I do think that the need to use a tool like ASM to handle the complexity of class file generation is
the primary bottleneck.
Getting rid of computing the various data structures and placing them in the correct location was
the primary reason to not even start looking at writing the class file directly. Separating out the
bytecodes in nice, but for me the constants are the most difficult part. In my case this
is due to the constant pool being a combination of values used by the jvm as parameters along with
values used directly as constants in my program. The former is handled by ASM as needed by the
jvm while the latter my compiler generates as a serialized representation of a Smalltalk constant.
It would be nice if these were separable ( and of course bytes not Strings for my constants)
I do use line numbers but I also place them in the BSMs for my debugger. The only place which
not having them may matter is within some optimizations which cause back jumps. I could recreate
these if I knew the byte code index anyway.
Since Smalltalk uses blocks quite a bit I do have more than one method in each of my class files.
Each block within the method creates an additional static method. The idea of helper methods
sounds intriguing. Since different methods can have different stack frames having a view method
would be handy as would the source code lookup and debugger helpers.
I use exceptions to handle the Smalltalk return in block ( [^foo] and Smalltalk thrown exceptions.
I do like the fiber ideas. It would be interesting to try to make the fiber idea a standard
feature. This seems like a way to get stack manipulation as well even without reification.
Ah yes, mission creep. I would be happy with a fast defineClass with the GC improvements John
mentioned.
regards
mark
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
