From: Godmar Back (gback@cs.utah.edu)
Date: Tue Feb 16 1999 - 17:12:19 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
I was actually thinking more of using BFD or BDF or whatever it's called:
a library to manipulate object files purportedly used some GNU tools.
> 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.
We can reintroduce the length field; no problem.
Do they intern their utf8consts? How do they compare them?
I'm getting some numbers on memory for class metadata right now.
I'll report when I have them.
>
> 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).
That's not what I mean. What I mean is storing whether you've executed
the static {} initializer already, i.e., whether a class has had what the
JLS calls its "first active use". This is important, semantically.
(I just looked at this. This is what I mean:
void
_Jv_InitClass(Hjava_lang_Class* type)
{
errorInfo err;
if (type->state != CSTATE_COMPLETE) {
processClass(type, CSTATE_COMPLETE, &err);
}
}
)
But I guess if gcj code never checks type->state directly (i.e., if they
always call _Jv_InitClass before what constitutes an active use), then
that's not a problem.
>
> 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.
Can you not resurrect stubs for this?
I'm not sure I understand this. Say you precompile java.lang.System,
which has a native call to initProperties0 in its static initializer.
gcj requires that you have a library functions with that name that
uses a different calling convention than KNI/JNI, correct?
So couldn't we just create one with kaffeh, compile it, and link it to
the .so file?
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:09 EDT