From: Tim Wilkinson (tim@transvirtual.com)
Date: Tue Feb 16 1999 - 17:01:57 EST
Godmar,
I don't think we want to get into post-processing their .s output (if you've
never looked at it I'll forgive you for even suggesting this - it's pretty
awful). Handling their .o (or .so) files at load time would mean regenerating
all the class meta data from their meta data - it's not a hassel (although
they do keep changing their internals between releases) but will consume
memory. In practice we need to regenerate the class data, field data, method
data, and utf8 contants (there's have the length field which we no longer
have) - pretty much everything else is okay.
Handling the state of their classes is no big deal (Kaffe already had a state
for that so it already understands them - CSTATE_PRELOADED if your
interested).
If we're regenerating the meta-data, then we can intern the utf8 constants
(well regenerate them since they're different) so any issues there go away.
Trampolines are not a problem.
Exceptions are - I'll need to bug Alexandre about them at some point - but I
can get them to work in 'most' circumstances for the moment.
However, there are some things GCJ does which we *must* patch. They expect
any native code their classes call to be linked with the library - so they end
up with real calls to library functions. We need these entries to be blank so
we can fill them in during execution with either a KNI or JNI call. There's
no way round this except to patch GCJ at the moment.
Tim
> >
> > 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
-- Tim Wilkinson Tel: +1 510 704 1660 Transvirtual Technologies, Inc., Fax: +1 510 704 1893 Berkeley, CA, USA. Email: tim@transvirtual.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:09 EDT