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

[armedbear-devel] json-rpc?
by Axel Rauschmayer 28 Apr '11

28 Apr '11

I think ABCL would make an excellent Ajax server. As such, it would have to support json-rpc. Any suggestions as to how to make this happen? The first part is obviously the server, where the two choices that I can see are Hunchentoot and a servlet container such as Tomcat. In the latter case, I would expect to use a technique like abcl-web (which seems a little bit complicated, but doable). The second part is the JSON parsing. How would I do that? Via CL-JSON? Via Yason? Via a Java library? Sorry for these newbie questions. I’m just getting started with Common Lisp and ABCL. Thanks, Axel -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/

4 10

[armedbear-devel] :case :common
by pjb＠informatimago.com 27 Feb '11

27 Feb '11

CLHS says: 19.2.2.1.2.2 Common Case in Pathname Components For the functions in Figure 19-2, a value of :common for the :case argument that these functions should receive and yield strings in component values according to the following conventions: * All uppercase means to use a file system's customary case. * All lowercase means to use the opposite of the customary case. * Mixed case represents itself. Note that these conventions have been chosen in such a way that translation from :local to :common and back to :local is information-preserving. [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.265 seconds. Startup completed in 0.718 seconds. Type ":help" for a list of available commands. CL-USER(1): (make-pathname :name "TEST" :type "LISP" :case :common) #P"TEST.LISP" CL-USER(2): (namestring (make-pathname :name "TEST" :type "LISP" :case :common)) "TEST.LISP" I'm on a linux system on a ext3 file system. The customary case is lower case (case significant on this particular file system, but 99.999% of the files on unix are lower case). Therefore I would expect to get #P"test.lisp" Notice that: (make-pathname :name "test" :type "lisp" :case :common) should produce #P"TEST.LISP" and that: (make-pathname :name "Test" :type "Lisp" :case :common) should produce #P"Test.Lisp" And that I understand "yeld strings in component values" to mean that the processing should be done on each parameter independently. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

3 4

[armedbear-devel] Registering Java Exceptions
by William 15 Feb '11

15 Feb '11

Hi, I am trying to register Java exceptions using REGISTER-JAVA-EXCEPTION but it does not seem to work for me as evidenced by the transcript below. Is there anything that I may have missed? Armed Bear Common Lisp 0.23.1 Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.354 seconds. Startup completed in 1.579 seconds. Type ":help" for a list of available commands. CL-USER(1): (define-condition java-illegal-argument-error (java-exception) ()) JAVA-ILLEGAL-ARGUMENT-ERROR CL-USER(2): (register-java-exception "java.lang.IllegalArgumentException" 'java-illegal-argument-error) NIL CL-USER(3): (ignore-errors (jstatic (jmethod "java.lang.String" "valueOf" "int") "java.lang.String" "12")) NIL #<JAVA-EXCEPTION {4A6F19D5}> CL-USER(4): (jstatic (jmethod "java.lang.String" "valueOf" "int") "java.lang.String" "12") #<THREAD "interpreter" {2690ED81}>: Debugger invoked on condition of type JAVA-EXCEPTION #<JAVA-EXCEPTION {74D8C3EE}> Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(5): 0 CL-USER(6): Kind regards, Martin.

2 1

[armedbear-devel] couple of difficult to debug clos situations
by Alan Ruttenberg 13 Feb '11

13 Feb '11

(defclass a (b)) (make-instance 'a) ; Evaluation aborted on NIL. ;; no backtrace in slime The problem is that b is not defined, but the error makes this difficult to discern. --- Trying to fix the problem in some ways leads to more: (defclass a1 (b1)) (defclass b2 ()) CL-USER> (make-instance 'a1) ; Evaluation aborted on NIL. ;; no backtrace in slime CL-USER> (defclass a1 (b2)) ; Evaluation aborted on NIL. ;; no backtrace in slime --- (defclass a3 (b3)) (mop::class-prototype (find-class 'a3)) ;; here we get a backtrace: #<STANDARD-CLASS A3 {1E8E471}> is not finalized. However it is hard to figure out what the problem is. Now try to fix it: (defclass b3 ()) (mop::class-prototype (find-class 'a3)) ;; still get "is not finalized" error (make-instance 'a3) ;; succeeds (mop::class-prototype (find-class 'a3)) ;; now it succeeds -Alan

2 1

[armedbear-devel] (defstruct (teststruct (:type list) :named) testslot)))
by Alan Ruttenberg 03 Feb '11

