After having mailed a few weeks ago about my ideas regarding a new fasl format, I'm now mailing regarding the next steps that I've come up with to implement the new scheme.

But first I'd like to mention that I've come to the conclusion that our "each function is its own class" scheme can't be entirely eliminated: since we don't use invokedynamic yet, there are only two ways to create the function objects that we still require (to stick in the symbol function slot):

1. By using the reflection API to extract the XEPs (eXternal Entry Points) from the fasl class and create a single forwarder class which calls the XEP using reflection

or 2. By still creating our multitude of classes which each implement a simple forwarder method which calls the fasl's XEP method

I'm not sure of the performance implications of either. Maybe we need to test both schemes before we decide which one would be best. My preference is with method (1), btw, if it performs on par with method (2).

So, now about the approach:

I. We need to be able to have multiple argument list parsers (the equivalent of Closure.processArgs()) in a single class --> To achieve this, we need to factor out the relevant bits from Closure.java In fact, I did that over the past week: step completed.

II. Our compiler should no longer specifically compile output to a class; we need to find a way for the COMPILE and COMPILE-FILE infrastructures to use the same basic compiler which compiles into a context provided by the respective callers. The trick here will be to develop a 'protocol' between the basic compiler and COMPILE/COMPILE-FILE which can be used to flatten the nested structure of compilands.

III. Re-enable compilation of the content of the ._ file; we used to have that, but it didn't make a difference in start-up performance, so I disabled it again. Now, we need it to prevent having as many init_xxx() routines as we have functions. After all, at this time, we currently run a mix of ._ and initialization code by intermixing class loading and ._ file execution.

IV. Develop a way to split overly big fasl classes, <clinit> (class initialization code) and <init> (constructor code) methods

V. Change the base compiler to directly link to method/class combinations when instructed to do so by their caller / through some protocol.

VI. COMPILE-FILE should start generating functions and XEPs -- within the current structure

VII. Change the file compiler to direct its output to one or a small number of fasl classes, replacing the current output classes with either one of the two options presented earlier in the mail.

Step (I) is - as mentioned - already completed. I'm envisioning steps (II) through (VI) to be done on trunk. I expect step (VII) to be associated with experimentation, which would best served by a separate branch.

Comments? Ideas? Helpers? :-)

Bye,

Erik.