- armedbear-devel - mailman3.common-lisp.net

Re: [armedbear-devel] [j-devel] Compilation Problem in ABCL 0.17
by Mark Evenson 15 Nov '09

15 Nov '09

On 11/15/09 10:03 PM, Dr. Thomas Sturm wrote: > I am using a 64-bit Mac with Snow Leopard (Mac OSX 10.6.2). I didi not do anything special but simply went (compile-file "test") in a fresh session. > > Here is my banner of ABCL: > > sturm@lennier[~] abcl > Armed Bear Common Lisp 0.17.0 > Java 1.6.0_15 Apple Inc. > Java HotSpot(TM) 64-Bit Server VM > Low-level initialization completed in 0.348 seconds. > Startup completed in 0.936 seconds. > Type ":help" for a list of available commands. > CL-USER(1): > > The ABCL is not from the svn but the 0.17.0 distribution as of last Saturday. […] I can reproduce your problem as well with ABCL trunk under the same OS/JVM. No idea yet on fixing it, but I will file a bug report for you. Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Re: [armedbear-devel] Inline primitives as static method calls
by logicmoo＠gmail.com 11 Nov '09

11 Nov '09

> > ----- Original Message ----- > From: "Alessio Stalla" <alessiostalla(a)gmail.com> > To: <dmiles(a)users.sourceforge.net> > Cc: "Armed Bear" <armedbear-devel(a)common-lisp.net> > Sent: Tuesday, November 10, 2009 1:12 AM > Subject: Re: [armedbear-devel] Inline primitives as static method calls > > > On Tue, Nov 10, 2009 at 9:01 AM, <logicmoo(a)gmail.com> wrote: >> Alessio, >> Excellent Work! >> >> Your .patch is what I meant. > > Thanks! > >> >>> when compiled it is translated as a direct call to the static >>> method, without passing through the symbol, which is faster than now >> >> Perfect - Yeah >> >> >> >> A Side note: >>> >>> When interpreted or passed as a higher-order function an >>> InlinedPrimitive calls the static method through reflection, resulting >>> in slower performance than now. >> >> I wrote a workaround for this into LarKC because of the performance >> degradation. >> >> So later on.... >> Like after we have everything working/vetted calling static inlines as much >> as possible. >> And using InlinePrimtives to call reflection... >> >> >> >> We'll have some options like: "FixedArityFunctor": >> >> http://larkc.svn.sourceforge.net/viewvc/larkc/trunk/platform/src/com/cyc/to… >> >> What I did was created a new Class via ASM that contains a single >> execute(a,b,c,d,e,f) signature per "args used". >> That simply calls the static method . >> >> So in InlinePrimitive later suplimented with some extras like: >> >> //The methodWith0Args - methodWithNArgs is what that .java url above >> generates. >> LispObject execute() { >> return methodWith0Args.evaluate(); >> } >> LispObject execute(LispObject a0) { >> return methodWith1Args.evaluate(a0); >> } >> LispObject execute(LispObject a0,LispObject a1) { >> return methodWith2Args.evaluate(a0,a1); >> } >> etc >> >> >> Figured I should mention the "FixedArityFunctor" so we dont get scared off >> by any performance >> degration of higher level calls before we learn all the benefits of inlining >> static functions! > > Ok, I'm not sure I followed everything. Oh the above was attempting to describe LarKC SubLisp implementation of this article: http://www.ibm.com/developerworks/java/library/j-dyn0610/ I couldnt find it before sending the email! The intial LarKC implemention used reflection in the same maner as InlinedPrimive does. The after reading that article, I found I could replace Method[] cache inside InlinedPrimive with generated methodStubs produced runtime for reflection performance. > but consider also that the > implementation through reflection is the default one, for convenience, > but you can still override the various execute() methods and call the > static method directly (of course, you have to make sure the method > you call is the same as the one you pass in the constructor, or things > start to behave differently in interpreted vs compiled code and that's > definitely not good :D). Something like > > new InlinedPrimitive(My.class, "myMethod", ...) { > public LispObject execute(LispObject arg) { > return My.myMethod(arg); > } > } Yup, InlinePrimtive still leaves that option open. If someone really wanted to, they can do that with a couple of their InlinedPrimtives if they noticed one particualtar method was getting called quite a bit. Making the instance execute call the static function (Like EQ/EQL/EQUAL for instance avoiding reflection.) > > The class I posted lacks the constructors taking the class and the > method, because I have been lazy ;), but they can easily be added - > with the caveat that, since the call to super() must be the first and > for Function super() sometimes (always?) installs the function in a > symbol (iirc), if you pass a wrong class/method to InlinedPrimitive > and as a result an exception is thrown, you'll have a symbol pointing > to an invalid function. I realy do like how you did it as factory method: public static final Primitive COPY_TREE = InlinedPrimitive.get(Primitives.class, "copyTree", Symbol.COPY_TREE, "object"); And depending on safety/speed you could save the string name of the class and method name for later and not even try to resolve the method[] until first time call.. and signal an error then if not found. This could be used like autoloading. > > Bye, > Ale