03 Feb '11

(defstruct (teststruct (:type list) :named) testslot))) causes the following defun to be compiled: (DEFUN NIL (SYSTEM::INSTANCE) (ELT SYSTEM::INSTANCE 0)) That shouldn't be. Particularly if (fdefinition nil) gives an error. -Alan

2 2

[armedbear-devel] [RFC] How to better support disposal of class objects
by Erik Huelsmann 31 Jan '11

31 Jan '11

To prevent any confusion beforehand: The mail below talks about class objects, objects which store class definitions, not the actual instances of those classes, which use those class definitions and store class-allocated or instance values. We have fixed a few bugs where memory would be allocated during (package creation or) FASL loading, but would not be freed upon package deletion. That was an issue because it's an explicit use-case for Blake. Last weekend I came up with another "leak" in ABCL. The word "leak" is between quotes, because depending on how you look at it, not all of it may technically be leaky. My point: it's easy to create a class; simply use a DEFCLASS form. However, unlike package creation, which can be "undone" through DELETE-PACKAGE, there's no DELETE-CLASS function to undo the result of a DEFCLASS. I started to think about supporting the use-case of deleting a class. Digging around in our implementation, I found there are several reasons why a class won't be automatically cleaned up when the package containing its naming symbol is deleted: 1. Every parent maintains a list of subclasses The list contains class objects, meaning that the actual class-object is referenced in this list and for that reason can't be GC-ed 2. Every generic function maintains a list of specializing methods The methods in the list refer to the dispatch types, meaning that the class-objects are strongly referenced from there too 3. Our FIND-CLASS implementation contains strong references to both the naming symbols as well as the class-objects. 4. Our implementation uses a cache to speed up the calls to generic functions. This cache uses strong references too. The issue in item (3) can be solved (relatively) easy by developing a weak hash table which contains both weak keys and values. This hash table could even be made available as regular Lisp objects. Item (4) currently uses an explicitly specialized hash table implemented on the Java side. The hash table could be adapted to use weak references as well - the effort wouldn't be as generally usable, but that's just tough luck. Items (1) and (2) are something to think about though: Is it wise to implement a function which removes the methods and the class from its parent? What if the class itself has direct subclasses? Do we signal an error? Do we provide a parameter forcing the deletion of a whole tree? Or maybe we should just document how potential users of our CLOS should proceed if they have the intention to do this, since it won't be portable anyway? Myself, I'm currently contemplating "just document" on one hand and "do whatever we can, even if they're whole trees" on the other... What do other people think? Bye, Erik.

2 2

[armedbear-devel] Start up message suggestion
by Blake McBride 31 Jan '11

31 Jan '11

Greetings, I've got a suggestion regarding the startup message on development versions of abcl. Rather that just saying "-dev" why don't we say "-dev (XXX)" where XXX is the subversion revision number? This would make it much more clear about what you are running, and I'm pretty sure subversion can automatically provide and update this (I am doing it elsewhere). Thanks. Blake McBride

6 12

[armedbear-devel] ext:run-shell-program
by Alex Mizrahi 30 Jan '11

30 Jan '11

hi I'd like to recieve output of external program as a stream, i.e. without getting it all in one (potentially) huge string but processing it in small portions as it comes. But it looks like this is not possible to do this with ext:run-shell-program -- it accepts output stream as parameter, but I can't read from output stream, and there is no way to translate output stream into input string in CL. (make-echo-stream does the opposite.) So ... am I missing something? If not, what is the best way to implement this?

1 0

[armedbear-devel] Thanks for the error message fix
by Blake McBride 27 Jan '11

27 Jan '11

Greetings, Thanks a lot for fixed the error messages. I can't tell you how much easier debugging has been. Thanks! Blake McBride

1 0

[armedbear-devel] Filename errors in Windows
by Arie van Wingerden 26 Jan '11

26 Jan '11

Hi, I just started with ABCL using the J editor on WinXP SP3. I replaced the ABCL jar in the J lib with the latest 0.23.1, but also in the old version ABCL 0.19 I had the same errors. I am able to create and save a very simple lisp file. However, when I use the menu function: Mode | Compile and load file I get this: [1] CL-USER(3): ;;; Compiling and loading D:\src\lisp\plus.lisp ... #<THREAD "JLisp interpreter" {FD5428}>: Debugger invoked on condition of type FILE-ERROR The file "D:/src/lisp/srclispplus.lisp" does not exist. It seems that somewhere under the hood the filename gets corrupted. Trying to change the name using double backslashes in the text box above the source file does have no effect. Can I change this behaviour? Thx, Arie

