[armedbear-devel] Some thoughts on classloaders, inner classes and in-memory compilation

Mark Evenson evenson at panix.com
Tue Sep 22 13:13:06 UTC 2009

There is a little more to the explanation of how ABCL loads its FASLs 
that should be included for completeness, namely the use of the 
so-called init-fasl Lisp code.  For every compilation unit ("packed 
FASL") there is a section of Lisp code that is read in by the Java 
implementation of LOAD that contains forms like:

(SETQ SYSTEM:*SOURCE* #P"/Users/evenson/work/abcl/dir.lisp")

Special variables–like *TEST-PATHNAME* here–are declared, the proper 
IN-PACKAGE forms are emitted, and then forms at the end issues the 
loadCompiledFunction() calls to load all of the top-level compilands 
created by compiling "dir.lisp" which are then FSET to the proper 
functions.  It is classes like "dir-1.cls" that may contain further 
static initializers

Any new load mechanism consisting purely of Java code would have to do 
the equivalent Java side presumably in a static initializer of some 
kind.  The current implementation rather simplifies what sort of Java 
classes can exist, namely that they can only represent functions.  I 
suppose the static initializer might be able to feed a string containing 
these forms to EVAL.

Alessio's musings here are interesting, but I think there is a simpler 
solution to the problem of removing the need for intermediate temporary 
files on the filesystem by changing the behavior of 
loadCompiledFunction() to look for some sort of special variable (like 
*LOAD-TRUENAME*?) to figure out where to look for the bytes to turn a 
into a class that can be loaded by the JVM.  By "simpler solution" I 
mean something that can be worked out without drastic impact on the 
current codebase.

"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

More information about the armedbear-devel mailing list