2 1

[armedbear-devel] Array Cleanup Example
by logicmoo＠gmail.com 11 Nov '09

11 Nov '09

Here is an example of an array cleanup that might be usefull. * It uses Arrays.fill(...) when it can * throwing badMajorRowIndex from one array (repeated code) This one is a bit questionable: * It started out as int32[] backing becasue we needed one extra signless bit to represent a 'unit16' PROS: Also notice the previous was constantly: store -> unboxing , get -> reboxing So almost anytime we wanted to store .. we took a submitted valid Fixnum.. then forgot about it. Then when we want a value: we have to recreate a fixnum to replace the one we had previously lost. CONS: On a 32bit machine the new represention takes the same ram 64 bit machine takes twice the ram after the refactor. Later on we might decide to allow this array to participate in the JavaObject ontology .. if so, then this is a neat object for storing unsigned shorts.. however would JavaObject ever rerpresent Unsigned numbers? ----------------------------------------------------------------------------------- Index: src/org/armedbear/lisp/SimpleArray_UnsignedByte16.java =================================================================== --- src/org/armedbear/lisp/SimpleArray_UnsignedByte16.java (revision 12275) +++ src/org/armedbear/lisp/SimpleArray_UnsignedByte16.java (working copy) @@ -33,17 +33,19 @@ package org.armedbear.lisp; +import java.util.Arrays; + public final class SimpleArray_UnsignedByte16 extends AbstractArray { private final int[] dimv; private final int totalSize; - private final int[] data; + private final Fixnum[] data; public SimpleArray_UnsignedByte16(int[] dimv) { this.dimv = dimv; totalSize = computeTotalSize(dimv); - data = new int[totalSize]; + data = new Fixnum[totalSize]; } public SimpleArray_UnsignedByte16(int[] dimv, LispObject initialContents) @@ -57,7 +59,7 @@ rest = rest.elt(0); } totalSize = computeTotalSize(dimv); - data = new int[totalSize]; + data = new Fixnum[totalSize]; setInitialContents(0, dimv, initialContents, 0); } @@ -75,7 +77,7 @@ rest = rest.elt(0); } totalSize = computeTotalSize(dimv); - data = new int[totalSize]; + data = new Fixnum[totalSize]; setInitialContents(0, dimv, initialContents, 0); } @@ -85,7 +87,7 @@ { if (dims.length == 0) { try { - data[index] = coerceLispObjectToJavaByte(contents); + data[index] = checkValue(contents); } catch (ArrayIndexOutOfBoundsException e) { error(new LispError("Bad initial contents for array.")); @@ -192,10 +194,10 @@ public int aref(int index) { try { - return data[index]; + return data[index].value; } catch (ArrayIndexOutOfBoundsException e) { - error(new TypeError("Bad row major index " + index + ".")); + badRowMajorIndex(index); // Not reached. return 0; } @@ -205,21 +207,33 @@ public LispObject AREF(int index) { try { - return Fixnum.getInstance(data[index]); + return data[index]; } catch (ArrayIndexOutOfBoundsException e) { - return error(new TypeError("Bad row major index " + index + ".")); + return badRowMajorIndex(index); } } + + private LispObject badRowMajorIndex(int index) { + return error(new TypeError("Bad row major index " + index + ".")); + } + public static Fixnum checkValue(LispObject obj) + { + if (obj instanceof Fixnum) { + return (Fixnum)obj; + } + return (Fixnum)type_error(obj, UNSIGNED_BYTE_16); + } + @Override public void aset(int index, LispObject obj) { try { - data[index] = Fixnum.getValue(obj); + data[index] = checkValue(obj); } catch (ArrayIndexOutOfBoundsException e) { - error(new TypeError("Bad row major index " + index + ".")); + badRowMajorIndex(index); } } @@ -259,11 +273,10 @@ public LispObject get(int[] subscripts) { try { - return Fixnum.getInstance(data[getRowMajorIndex(subscripts)]); + return data[getRowMajorIndex(subscripts)]; } catch (ArrayIndexOutOfBoundsException e) { - return error(new TypeError("Bad row major index " + - getRowMajorIndex(subscripts) + ".")); + return badRowMajorIndex(getRowMajorIndex(subscripts)); } } @@ -272,20 +285,17 @@ { try { - data[getRowMajorIndex(subscripts)] = Fixnum.getValue(obj); + data[getRowMajorIndex(subscripts)] = checkValue(obj); } catch (ArrayIndexOutOfBoundsException e) { - error(new TypeError("Bad row major index " + - getRowMajorIndex(subscripts) + ".")); + badRowMajorIndex(getRowMajorIndex(subscripts)); } } @Override public void fill(LispObject obj) { - int n = Fixnum.getValue(obj); - for (int i = totalSize; i-- > 0;) - data[i] = n; + Arrays.fill(data, 0, totalSize, checkValue(obj)); } @Override

2 2

[armedbear-devel] Performance improvement special binding read/write
by Erik Huelsmann 10 Nov '09

10 Nov '09

Last weekend, I ran Maxima tests since some time again. I don't remember the older performance figures, although I remember the total test suite - possibly performance tuned - to take 3300seconds before. Last weekend, it was 3900seconds, giving me a feeling of performance regression. So I decided to take another look. I found two things, one of which is that we still have slow special binding value lookup. Peter Graves suggested some time ago that we switch to the same scheme used by SBCL and CCL because he found that XCL benefitted ~10% on his tests when he made the same switch. The scheme used by SBCL/CCL differs from the one used by ABCL in the way the "active" binding is being accessed. ABCL manages all bindings as a linked list, with the most recent one as the active one. This means O(n) access time on the number of special bindings. In SBCL/CCL, the active binding is stored in an array, with a linked list to record which values to restore when unwinding the binding. Upon restore, this solution takes more cycles than our solution: we simply change the head of the linked list, whereas the SBCL/CCL solution needs to set all the array elements. Running the application which we know tests special bindings performance the best [Maxima], I see a strong performance improvement: 3900 seconds before and 2300 seconds after the change. Performance improved by ~40%! I'll commit this change after cleaning up. Bye, Erik.

1 1

[armedbear-devel] Class file extenstions
by logicmoo＠gmail.com 10 Nov '09

10 Nov '09

I dont think this patch has any ill-effects - But I only tested on Win64/Linux64 Sun Java 6s Its for http://trac.common-lisp.net/armedbear/attachment/ticket/34 (Ignore the previous patch posted there) The goal of it.. for is for the start leveraging Ahead Of Time compilers like GCJ/EcellisorJET According to Peter the original use of ".cls" was more for figuring out which files to delete.. not because the classfile format was non-compliant. ---------------------------------------------------------------------------------------------------------------- Index: src/org/armedbear/lisp/compile-file.lisp =================================================================== --- src/org/armedbear/lisp/compile-file.lisp (revision 12273) +++ src/org/armedbear/lisp/compile-file.lisp (working copy) @@ -45,8 +45,8 @@ *output-file-pathname*)) "Computes the name of the class file associated with number `n'." (let ((name - (%format nil "~A-~D" - (substitute #\_ #\. + (%format nil "~A_~D" + (substitute #\$ #\. (pathname-name output-file-pathname)) n))) (namestring (merge-pathnames (make-pathname :name name :type "cls") output-file-pathname))))

1 0

[armedbear-devel] Inline primitives as static method calls
by Alessio Stalla 10 Nov '09

10 Nov '09

Attached is a patch + a Java class that tentatively implement logicmoo's idea of "inlining" primitives as calls to static methods (just for test on a single primitive, COPY-TREE). The Java class, InlinedPrimitive, extends Primitive and implements its execute() methods with static methods with a given name found in a given class. When interpreted or passed as a higher-order function an InlinedPrimitive calls the static method through reflection, resulting in slower performance than now. But, when compiled it is translated as a direct call to the static method, without passing through the symbol, which is faster than now (I haven't measured how much faster). Consider this patch as a rough draft - it must be polished if we ever decide to include it. In particular "inlining" is always performed, while we should probably avoid it with some debug/speed settings. Bye, Alessio

2 2

[armedbear-devel] SETF for JFEILDS
by logicmoo＠gmail.com 10 Nov '09

10 Nov '09

Hi, Could we add add something like this to java.lisp? (defun (setf jfield) (newvalue class-ref-or-field field-or-instance &optional ( instance :noinst) (value :novalue)) (if (eq instance :noinst) (jfield class-ref-or-field field-or-instance newvalue) (jfield class-ref-or-field field-or-instance instance newvalue))) -Thx

1 0

Re: [armedbear-devel] Changes to ConditionThrowable
by logicmoo＠gmail.com 08 Nov '09

08 Nov '09

Yep I had *improperly* tried to divide the three type of ControlTransfers They are indeed undistinguishable by class. In fact my now I remember: 3rd party code didn't catch the ControlTransfers but instead override ERROR/%DEBUGGER-HOOK-FUNCTION Symbol sym = Lisp.PACKAGE_CL_USER.findAccessibleSymbol("ERROR"); sym.setSymbolFunction(new CSThrowError(sym.getSymbolFunction())); sym = Lisp.PACKAGE_SYS.findAccessibleSymbol("%DEBUGGER-HOOK-FUNCTION"); sym.setSymbolFunction(new CSThrowError(sym.getSymbolFunction())); Then had to decide to handle it with inspecting the arguments with lines: 32-54 of http://code.google.com/p/opensim4opencog/source/browse/trunk/Cogbot/ScriptE… Thanks for he clarity. ----- Original Message ----- From: "Erik Huelsmann" <ehuels(a)gmail.com> To: <dmiles(a)users.sourceforge.net> Sent: Friday, November 06, 2009 11:39 PM Subject: Re: [armedbear-devel] Changes to ConditionThrowable Hi Douglas, On Sat, Nov 7, 2009 at 1:33 AM, <logicmoo(a)gmail.com> wrote: > My two cents: > > Those who call Lisp.eval(...) or mySymbol.execute() should at least be > capable of catching RuntimeCondition But should not be forced to also catch > Go and Throw > > The way it is now.. > I have a Primitive that I implement outside of ABCL. > It catches certain condition throwables but should not have to catch > Throw/Go > > which means: > ABCL calls my primitive. > My code is calling back into ABCL > I must catch ConditionThrowable. > I must also check to see if ConditionThrowable instanceof Go or instanceof > Throw. > If one of these things are true, I have to rethrow the Go or Throw > However I do not rethrow SeriousCondtions.. I have a different handler. > that may change the type of condition. > > > I suggest dividing the ontology of ConditionThrowable into two types: > > ControlTransfer > RuntimeCondition > Derive them both from RuntimeException if you'd like. The thing is: SeriousCondition is never thrown in terms of Java 'throw': it's either signalled or error-ed, which don't use the Java throw primitive. I think these conditions really *are* transfer-of-control events. Thanks for your feedback! Bye, Erik.

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.17.0 released
by Erik Huelsmann 07 Nov '09

07 Nov '09

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.17.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements JSR-223. This release features - among lots of other things - performance improvements, a fix for unexpected thread termination due to uncaught exceptions and example code for running ABCL on Google App Engine. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.17.shtml If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/abcl-src-0.17.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.17.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.17.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.17.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.17.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.17.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.17.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.17.0.zip.asc Erik Huelsmann

1 0

Re: [armedbear-devel] Changes to ConditionThrowable
by logicmoo＠gmail.com 07 Nov '09

07 Nov '09

Sorry I should said Go & Return -> ControlTransfer - > RuntimeException Throw -> RuntimeCondition -> RuntimeException Though some people use Throw for for flow control ----- Original Message ----- From: <dmiles(a)users.sourceforge.net> To: "Erik Huelsmann" <ehuels(a)gmail.com>; "Armed Bear" <armedbear-devel(a)common-lisp.net> Sent: Friday, November 06, 2009 4:33 PM Subject: Re: [armedbear-devel] Changes to ConditionThrowable > My two cents: > > Those who call Lisp.eval(...) or mySymbol.execute() should at least be capable of catching RuntimeCondition > But should not be forced to also catch Go and Throw > > The way it is now.. > I have a Primitive that I implement outside of ABCL. > It catches certain condition throwables but should not have to catch Throw/Go > > which means: > ABCL calls my primitive. > My code is calling back into ABCL > I must catch ConditionThrowable. > I must also check to see if ConditionThrowable instanceof Go or instanceof Throw. > If one of these things are true, I have to rethrow the Go or Throw > However I do not rethrow SeriousCondtions.. > I have a different handler. that may change the type of condition. > > > I suggest dividing the ontology of ConditionThrowable into two types: > > ControlTransfer > RuntimeCondition > > Derive them both from RuntimeException if you'd like. > > > > ----- Original Message ----- > From: "Erik Huelsmann" <ehuels(a)gmail.com> > To: "Armed Bear" <armedbear-devel(a)common-lisp.net> > Sent: Friday, November 06, 2009 11:49 AM > Subject: [armedbear-devel] Changes to ConditionThrowable > > >>A very prominent item in our API is that nearly every function is >> declared to throw ConditionThrowable. >> >> Personally, I have 2 gripes with that situation: >> >> 1) ConditionThrowable is the most undescriptive name of what it actually is and >> 2) Since ConditionThrowable is a completely *internal* thing to ABCL, >> it's wrong to expose it this way >> >> >> My proposal is to: >> >> 1) Rename ConditionThrowable to ControlTransfer - which is more of a >> description of what it does: it's used internal to ABCL to cause >> non-local transfer of control >> 2) Make ControlTransfer an unchecked exception (thus derive it from >> RuntimeException), because that'll allow us to keep it from being >> exposed in the API. >> We'll need to document in an abcl-embedding manual that callbacks >> should be aware of the fact that a ControlTransfer exception may cause >> the function's execution to be terminated. >> >> >> For normal API use, ControlTransfer won't be seen: it'll be thrown and >> consumed inside ABCL. >> >> >> How about that? >> >> Bye, >> >> >> Erik. >> >> _______________________________________________ >> armedbear-devel mailing list >> armedbear-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 1