gcj and jikes

[Andrew Haley <aph at redhat dot com>]

Tom Tromey writes:
 > 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.

Sounds good.

 > 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).

I can't say that I believe this to be very important.

 > 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.

Yes, we can generate all the debug info we need from lines and
variable scopes.  The class file has full type info, of course.

The problem that bothers me is divergence.  For example, I want to do
something with Generic Java ASAP, and I suppose I'd have to keep both
Jikes and gcj up to date.

 > 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.

Ah.  Oh.  Darn.

Andrew.