3 8

Re: [armedbear-devel] Infinite loop loading compiled file
by Greg Baryza 26 Jan '11

26 Jan '11

Sent, Erik. Thank you. Please confirm that you have it in hand. At 10:11 PM 1/25/2011, Erik Huelsmann wrote: >Hi Greg, > >On Tue, Jan 25, 2011 at 10:01 PM, Greg Baryza <baryza(a)intersystems.com> wrote: > > I have a self-contained directory that has only the QI files needed to > > reproduce the problem. Â In it there is a subdirectory called JAR where you > > should place the ABCL jar file of your choice. Â _COMPILE.bat compiles > files > > and then loads them; it hangs trying to load the fourth file. _BUILD.bat > > uses the same files but just loads the lisp sources; it works. > >That looks like a manageable size reproduction. Interesting. > >Could you send directly to me on my sender address? I'll check it out. > >Bye, > >Erik. > > > > I have all this in a 16KB zip file ready to go. Â Where do you want it? > > > > <G> > > > > At 09:23 PM 1/25/2011, Erik Huelsmann wrote: > >> > >> Hi Greg, > >> > >> On Tue, Jan 25, 2011 at 3:33 PM, Greg Baryza <baryza(a)intersystems.com> > >> wrote: > >> > I recently became interested in the language QI. Ã Since it did not run > >> > on > >> > ABCL (it does on SBCL, Allegro, LispWorks and others), I decided to see > >> > what it would take to move it there. Ã From the QI mailing list, I > found > >> > several others had tried on earlier versions of ABCL with inconclusive > >> > results. Ã I decided to give it a try on 0.23.1. > >> > > >> > When I tried the standard script with compiles and then loads the > >> > compiled > >> > files, ABCL hangs it what appears to be an infinite loop try to load one > >> > of > >> > the compiled files. Ã When I switch to just loading them in as Lisp > >> > sources, > >> > things seem to work (though some of the QI tests later fail). > >> > > >> > I tried the compile/load script under 0.24.0 today and the same hang > >> > happens. > >> > > >> > I have a small test case consisting only of the needed sources and a > >> > couple > >> > of .bat files for Windows that demonstrates the problem, but before I > >> > proceed further, has anyone seem anything like this. Ã The file in > >> > question > >> > DEFUNs about 85 functions. Ã Is that too many to provoke the "large > >> > file" > >> > problem I see mentioned here? > >> > >> Could you provide us with a transcript for downloading/installing Qi > >> so we/I can test? > >> > >> If this is the same old bug, the ball is really in Qi's park, but if > >> it's not, we're really happy to fix what we can! > >> > >> Thanks! > >> > >> > >> Bye, > >> > >> > >> Erik. > > > >

1 0

[armedbear-devel] initialization of shared slots
by Didier Verna 26 Jan '11

26 Jan '11

Hello, it seems that until now, I've been relying on a non-standard behavior, namely the fact that shared slots with an :initform are initialized before the first actual class instance is created: (defclass test () ((slot :allocation :class :initform t))) (defmethod initialize-instance :before ((test test) &key) (format t "Slot boundp: ~A~%" (slot-boundp test 'slot))) CL-USER> (make-instance 'test) Slot boundp: NIL #<TEST {C5D3B8}> CL-USER> (make-instance 'test) Slot boundp: T #<TEST {14563D4}> CL-USER> I just fell on this because every other Common Lisp implementation I've tried gives T and T here. Is it due to the way CLOS is implemented in ABCL, and is there a chance that this can be improved? Thanks. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

3 4

Re: [armedbear-devel] Infinite loop loading compiled file
by Greg Baryza 25 Jan '11

25 Jan '11

