[vmkit-commits] [PATCH] Update OpenJDK's classpath reflect--fix field layout and class mapping

[Will Dietz]

On Thu, Oct 27, 2011 at 4:39 PM, Will Dietz <wdietz2 at illinois.edu> wrote:
>>
>> OK. Note that I understand the problem and have a few ideas we could
>> discuss. But please do as you think would be best, and we can then talk :)
>> Nicolas
>>
>
> Well, if you have the time I would very much appreciate any ideas you
> have.  As you said you "understand the problem" hehe (and you might
> notice I'm still very much learning how this all works!) so I'm more
> than happy to, uh, let you take the lead on this :).  Although I do
> humbly ask that you explain briefly if you don't mind too terribly :).
>
> Would something as simple as adding extra fields to JavaObjectClass
> work? java.lang.Class *is* final and not cloneable, after all...
>

For what it's worth, the java.lang.Thread --> Thread mapping can be
done with the 'eetop' field (that's what it's for!), and since it's a
'long' I don't think we have to worry about GC tracing through it.

The java.lang.ClassLoader --> JnjvmClassLoader mapping is less clear,
but looks like the "classes" field would be a good candidate to abuse
(it's what jamvm uses), if we added a nativetracer to avoid GC
following it.

There _is_ an addClass() public method in ClassLoader that access this
'classes' field, but we could override it with a native definition or
similar to avoid issues (it's marked for VM use only, and isn't in the
documentation: http://download.oracle.com/javase/1.5.0/docs/api/java/lang/ClassLoader.html,
so could probably just define it to a "what are you doing" abort
path).

Still have the JavaObjectClass --> SomethingUseful mapping issue
(either UserCommonClass, or the defining JnjvmClassLoader perhaps).

Just some more thoughts on the subject :).

~Will