Re: GCJ integration

Date view Thread view Subject view Author view

From: Tim Wilkinson (tim@transvirtual.com)
Date: Tue Feb 16 1999 - 17:30:52 EST


Godmar,

They deal with first active use just like kaffe does (what a suprise!) so this is
not a problem. Actually the current GCJ doesn't even have a 'state' flag (my guess
it that they hold it in the VM somewhere else because it prevents them ROMing a
class data if they have to change the state).

Re: stubs
You really think this is a good idea? Rather than changing GCJ (which will
probably change with each release anyway) we have to generate a C++ stub for all
native code in any compiled Java code - that certainly complicates the generation
of pre-compiled libraries. Actually you don't need to generate a stub but just
need to stop the linker error (so defining the symbols in some way would be fine -
or generating a stub which does nothing would be fine).

Just so you know, the patchs to GCJ are *very* small (a few dozen lines) to get it
working with Kaffe.

Tim

Godmar Back wrote:

> >
> > 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

--
  Tim Wilkinson                         Tel:     +1 510 704 1660
  Transvirtual Technologies, Inc.,      Fax:     +1 510 704 1893
  Berkeley, CA, USA.                    Email:   tim@transvirtual.com


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:09 EDT