Alessio Stalla writes:
Let's start by describing how abcl works now. Every piece of code in the JVM needs to be contained in a method of some class, so when abcl compiles a function it produces - surprise - a class, or better, a stream of bytes that the JVM knows how to interpret to create a class.
This already seem counterintuitive to me. Consider this: (defun f(x) (lambda (y)(+ y x))) I hope that (f 1) does not have to create a new class. I hope that it creates a new "object" that is a member of a class that is only created once. Furthermore, a form like the defun above when interpreted does not have to create a new class, does it? It creates a new object of the class interpreted-function containing an fdefinition slot (field? member? whatever you call those data items in a class) which is a lisp object like (lambda(x)(lambda(y)(+ y x))).
I would hope that there is also a class compiled-function containing as one of its slots a byte code vector. Then the result of compiling a function in memory or loading a compiled function would be an instance of this compiled-function class. I see no need for subclasses of that class.
Classes produced by the compiler extend a common abcl class providing the methods that will be used to actually invoke the function; the
I argue that there is no need for the compiler to create new classes. It sould do something like new compiledFunction(byteCodeVector)
compiler, among other things, will override some of those methods. When using the runtime compiler, the class is immediately loaded; when using the file compiler, it is stored on the filesystem for later use. So far, nothing requires temporary files to work. However, a Lisp function can contain nested functions introduced with FLET or LABELS, and those have to be compiled to classes as well.
Into additional objects of type compiled-function, still not requiring any new classes.
Does this model violate any requirements of Java? Does java already have a class of compiled code objects that could be used, i.e., where creating a vector full of byte codes gives you something that can be directly executed? (Or maybe it has to go through some verifier first?) Would this approach solve all of your problems related to class loaders and temporary files? Maybe it would solve some other problems that you've not yet mentioned?