Re: CodeFragment -- is it useable?

[Per Bothner <per at bothner dot com>]

Lars Clausen wrote:

>We're about to use the gnu.bytecode package[1] as a compiler backend.  A
>major part of our project is passing pieces of code around as values in a
>meta-language.  I notice there is a CodeFragment class that seems useable
>for that.  It doesn't seem to allow jumps out of the fragment, though (this
>would be what you mean by 'no non-relative jumps'?) -- are there any major
>blocks for implementing that?  Obviously, the jumps will have to be
>adjusted when the fragments are assembled, but are there some underlying
>designs that come in the way of this?
>
Well, a lot of the code assumes that once code has been generated, its 
address is
known. CodeFragment is a limited facility to generate code and defer 
emitting it
until later.  However, it is currently only used to move some exception 
handlers
to the end of a method (to avoid an extraneous goto), and so is very far 
from general.
In addition to jumps out of *or* into a fragment, I believe things will 
break if
there is any exception handler in a fragment.

Some similar toolkits instead used a linked list of Instruction objects, 
but that
means lots of small objects with lots of overhead with little benefit. 
 Instead, it would
be nice if CodeFragments were more general, and to re-write CodeAttr 
such that
CodeFragments can be easily moved, added, or deleted.  You basically need to
associate with each CodeFragment a list of "relocation" nodes.  I 
basically did
something like this when I wrote the bytecode-generating code for GCJ.  See
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/jcf-write.c?rev=1.89
The jcf_block struct corresponds to CodeFragment.  If converting this to
Java, it might be reasonable to have an abstract Relocation class, and
concrete classes for the different kinds of relocation.  The code in 
jcf-write.c
that actually takes a list of fragments and assigns them to specific 
bytecode
addresses in perform_relocations.

If you or someone wanted to change gnu-bytecode to support more general
code fragments, I would suggest converting the algorithm and data structures
in jcf-write.c to Java.  (Unless of course you have a better idea!) 
 That would be
very cool, and I'd love to have that in gnu.bytecode.  Some of the 
clients that use
gnu.bytecode might have to be changed, but I think it would be worth it. 
 One
benefit is that it would be easy to re-order the code to remove unneeded 
jumps.