Re: Using gcj as a JIT Compiler

[aph at cambridge dot redhat dot com (Andrew Haley)]

Jeff Sturm writes:
 > On Thu, 2 Jan 2003, Andrew Haley wrote:
 > > You may find this interesting.  On the other hand, you may find it
 > > totally horrible!
 > 
 > Can it be both? :)

It sure can.

 > I don't think this is absurd.  I think a similar technique would be
 > useful for ahead-of-time compilation... run the code and let the
 > JIT discover what classes are needed, then link the cached objects
 > into a final executable.

Right.  With Eclipse, for example, we know that some classfiles will
never link but then Eclipse never tries to load them.  Come to think
of it, this might be a good technique for building Eclipse.  
Aieee...  :-)

 > > Alternatively, if we could persuade ld.so to load a DSO without
 > > resolving all of its references we could always use direct calls.
 > > We'd need to split ld.so so that loading a DSO and resolving its
 > > references were separate actions.
 > 
 > How difficult could it be for libgcj to implement its own loader?  Surely
 > less effort than an entire JIT would be.

Maybe.

 > A custom object loader could:
 > 
 > - load .o files directly, saving the ld pass

Um, okay.  It would have to do most of the work ld does, though.

 > - allocate text & data segments on the heap
 > - eliminate the 4k page boundaries per class
 > - perform text/data relocations without the need for PIC

It's better to have PIC; it makes sharing between processes easier.

 > - read debug sections and provide file/line# info in tracebacks
 > 
 > A library like libelf might be a good starting point.

The big disadvantge of all this from my POV is that it's be hard to do
this portably.  Simply calling gcj, as, and ld is portable.

Andrew.