From: Godmar Back (gback@cs.utah.edu)
Date: Sat Dec 19 1998 - 19:42:47 EST
The unhand macro comes from Sun. It is useful to hide the layout
of the Java object from the C code. For instance, Sun uses handles for
their objects (unlike kaffe), and so unhand actually has more work to do.
If we ever decided to switch to handles, we would benefit from keeping
the unhand(). I'm definitely in favor of it.
I think that is the reasoning here, though I might be wrong and Sun
also uses it only to hide the internals of the beginning of the object
(which could cache locks, hold a dtable pointer etc.)
In general, however, unhand() is as deprecated as stubs are.
New native library code that is not performance-critical should use
JNI instead. Note that this does definitely not apply to java.lang.String.
In fact, you could write java.lang.String as a 100% native class ---
it would be really interesting to see how that would perform.
(Horrible in the interpreter, I know, but using the jit it should pay off.)
- Godmar
>
> Godmar Back writes:
> > > I don't see "interned" ever being set anywhere... ie, this is a
> > > bug. It looks like the fix is to add "interned" to java_lang_String.h
> > > and set it to true in internJavaString().
> >
> > Yes, this looks like another victim of the last TVT merge.
>
> OK, I'll fix it.
>
> > > Also, why does java_lang_String.h have this structure "data"?
> > > Why can't java_lang_String.h just be equal to the output of kaffeh?
> > > Is this some kind of holdover from long ago?
> >
> > Possibly. I'd say try a kaffeh-generated file and see where this gets
> > you with string.c.
>
> Ah, now I see.. each class's 'additional fields' beyond those
> inherited from java.lang.Object are defined in their own sub-structure.
> So this "data" structure is real, it's just invisibly declared by
> the HandleTo() macro.
>
> Which brings up the question, what purpose does having a nested
> structure serve? It just seems to force adding a bunch of "unhand()"
> macros everywhere. Wouldn't it be cleaner if the structure directly
> corresponded to the class fields, and we got rid of the need for
> unhand()? Is field alignment a concern?
>
> > I just tried CaffeineMark 3.0, and kaffe's string score is weaker than
> > FreeBsd's jdk port 1.1.6... So short of breaking it, there's no damage
> > you can do to string handling in kaffe.
>
> Good.. :-)
>
> -Archie
>
> ___________________________________________________________________________
> Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
>
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:24 EDT