gnu.bytecode GSoC Project using ObjectWeb ASM

[Tom Bousso <tombousso@gmail.com>]

Hi all,

I'm Tom and I'm working on implementing Kawa's gnu/bytecode library on
top of ObjectWeb ASM for this year's GSoC. gnu/bytecode is the JVM
bytecode generation library which Kawa uses
(https://www.gnu.org/software/kawa/api/gnu/bytecode/package-summary.html).

Currently, gnu/bytecode generates classfiles from scratch (i.e. it
creates classfiles byte by byte). ASM is a popular and well-maintained
bytecode manipulation/generation library. By using ASM in
gnu/bytecode, we will significantly reduce gnu/bytecode's complexity.
gnu/bytecode will no longer need to worry about the binary format of
classfiles, and instead it can focus on the abstractions which make it
a great library. It will be easier to add new features to the new
version of gnu/bytecode because much of the work will be handled by
ASM. For example, gnu/bytecode doesn't currently have an
emitInvokeDynamic method, and implementing this method is not trivial.
In the new version of gnu/bytecode, implementing an emitInvokeDynamic
method is very trivial because we can just call ASM's
visitInvokeDynamicInsn method. And if any new attributes are added to
the classfile specifications, we won't need to implement their binary
formats - we'll just call ASM.

There are a few downsides to using ASM in gnu/bytecode. For example,
gnu/bytecode has a few complex features which reorder bytecode, and
ASM's APIs don't support this, so we'll have to use gotos instead.
Also we still don't know how fast the new gnu/bytecode will run
compared to the old one.

Overall, I think that ASM has a lot to offer gnu/bytecode. If all goes
well, we can hope to see Kawa Scheme running with the new gnu/bytecode
by the end of the summer, and then the new gnu/bytecode can be merged
into Kawa. The new gnu/bytecode is being developed at
https://gitlab.com/tombousso/gnu-bytecode2.

All feedback is welcome.

-Tom Bousso