I have a self-contained directory that has only the QI files needed to reproduce the problem. In it there is a subdirectory called JAR where you should place the ABCL jar file of your choice. _COMPILE.bat compiles files and then loads them; it hangs trying to load the fourth file. _BUILD.bat uses the same files but just loads the lisp sources; it works. I have all this in a 16KB zip file ready to go. Where do you want it? <G> At 09:23 PM 1/25/2011, Erik Huelsmann wrote: >Hi Greg, > >On Tue, Jan 25, 2011 at 3:33 PM, Greg Baryza <baryza(a)intersystems.com> wrote: > > I recently became interested in the language QI. Â Since it did not run on > > ABCL (it does on SBCL, Allegro, LispWorks and others), I decided to see > > what it would take to move it there. Â From the QI mailing list, I found > > several others had tried on earlier versions of ABCL with inconclusive > > results. Â I decided to give it a try on 0.23.1. > > > > When I tried the standard script with compiles and then loads the compiled > > files, ABCL hangs it what appears to be an infinite loop try to load one of > > the compiled files. Â When I switch to just loading them in as Lisp > sources, > > things seem to work (though some of the QI tests later fail). > > > > I tried the compile/load script under 0.24.0 today and the same hang > happens. > > > > I have a small test case consisting only of the needed sources and a couple > > of .bat files for Windows that demonstrates the problem, but before I > > proceed further, has anyone seem anything like this. Â The file in question > > DEFUNs about 85 functions. Â Is that too many to provoke the "large file" > > problem I see mentioned here? > >Could you provide us with a transcript for downloading/installing Qi >so we/I can test? > >If this is the same old bug, the ball is really in Qi's park, but if >it's not, we're really happy to fix what we can! > >Thanks! > > >Bye, > > >Erik.

2 1

[armedbear-devel] Problem with error reporting
by Blake McBride 25 Jan '11

25 Jan '11

I've noticed a problem with error reporting in certain cases. For example, if you type (cons) you get: "Wrong number of arguments for CONS." However, if you type (time) you get: "Wrong number of arguments for ~S." It should be: "Wrong number of arguments for TIME." Of course this is a problem because it doesn't give any pointers when a function fails. I've seen this issue in several instances. Thanks. Blake McBride

3 11

[armedbear-devel] Infinite loop loading compiled file
by Greg Baryza 25 Jan '11

25 Jan '11

I recently became interested in the language QI. Since it did not run on ABCL (it does on SBCL, Allegro, LispWorks and others), I decided to see what it would take to move it there. From the QI mailing list, I found several others had tried on earlier versions of ABCL with inconclusive results. I decided to give it a try on 0.23.1. When I tried the standard script with compiles and then loads the compiled files, ABCL hangs it what appears to be an infinite loop try to load one of the compiled files. When I switch to just loading them in as Lisp sources, things seem to work (though some of the QI tests later fail). I tried the compile/load script under 0.24.0 today and the same hang happens. I have a small test case consisting only of the needed sources and a couple of .bat files for Windows that demonstrates the problem, but before I proceed further, has anyone seem anything like this. The file in question DEFUNs about 85 functions. Is that too many to provoke the "large file" problem I see mentioned here? Thanks.

4 3

