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

[armedbear-devel] Performance: Analysis of options to reduce exception handlers
by Erik Huelsmann 09 Nov '10

09 Nov '10

Based on Joel's reaction regarding my profiling attempts on exception rates/exception handling in ABCL, I've been thinking how to do better in the exceptions/specials restoration department. Let me start by describing how our current exception handling/specials restoration is structured. It should be noted that the current strategy works the way it does because we were failing to restore special values all over the place. This made me decide that we should restore specials when leaving the binding block, even if that is through non-local transfer of control, with the contrived example for exception handlers as given in my mail earlier this month. Looking at the profiling results, we're now correct, but probably we're not very efficient at doing it. This is what I've been thinking: If a block binds special variables, there are 3 ways to exit the block: 1. through normal sequential execution of the byte code 2. through a function-local jump out of the block 3. through a non-local transfer of control (modelled using the ControlTransfer exception in ABCL) Case (1) is easy: we just reach the end of the binding block, at which point there is a call to "LispThread.restoreSpecialBindings(mark);". Case (2) is a little more involved: before jumping to the target location the specials are restored at the jump-location. To do this, there's a bit of logic in the compiler to find out which restore point to use. Case (3) is quite involved: at the call site an exception is thrown causing the stack to be unwound. When looking at it like this, the catch-site should restore its specials state. There's no need to do that, currently, because all the intermediate levels restore their state. There is at least one special case here: unwind-protect may be executing lisp code (which needs its specials restored to the right state) without being the final catch location. Final catch requiring forms are quite easily determined: TAGBODY (to catch GO), BLOCK (to catch RETURN) and CATCH (to catch THROW). One of the major drawbacks of this scheme is that all non-local transfers become responsible for restoring their special bindings. BLOCK and TAGBODY forms which don't serve as non-local target are not affected by this reasoning; they fall under case (2). CATCH can never be considered taking only local transfers of control as it However, the entire application may not be binding any specials at all. The overhead involves a call at the start of each block which contains non-local-transfer targets to snapshot the special bindings state and to restore it *in case of a non-local transfer*. The calls involved are markSpecialBindings() and restoreSpecialBindings(), two very short and - I think - efficient functions. So, there's a small drawback in applications which don't use special bindings much. However, the potential gain in applications which do use them is quite relevant: the example I gave before shows that a relatively simple function binding the same special variable three times will cause 3 separate specials-unwinding-exception blocks, each rethrowing the exception to the next level. Thinking about it a bit more, I realize that no additional exception blocks have to be registered. Just only the catch/restore of specials state. Looking at it this way, I propose that we stop restoring specials in finally blocks, moving part of the responsibility of having correct specials bindings to BLOCK, CATCH, TAGBODY and UNWIND-PROTECT. My change should affect both the interpreter and the compiler, to get the full benefit of efficiency. However, I thought I'd implement the LET/LET* binding optimization in the compiler first, just to see how much we benefit from this change in Maxima. Comments? Bye, Erik.

1 0

[armedbear-devel] Increased FASL size support -- was: [armedbear-cvs] r13013 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 09 Nov '10

09 Nov '10

