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

[Nicolas Geoffray]

On Thu, Oct 27, 2011 at 11:59 PM, Will Dietz <wdietz2 at illinois.edu> wrote:

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

Yes, good catch.


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

The VMClassLoader which is a VM defined GC object in JnjvmClassLoader.h is
the perfect candidate for that. In GNU Classpath, I use "vmdata" which is an
object. The fact that the ClassLoader Java class can be subclassed makes it
difficult to hijack the tracer.

What is the type of this 'classes' object? If it's not Object, it will kind
of make me nervous, but I believe we could live with 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).


Sure! If we use the 'classes' field to store the VMClassLoader, Java code
should *never* use it.


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


Yeah, this one is annoying. But since java.lang.Class is final (as you
noticed), we can extend the layout of the object by adding a field (and
making sure the internal 'j3::Class' knows about this change), and hijacking
the tracer. Yes, as easy as that :)


>
> Just some more thoughts on the subject :).
>
> ~Will
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/vmkit-commits/attachments/20111028/9ebda2b9/attachment.html>