[armedbear-devel] Dynamic classpath settings (ticket #18)
by Erik Huelsmann 24 Jan '11

24 Jan '11

Hi Alessio, There's a ticket (#18, http://trac.common-lisp.net/armedbear/ticket/18) to add dynamic classpath capabilities to ABCL, just as used by invoke.lisp. Browsing through our sources, I think you may have added this capability already. Can the issue be closed? Bye, Erik.

3 3

[armedbear-devel] [ANNOUNCE] ABCL 0.24.0 released
by Erik Huelsmann 22 Jan '11

22 Jan '11

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.24.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: Java scripting API. This release features - among lots of other things - improved embedding support through elimination of System.exit() calls and fixes a regression causing FASLs to be limited in the number of functions they can contain. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.24.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES 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/0.24.0/abcl-src-0.24.0.ta… http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-src-0.24.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/0.24.0/releases/abcl-src-0.24.0.ta… http://common-lisp.net/project/armedbear/0.24.0/releases/abcl-src-0.24.0.zi… In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-bin-0.24.0.ta… http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-bin-0.24.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.24.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.24.0.zip.asc

1 0

[armedbear-devel] Design issue regarding condition printing (was: Error reporting problems)
by Erik Huelsmann 22 Jan '11

22 Jan '11

In order to start addressing our issue with error reporting, I thought I'd start poking around at the source of all Java based exception classes (of which both PROGRAM-ERROR and SIMLE-ERROR are part). This source is the Condition java class. In the class 3 methods have been defined, all related to printing of (java based) errors: * getMessage() [overridden 13 times, 8 call sites] * getConditionReport() [not overridden, 1 call site] * writeToString() While the role of "writeToString()" is clear (it's called by PRINT to print all Java-based objects) and hence should function differently under different circumstances, the role separation between getMessage() and getConditionReport() isn't quite so well defined. This conclusion comes both from the extreme lack of documentation as well as the following: getConditionReport() calls getMessage() to find an "alternative message" to be reported. getMessage() finds out if there's a formatControl string; if there is, it calls writeToString() to generate a message, returning that to getConditionReport(). If getConditionReport() doesn't get an alternative from getMessage() to return back to the caller, it calls Lisp.format() to generate a formatted string to be presented to the user. However, this second path will never get called, except when there's no format string.... Lisp.format() explicitly checks for a null format control string and returns an empty string - which explains why we haven't seen crashes from the above code paths. So, how does that tie into the grand scheme of error reporting? We have two places where errors are being reported: 1. the lisp debugger, which prints errors using the real (lisp based) FORMAT function if it's autoloaded (but falls back to Lisp.format() if FORMAT isn't autoloaded yet) which is invoked by INVOKE-DEBUGGER-REPORT-CONDITION 2. the ERROR place holder Primitives.ERROR() which calls Condition.getConditionReport() The Lisp based FORMAT uses PRINT-OBJECT to print conditions. PRINT-OBJECT.lisp defines specialized instances for several classes in the condition class hieranchy. I know I added some in order to try to address the exact issue we're talking about here. The Java based Lisp.format() function uses <condition>.writeToString() to produce its output. With all these facts on the table, I think we need to do a few things to clean up the mess: - Any condition overriding getMessage() in order to call FORMAT should be removed - getMessage() should be documented *not* to use writeToString() on its own instance - getConditionReport() should be documented not to be overridden, but to override getMessage() instead (maybe declare 'final'?) - Remove all the special methods for classes derived from CONDITION in the print-object.lisp file: they should all fall back to the general method for printing conditions. - Both INVOKE-DEBUGGER-REPORT-CONDITION and Lisp.ERROR should bind the following variables to these listed values, in order to make sure conditions are printed for humans: *print-readably* nil --> all other *print-** variables bound like the values specified for WITH-STANDARD-IO-SYNTAX (except maybe *PRINT-ESCAPE*) The above looks like it should solve our issues. I'd greatly welcome any comments: it's a rather big change, judging by the description above. Ville, you were going to look at it, maybe you can verify if I'm half way right? Bye, Erik.

4 7

[armedbear-devel] Please make getStatus public (thanks :-)
by Didier Verna 18 Jan '11

18 Jan '11

Hello, could you please make the method getStatus from the class ProcessingTerminated public? One need this to mimic what the Main class/function does from /outside/ the ABCL package. Thank you! -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[armedbear-devel] Please make getStatus public (thanks :-)
by Didier Verna 18 Jan '11

18 Jan '11

Hello, could you please make the method getStatus from the class ProcessingTerminated public? One need this to mimic what the Main class/function does from /outside/ the ABCL package. Thank you! -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[armedbear-devel] Another error message enhancement request
by Blake McBride 15 Jan '11

15 Jan '11

I just got the following error: #<THREAD "http-8084-1" {41ABA945}>: Unhandled condition of type SIMPLE-ERROR: The method has the wrong number of required arguments for the generic function. Which method? I have a macro that creates many, many methods. If it gave me the method name I'd be able to track the problem easily. I am embedding ABCL in a very large web application. Starting and stopping the server takes a significant amount of time, and I have no command line access to the code. Giving me the name of the method in question could save me 30 minutes easily. Thanks. Blake McBride

1 0

[armedbear-devel] Error condition is too strong
by Blake McBride 14 Jan '11

14 Jan '11

Greetings, I am in the process of embedding ABCL into a web server application I have. While it is okay for an error to either be caught and handled, or not handled and having the thread terminate, it definitely is not okay for an error condition to kill the entire server. I am executing a (load "file") command (where "file" doesn't exist) from Java and it kills the entire server. I tried enclosing it in a try/catch block (I tried Exception & Throwable) and it still killed the server. I then replaced the load with (without a try/catch): File file = null; file.canRead(); And the error didn't kill the server. I just got a backtrace and the thread ended. (I think the error was caught higher up.) Is ABCL calling System.exit() or doing something similar? Thanks. Blake McBride

3 5

[armedbear-devel] Alex Muscar wants to stay in touch on LinkedIn
by Alex Muscar 14 Jan '11

14 Jan '11

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Alex Muscar Alex Muscar Student at Universitatea din Craiova Romania Confirm that you know Alex Muscar https://www.linkedin.com/e/-if48af-giwrckr2-4k/isd/2142627460/1VpMmRDn/ -- (c) 2010, LinkedIn Corporation

1 0

[armedbear-devel] Proposed solution to the "too many functions in FASL" problem
by Alessio Stalla 13 Jan '11

13 Jan '11

Hello all, since my merge of the less-reflection branch with trunk[1], several of you have been bitten by the new limitation in the number of functions that can be contained in a FASL. The reflection-less scheme requires creating a loader class because it needs to spell out in the bytecode all the class names corresponding to compiled Lisp functions in the FASL. Functions are numbered from 1 onwards and a method is created that is a huge switch (actually a chain of if's) that returns the right function given its index: if(index >= 1 && index < 1024) { if(index == 1) return new function_1(); if(index == 2) return new function_2(); ... } else if(index >= 1024 ... In the presence of many functions, this method grows very large, eventually surpassing the JVM's 64k method size limit. A couple of days ago Erik and I discussed a bit about the issue and how to solve it. One option is to implement method splitting for the big FASL loader method. Method splitting in general is hard (you'd need some form of CPS conversion) but in this case it's quite easy. The current scheme, though, has drawbacks: it's more complicated than it used to be, and it's not that beneficial performance-wise - from a profiling I did a while ago, its performance gains amounted to ~1% of our loading time, which is completely dominated by I/O and UTF-8 decoding. So, there's another option: go back to reflection-based loading. Using reflection has the benefit of being simpler. On certain platforms (e.g. mobile JVMs or similar, like Dalvik), reflection has a higher cost, but we currently don't run satisfactorily on those platforms anyway and we'd require multiple changes to do so. After my discussion with Erik, a further refinement of this second option came to my mind. As part of the no-reflection effort, the compiler was changed to stop emitting calls to loadCompiledFunction(className) in favor of generating `new className()` bytecode for local functions, in accordance with the goal of avoiding reflection as much as possible. A special classloader is used to both resolve those local function references, and to load the FASL loader class (and thus transitively all top-level functions). I propose keeping the compilation of local function references as it is, and thus the special classloader; and use it directly (via reflection) to load top-level functions, instead of generating one big loader method. This would result in slightly less reflection, but more importantly in a clearer function loading scheme, and less development effort compared to returning completely to the reflection-based scheme also for local functions. What do you think? If it's not clear, both Erik and I sponsor the solution of returning to a reflection-based approach, but we'd like to hear everyone's opinions. Bye, Alessio

2 4

[armedbear-devel] Recovering "special slots" after package deletion
by Erik Huelsmann 11 Jan '11

11 Jan '11

The other day, Ville and I were discussing the issue with recovery of "special slots" after package deletion on IRC. Let me start by describing the problem for you first. After that I'll describe the solution I see, however, your feedback on the solution is very much appreciated. Special symbol slots? ABCL - like SBCL and CCL - uses a thread-local array containing the 'current' values of its special variables. All symbols which have been declared or declaimed special at one point or another have been assigned an index in this array. This method allows very quick access to the special value (and hence the symbol value) with only a single level of added indirection: the symbols hold the number of their index in the array, meaning that having a reference to the symbol and the current thread is enough to find its value. When I implemented it, it was a huge difference with respect to the method we were using before. Do those need release? Since packages can be deleted, symbols be garbage collected. In the current implementation, GC-ing a special symbol will leave the slot it was assigned unused. There's no way the slot gets reassigned, because nothing keeps track of these 'dead' slots. To make matters worse: there may be huge lisp structures referenced in the dead slot, because it's also not cleared out. In the very long run, this will cause issues in scenarios as Blake describes where one creates, deletes and re-creates packages. The symbols in the packages are new symbols on every re-creation. Yet there are only 4096 spots in the special-symbols table. The solution? Well, the solution I see is to use the Object.finalize() method to release the index back to a freelist. There's a downside here though: the 4096 slots may run out before a multi-gb system sees its first GC run. There are two ways out here: grow the table once we run out of free slots (even though many potentially free slots may be pending GC). Or force a gc/runFinalization() run when running out of indices. Surely a combination of both would also be an option. Ville partially objects to the above because he's used to the pattern "you can't depend on finalize() to be invoked". Reading its documentation and googling the topic a bit, I see that finalize() can't be depended upon especially on JVM termination. However, that particular case isn't interesting here: we're looking at releasing "memory" related resources, which seems to be the exact purpose of finalize() as described in all the web docs I found. Can you comment? Is my approach as sane as I think it is? Bye, Erik.

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel January 2011