[armedbear-devel] Generating class files instead of functions-as-class-files

Erik Huelsmann ehuels at gmail.com
Sun Apr 18 11:49:04 UTC 2010


Over the past months, I've been thinking about changing the way we
generate our class files. Currently all of our class file generation
is centered around producing a execute() method, with a constructor to
support object initialization.

This scheme seriously limits our flexibility. Imagine a function of 2
arguments, one required and one optional. Currently, we require a call
to fastProcessArgs(), where we could have done with a class which
implements the single as well as the two-argument execute() methods.

Along the same lines, I'm looking to clean up our constructors: In my
ideal world all the static field initializers will be moved to the
class constructor <clinit>() which isn't called more than exactly
once.

To support this type of output, I started jvm-class-file.lisp. It's a
file which centers around generation of true class files (with
arbitrary numbers of methods), instead of "functions-as-classes" which
are modelled using exactly 2 methods. The jvm-class-file.lisp file is
local to my working copy for now, although I did send a version to
Alessio some time ago.


Apart from the flexibility this would achieve, I think I have another
benefit: it would allow catching the full class file before it's a
serialized. The resulting in-memory class file representation could be
analysed, for example to find the stack inconsistencies we're looking
(but not yet finding).

There are serveral reasons to send this mail:

1. To keep you all in the loop
2. To see about your comments regarding the above direction
3. To see if there's anybody here who wants to help out

As a general direction forward, I was thinking to start a branch so
that there's some place to store my currently-private
jvm-class-file.lisp. I'll have to create a BRANCH-README to document
what the branch is about, what the status is and what is left to be
done.

The first step forward, I'd like to do on the trunk however: a first
separation of code generation and class file writing. That would allow
me to write a GUI tool for inspecting the resulting class files from a
single COMPILE call and hence creating a tool which should help
finding our "stack inconsistency" problems.


Comments? Helpers?


Bye,


Erik.




More information about the armedbear-devel mailing list