[kaffe] Re: GCJ and Kaffe

[Godmar Back]

Patrick wrote a while ago:
> 
> Jim wrote:
> > I'd also like to see if we "plug in" and execute pre-compiled
> > objects built with gcj.
> 
> FYI, Godmar had this somewhat working sometime in late 2000 (maybe?).
> Getting the Kaffe and GCJ exception mechanisms to play nicely together
> was, I believe, the last remaining major hurdle.  GCJ has probably
> changed sufficiently to have added some more hurdles.
> 

No, the exception stuff actually worked.  It was ugly and operated
with the internals of DWARF2 processing in libgcc.a, but it worked.
Specifically, it required faking stack unwinding information,
which wasn't that hard because Kaffe's JIT is so simple.
This stuff is checked in and it's the reason why you probably
all build with --disable-gcj (unless somebody removed it already)

The problem I eventually gave up on was Kaffe's broken locking system,
as discussed on this list.

The old stuff I did operated under the assumption that there would be
no cooperation from the gcj team and that users will not install a
kaffe-specific version of gcc/gcj on their machines.
As a result, I created shadow structures for all metadata, and faked
some structures the precompiled code relied on.
This was essentially a big hack and maintaining it over versions of
gcj would have been a major nightmare too.

Tim Wilkinson had tried it a while before and in his approach he had 
hacked gcj to produce kaffe-compatible metadata.  This was with a
very old version of kaffe, however.

I'm not sure what the best way of doing this is.  I can see two possible
goals: either going about providing a jit for gcj, or allowing kaffe to 
precompile things, such as its libraries.  
In the first case, you'd probably throw out kaffe's libraries and
interface with gcj's libraries, ultimately you'd probably only use its
jit.  Which seems silly.  The other way would likely require your own 
version of gcc.  Which means hacking gcj. 

Either goal involves a lot of work.

	- Godmar