Using gcj as a JIT Compiler

Fri Jan 3 18:46:00 GMT 2003

On Fri, 3 Jan 2003, Andrew Haley wrote:
> > 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.

I've been using Ant as my testbed for -fno-assume-compiled. I'd like to
simply do:
gcj -c -fno-assume-compiled optional.jar
and have it produce something. Currently optional.jar depends on a lot of
third-party class libraries. (It almost works now... field and method
references need to go to the constant pool to be linked at runtime.)
Ditto for Eclipse.
> > - load .o files directly, saving the ld pass
>> Um, okay. It would have to do most of the work ld does, though.

Well, weren't you talking about replacing parts of ld.so? However you
look at it, the current ELF tools are inadequate for Java's linking model.
> > - perform text/data relocations without the need for PIC
>> It's better to have PIC; it makes sharing between processes easier.

and code slower... something to keep in mind as long as you are
benchmarking alongside other JITs. Size vs. speed. Let the user choose.
> 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.

Heh. If only that were true... libtool might never have existed.
Jeff