From: Godmar Back (gback@cs.utah.edu)
Date: Tue Feb 16 1999 - 16:49:22 EST
>
> Okay, as you may have just seen I've check in the intial stab at
> GCJ integration (from the Custom edition where I did the orignal work).
> This doesn't work yet for a number of issues which should be resolved
> first.
>
> So ... basically these boil down to an either or choice for changes to
> GCJ itself - if we want GCJ to generate compatible structures to Kaffe
> (they're close but not quite the same) then we need to patch the EGCS
> compiler. The advantages of this are that we can directly use what
> GCJ produces in Kaffe with the minimum of load-time work.
>
> On the other hand if we don't change GCJ we basically have to regenerate
> the class/method/field structures when we load a GCJ class (we get to
> use the code but that's it) - even the utf8 constants are different.
> This means we use extra memory.
>
> That's basically the choices - comments?
>
For practical reasons, I'm for changing Kaffe rather than egcs.
Alternatively, for providing a filter to egcs output, be it .o files
or .S files.
I do not believe that a conversion of data structures at load-time
is too big of an impediment. What would that mean in practice? That
they put a bunch of data definitions in the .data section of their .o
files, we have to parse them and create kaffe-internal structures?
A potentially bigger problem seems to be consistency. I.e., we need to
keep ours and theirs in sync. That would apply to the state a class is in,
for instance (i.e., whether it's been initialized or not).
What's different about the utf8constants? The actual data should be the
same, the header may be different(?) We could change that easily, I
think. But would they then still be interned? Would comparing utf8's
by comparing their address still work?
What about the problems with trampolines and exceptions you mentioned?
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:09 EDT