Using gcj as a JIT Compiler
Jeff Sturm
jsturm@one-point.com
Fri Jan 3 17:08:00 GMT 2003
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? :)
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.
> 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.
A custom object loader could:
- load .o files directly, saving the ld pass
- allocate text & data segments on the heap
- eliminate the 4k page boundaries per class
- perform text/data relocations without the need for PIC
- read debug sections and provide file/line# info in tracebacks
A library like libelf might be a good starting point.
Jeff
More information about the Java
mailing list