gcj and jikes

Geert Bevin gbevin@uwyn.com
Fri Apr 25 19:28:00 GMT 2003


Hi Tom,

this sounds like a very good idea. I think however that the licensing 
issues might be a major problem. It would be nice however to join the 
efforts of java source code parsing instead of having to duplicate the 
work each time for gcj. With the new features of jdk 1.5 that are 
coming up, gcj will be lagging behind and a considerable amount of 
effort will have to be done to catch up. If this can immediately be 
integrated from the next jikes release I suppose support for these new 
features will be much more easily obtained.

Just my 2c.

Btw if there's need for stupid integration work that can be done by 
someone without much knowledge of the inner architecture, I'm willing 
to help. In time I suppose I could get acquainted with more internal 
details, but for now gcj is pretty much a black box to me. I don't know 
if I can be useful, but you never know.

Best regards,

Geert

On vrijdag, apr 25, 2003, at 20:21 Europe/Brussels, Tom Tromey wrote:

> 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
>
--
Geert Bevin                       Uwyn
"Use what you need"               Lambermontlaan 148
http://www.uwyn.com               1030 Brussels
gbevin[remove] at uwyn dot com    Tel & Fax +32 2 245 41 06

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net



More information about the Java mailing list