On Thu, Oct 27, 2011 at 11:59 PM, Will Dietz <span dir="ltr"><<a href="mailto:wdietz2@illinois.edu">wdietz2@illinois.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Oct 27, 2011 at 4:39 PM, Will Dietz <<a href="mailto:wdietz2@illinois.edu">wdietz2@illinois.edu</a>> wrote:<br>
>><br>
>> OK. Note that I understand the problem and have a few ideas we could<br>
>> discuss. But please do as you think would be best, and we can then talk :)<br>
>> Nicolas<br>
>><br>
><br>
> Well, if you have the time I would very much appreciate any ideas you<br>
> have.  As you said you "understand the problem" hehe (and you might<br>
> notice I'm still very much learning how this all works!) so I'm more<br>
> than happy to, uh, let you take the lead on this :).  Although I do<br>
> humbly ask that you explain briefly if you don't mind too terribly :).<br>
><br>
> Would something as simple as adding extra fields to JavaObjectClass<br>
> work? java.lang.Class *is* final and not cloneable, after all...<br>
><br>
<br>
</div>For what it's worth, the java.lang.Thread --> Thread mapping can be<br>
done with the 'eetop' field (that's what it's for!), and since it's a<br>
'long' I don't think we have to worry about GC tracing through it.<br></blockquote><div><br></div><div>Yes, good catch.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
The java.lang.ClassLoader --> JnjvmClassLoader mapping is less clear,<br>
but looks like the "classes" field would be a good candidate to abuse<br>
(it's what jamvm uses), if we added a nativetracer to avoid GC<br>
following it.<br></blockquote><div><br></div><div>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.</div>
<div> </div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
There _is_ an addClass() public method in ClassLoader that access this<br>
'classes' field, but we could override it with a native definition or<br>
similar to avoid issues (it's marked for VM use only, and isn't in the<br>
documentation: <a href="http://download.oracle.com/javase/1.5.0/docs/api/java/lang/ClassLoader.html" target="_blank">http://download.oracle.com/javase/1.5.0/docs/api/java/lang/ClassLoader.html</a>,<br>
so could probably just define it to a "what are you doing" abort<br>
path). </blockquote><div><br></div><div>Sure! If we use the 'classes' field to store the VMClassLoader, Java code should *never* use it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Still have the JavaObjectClass --> SomethingUseful mapping issue<br>
(either UserCommonClass, or the defining JnjvmClassLoader perhaps).<br></blockquote><div><br></div><div><br></div><div>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 :)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Just some more thoughts on the subject :).<br>
<font color="#888888"><br>
~Will<br>
</font></blockquote></div><br>