There were some reports with FASLs becoming too large -- ie generating more .cls files than can be loaded in our loader method "<fasl-name>_0" because the code overflows the 64kB method size boundary. The change below drastically reduces the size of the generated loader method, reducing the chances that people run into an issue. Of course, that can't be the final state, but it seems like a good option, as long as we don't implement the means to split this method. Implementing means to split specifically this method however, doesn't seem good enough: all of our methods have the potential of overrunning the 64kB boundary and it would be nice if we could implement general method-splitting logic instead, to be applied when methods overrun their 64kB boundary size. This commit is in our upcoming release, aleviating (but not solving) the Big FASLs problem. Bye, Erik. On Mon, Nov 8, 2010 at 11:34 PM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Mon Nov 8 17:34:18 2010 > New Revision: 13013 > > Log: > Reduce the impact of the fasl-loader "_0" class's maximum size of 64kB: > this change reduces the size of pprint_0.cls from 23001 to 19380 bytes, > a saving of 18.64%, which is probably much more when counting the size > of the execute() method alone. > > Modified: > trunk/abcl/src/org/armedbear/lisp/compile-file.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/compile-file.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compile-file.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compile-file.lisp Mon Nov 8 17:34:18 2010 > @@ -679,7 +679,14 @@ > (defun generate-loader-function () > (let* ((basename (base-classname)) > (expr `(lambda (fasl-loader fn-index) > - (identity fasl-loader) ;;to avoid unused arg > + (declare (type (integer 0 256000) fn-index)) > + (identity fasl-loader) ;;to avoid unused arg > + (jvm::with-inline-code () > + (jvm::emit 'jvm::aload 1) > + (jvm::emit-invokevirtual jvm::+lisp-object+ "javaInstance" > + nil jvm::+java-object+) > + (jvm::emit-checkcast +fasl-classloader+) > + (jvm::emit 'jvm::iload 2)) > (ncase fn-index 0 ,(1- *class-number*) > ,@(loop > :for i :from 1 :to *class-number* > @@ -687,20 +694,14 @@ > (let* ((class (%format nil "org/armedbear/lisp/~A_~A" > basename i)) > (class-name (jvm::make-class-name class))) > - `(,(1- i) > - (jvm::with-inline-code () > - (jvm::emit 'jvm::aload 1) > - (jvm::emit-invokevirtual jvm::+lisp-object+ "javaInstance" > - nil jvm::+java-object+) > - (jvm::emit-checkcast +fasl-classloader+) > - (jvm::emit 'jvm::dup) > - (jvm::emit-push-constant-int ,(1- i)) > - (jvm::emit-new ,class-name) > - (jvm::emit 'jvm::dup) > - (jvm::emit-invokespecial-init ,class-name '()) > - (jvm::emit-invokevirtual +fasl-classloader+ > + `(,(1- i) > + (jvm::with-inline-code () > + (jvm::emit-new ,class-name) > + (jvm::emit 'jvm::dup) > + (jvm::emit-invokespecial-init ,class-name '()) > + (jvm::emit-invokevirtual +fasl-classloader+ > "putFunction" > - (list :int jvm::+lisp-object+) jvm::+lisp-object+) > + (list :int jvm::+lisp-object+) jvm::+lisp-object+) > (jvm::emit 'jvm::pop)) > t)))))) > (classname (fasl-loader-classname)) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] Reading a UTF-8 lisp source fails.
by pjb＠informatimago.com 07 Nov '10

07 Nov '10

My sources contain some non US-ASCII characters, so they're all encoded in UTF-8. However, loading them fails: [pjb@kuiper :0.0 lisp]$ LC_CTYPE=en_US.UTF-8 abcl Armed Bear Common Lisp 0.20.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.266 seconds. Startup completed in 0.726 seconds. Type ":help" for a list of available commands. CL-USER(1): (load"test-abcl-unicode.lisp") Error loading /home/pjb/src/git/public/lisp/test-abcl-unicode.lisp at line 3 (offset 54) #<THREAD "interpreter" {132021A}>: Debugger invoked on condition of type STREAM-ERROR Input value 0xffc2 is malformed while recoding with charset US-ASCII Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): (quit) [pjb@kuiper :0.0 lisp]$ What should I do to let abcl read them as UTF-8 and not try to convert them into US-ASCII? The test file is: ------------------------------------------------------------------------ ;;;; -*- mode:lisp;coding:utf-8 -*- (defvar *test* "45°") ;;;; THE END ;;;; ------------------------------------------------------------------------ -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

2 1

[armedbear-devel] directory doesn't honor :wild-inferiors (#P"**/*.*")
by pjb＠informatimago.com 07 Nov '10

07 Nov '10

[pjb@kuiper :0.0 lisp]$ abcl Armed Bear Common Lisp 0.20.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.266 seconds. Startup completed in 0.75 seconds. Type ":help" for a list of available commands. [1] CL-USER(9): (directory "*/*.asd") (#P"/home/pjb/src/git/public/lisp/tools/com.informatimago.common-lisp.tools.make-depends.asd" #P"/home/pjb/src/git/public/lisp/common-lisp/com.informatimago.common-lisp.asd" ...) [1] CL-USER(10): (directory #P"**/*.asd") NIL [1] CL-USER(11): -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

3 2

[armedbear-devel] Working toward the 0.23 release
by Erik Huelsmann 06 Nov '10

06 Nov '10

We've had a productive number of weeks since our last release. Changes include: * Running the Maxima test suite without failure [Thanks to the Maxima team for their part in this!] * CLOS thread safety fixes * Fixes to be able to run on Oracle JRockit JVM * Numerous tickets fixed * A new class file writer to build further optimizations upon So, I think we should be moving toward a release real soon now. Is there more to be added to trunk? If not, I'll be branching by the end of the weekend; otherwise, let's discuss and see what timelines to set. Everybody, thanks again for your contributions! Bye, Erik.

2 2

[armedbear-devel] Soliciting (updates to) testimonials
by Erik Huelsmann 04 Nov '10

04 Nov '10

In the interest of informing potential users about the various uses, strengths and weaknesses of ABCL, we have a Testimonials page. However, most of the testimonials don't have a date. That's rather unfortunate, because it makes it hard to judge how valid they still are: over the past three years, we had quite a bit of change in our code base. Most of the changes were driven by CLHS compliance, correctness or code cleanup (to support future maintenance). So, there's a good chance some of the older testimonials don't actually apply to current ABCL versions anymore. Just removing those older testimonials (leaving a blank page) isn't really an option for me. OTOH, leaving them up there without a date isn't really indicative of today's ABCL either. That's why I'm asking you to submit your (updated) testimonials. If you're currently using ABCL (or have been using until recently), but there's no testimonial up on the page from you, please take a quick look at the top testimonial at http://common-lisp.net/project/armedbear/testimonials.shtml (the one by David Kirkman). As you see, it doesn't have to be much, so, creating a testimonial doesn't have to take a lot of time. Taking the half hour to create a testimonial is your opportunity to donate back to the ABCL community! Thanks for your time and contributions, Erik.

1 0

[armedbear-devel] ASDF and ABCL
by Faré 31 Oct '10

31 Oct '10

Dear ABCL developers, the one big thing missing in ABCL to fully pass the ASDF test suite is support for (directory "/usr/share/common-lisp/source/**/*.asd") Could you get it to work and update to the latest stable ASDF? That would be great! [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The trouble with opportunity is that it always comes disguised as hard work. — Herbert V. Prochnow

3 12

[armedbear-devel] BUG: armedbear-devel@common-lisp.net
by Alessandro Serra 22 Oct '10

22 Oct '10

Hi, compiling ltk I have the following error: #<THREAD "interpreter" {FE135D}>: Debugger invoked on condition of type SIMPLE-ERROR s2 argument 34666 out of 16-bit signed range. Debugging a bit, I found that the error is in "compiler-pass2.lisp" in the function "code-bytes" during the pass2 (replace labels with calculated offsets). What can I do to avoid this error? Thanks, Alessandro -- The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use the words. How To Build A Universe That Doesn't Fall Apart Two Days Later Philip K. Dick

2 1

[armedbear-devel] basic support for DEFINE-METHOD-COMBINATION (long form) landed on trunk
by Erik Huelsmann 20 Oct '10

20 Oct '10

Just a minute ago, I committed Mark Evenson's work on DEFINE-METHOD-COMBINATION (long form) [short: D-M-C]. It's a port to ABCL of the D-M-C implementation found in XCL which derives from Sacla. That being the case, I expect the implementation to be little tested. Which can definitely be said of the port. However, some testing with a few self-made tests didn't turn up many problems. However, SBCL has a series of tests for D-M-C. It would be nice if we could port those to ABCL too in an effort to smoke out any issues our D-M-C implementation may have. I smoked out the first one already that way: there was a quote missing is a function which returns a part of a method combination form. Compile times just longer once again - however, there should be no measurable impact for any code which doesn't use the long form of D-M-C itself. Serious request: help smoke out problems! Test! Fix! The sooner we get good confidence in the implementation, the sooner we can release 0.23! Bye, Erik.

2 1

[armedbear-devel] failure to compile big files
by Carlos Ungil 19 Oct '10

19 Oct '10

Dear ABCL developers, trying to "compile-file" the following fragment of code using the latest release results in an error "s2 argument 32778 out of 16-bit signed range." ----------------------------------------------------- (defmacro many-functions (n) (append '(progn) (loop for i from 1 to n collect `(defun ,(intern (format nil "TEST~A" i)) () (print ,i))))) (many-functions 1525) ----------------------------------------------------- There are no problems with 0.20 (even for much bigger values of the parameter, i.e. bigger output files). I encountered the problem with a file containing several calls to the macro def-java-class in Jfli. It took me some time to discover that splitting the file in two was enough to make the problem go away... This is not a critical bug (it's usually easy to reorganize the code to ensure the files are small enough), but you might want to look at it. Cheers, Carlos

3 4