gcj and jikes

[Tom Tromey <tromey at redhat dot com>]

Last night I checked out the jikes source and looked through it a bit.

I think it would be fairly easy to attach the jikes front end to gcj.
This would be a vast improvement, since jikes is much better at
parsing the Java language; for instance, jikes can compile Eclipse,
whereas gcj cannot.

Jikes represents most things at a pretty high level until it actually
starts generating bytecode.  So, we would just write our own generator
which would generate GENERIC trees from jikes' internal representation
(thus solving the tree-ssa problem as well).  The main difficulty here
would be that the gcc headers and such almost certainly aren't
C++-friendly.  So, we'd have to either fix them or write C helper
functions.

The gcj bytecode generator has some advantages over the one in jikes.
gcj has a 2-pass generator that processes relocations in a second
pass.  So, where jikes will sometimes guess whether it needs a wide
opcode, gcj never will.  Also, gcj can only generate dead code in
certain pathological situations.  Porting the important parts of the
gcj bytecode generator to jikes would be fairly straightforward, and
in fact we could use the opportunity to get rid of the few remaining
dead code generation problems (by reference counting basic blocks).

To do an excellent job we'd also want to change the error output to
conform to GNU standards.  That shouldn't be very difficult, either.


The biggest technical barrier I can see is representing debug info.
Unfortunately this is an area I don't know very much about, so I'm not
sure what we need out of a front end.  Is information about variables
and the starts of lines enough?  Jikes already has that represented
internally, since that is the debug info in a .class file.


The non-technical barrier is licensing.  jikes is under the IBM public
license.  We'd probably have to get some sort of special dispensation
from RMS (and/or IBM) to do this.

Tom