Experiences using GCJ as an embedded compiler

Mon Mar 29 12:31:00 GMT 1999

>>>>> "Jon" == Jon Olson <olson@mmsi.com> writes:

Jon> 1) Lightweight exceptions
For gcc changes you really have to contact the egcs list. While we in
the Java group do some work on gcc, we have to go through the same
process as anybody else to change parts of gcc outside of the java
directory.
Jon> 2) Write barriers
Ditto here.
Jon> Fortunately, write-barriers were relatively simple to add to
Jon> GCC. The following code, added to `gcc/expr.c', invokes a
Jon> new `write_barrier' RTL pattern whenever it writes a pointer
Jon> to memory.
Does this include register spills and other writes to the stack?
Jon> 4) 64-bit code
Jon> GCJ generates pretty bad code for many 64-bit operations.
Is this a gcc problem or specific to the gcj front end?
Jon> 5) Size of compiled metadata
I don't have time to look at this one today, but I'll keep it around
for a future read.
Jon> 6) Interface calling mechanism
Jon> Currently, the GCJ compiler generates the following run-time
Jon> call to lookup the native code for a given Java interface.
Jon> Instead, I propose that GCJ layout vtables for each
Jon> interface and, at compile time, determine the interface and
Jon> vtable index being invoked. Thus, the above run-time
Jon> interface would change to:
I believe Per has some plans to change how interface invocations are
handled. I don't recall the details. We're all in agreement that the
current implementation is too slow.
It sounds like you've done a lot of work. Cool stuff.
If you're planning to push some of these changes back into gcc/gcj,
you'll have to get paperwork signed with the FSF. You can see what
you'll need here:
	http://egcs.cygnus.com/contribute.html
Tom