John Keiser wrote:
>
> First off, something fishy is going on ... I'm not getting this message on
> the Japhar list, just Classpath. Am I still on that list, after the recent
> list changes?
>
hmm.. i got the message twice.. i'll ask vern if he's noticing anything
funky.
>
> > I would like Classpath to change it's DLL names from javaio and
> > javalang, to classpath_io and classpath_lang. That way I can localize
> > the required Classpath change to DLL_findAlongPath().
> >
>
> Remember, though: we have to load *both* your "lang" and ours, and both your
> "reflect" and ours. We have the VM-independent portion of lang sitting up
> in Classpath, and also VM-independent reflect. Then there are the
> cp.java.lang and cp.java.lang.reflect dirs. Only with the union of the
> Japhar+Classpath lang do we have all the lang and reflect functions. Thus,
> even if we change javaio to classpath_io (which is just fine), there still
> need to be two separate loads for lang in DLL_loadSystemLibraries(). One
> yours, one ours.
There is a way to get around having to load both libs in
DLL_loadSystemLibraries (something I'd like to avoid as well.) Japhar
can load the classpath lib for the VM-independent portion of lang (or
whichever package.) static initializers in this package would get a
property from java.lang.System (java.vm, which the JVM would initialize
- 'japhar' for Japhar, and 'kaffe' for Kaffe.) The VM independent
portion would build up some lib name and load the additional native libs
there (in the static initializers.)
That way, we only have to make a minimal change to the
DLL_loadSystemLibraries (if any) and classpath gets more flexibility for
free.
> Not that I mind a name change to classpath_*. That would probably be a good
> thing. It should probably just be classpath_javalang, not classpath_lang.
>
> > Could Classpath change name on the following variables, to keep them
> > the same as JDK?
> >
> > java.lang.Class declaringClass -> clazz
> > java.lang.String len -> count
> > str -> value
> > java.lang.Throwable message -> detailMessage
> > java.lang.Thread privateInfo -> PrivateInfo
> >
>
> I am wary of making any changes deliberately to give compatibility with
> private and package-protected members and/or classes from Sun. It is an
> explicit step away from cleanroom. I am not a lawyer, though. I think we
> should defer to Paul and his FSF buddies on this one, or anyone who really
> knows the law on this.
i seriously doubt that you'll have any problem. lesstif uses a much
more aggressive strategy, and we have yet to have any problems with it.
> > BTW: One checks for NULL pointers _before_, not after it is used.
> > Have a look at objects.c:cache_fields() and try again. :-)
> >
>
> static void cache_fields(JNIEnv * env) {
> int i;
> class_clazzfile = find_class(env, "java/lang/Class");
> for(i=0;i<class_clazzfile->num_fields;i++) {
> if(!strcmp(class_clazzfile->fields[i]->name, "private_data"))
> private_data_field = (jfieldID)class_clazzfile->fields[i];
> else if(!strcmp(class_clazzfile->fields[i]->name, "superclass"))
> superclass_field = (jfieldID)class_clazzfile->fields[i];
> else if(!strcmp(class_clazzfile->fields[i]->name, "name"))
> name_field = (jfieldID)class_clazzfile->fields[i];
> else if(!strcmp(class_clazzfile->fields[i]->name, "signers"))
> signers_field = (jfieldID)class_clazzfile->fields[i];
> }
> assert(class_clazzfile != 0);
> assert(private_data_field != 0);
> assert(superclass_field != 0);
> assert(name_field != 0);
> assert(signers_field != 0);
> }
>
> If you look in the caller: "if(private_data_field == NULL)
> { cache_fields(); }". The check happens in the caller, not the callee.
> It's a silly optimization to avoid the method call. I spent too much time
> with my head in assembly code a few years back. If you think it's better to
> put it into the method, be my guest :)
I think what petter is pointing out is the assert(class_clazzfile != 0);
after many lines with "class_classfile->"
> > Why do you do the caching in objects.c, and are you sure it is save to
> > cache this info?
> >
>
> Well, it'd be best to cache it wherever you guys are caching the ClazzFile *
> for Class, String and Object. I just don't know where that is. All field
> and methodIDs that are used by the core should be cached somewhere.
I agree with this, I just don't think they should be cached in the JVM.
> I do the caching because searching for these fields is very slow (a total of
> 10 string compares) and I want speed in the JVM. I don't mind if you want
> to use find_class every time, I just think it's a waste of taxpayer CPU
> cycles :) It would also involve monitors, another thing I like to minimize,
> for the same performance reasons. Caching it with class, string and object
> would be best.
find_class is one thing - I don't have any problem with caching classes
that have been loaded. Checking for particular field names is another
matter entirely. Japhar doesn't do this (except in the fake array
classes we generate and the fake Class field we create since we know
what the offsets are.)
I don't expect core classes to be changing all that often, but I would
really like it if the same version of japhar could be used with multiple
versions of classpath just by replacing the .zip and .so's.
Japhar really shouldn't have to worry about field names in given classes
-- all that should be dealt with in either java or native code within
classpath. There are perhaps a few sticky examples, but I'd really like
to minimize the changes to japhar necessary to get classpath running.
Also, since the JDK1.2 apparently errors out when creating the second
(or later VM's), caching fields in static variables inside native libs
is legal (and, I suppose, desirable - I'm finally breaking down :) This
should obviate the need for the caching of fields in the VM.
xtoph
