[armedbear-devel] New fasl format: steps to success

[Erik Huelsmann]

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.