On Sun, Nov 6, 2011 at 8:32 AM, 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 Fri, Nov 4, 2011 at 4:57 PM, Nicolas Geoffray<br>
<<a href="mailto:nicolas.geoffray@gmail.com">nicolas.geoffray@gmail.com</a>> wrote:<br>
> Don't you need to fix java.lang.String also?<br>
><br>
<br>
</div>Hmm, I'd imagine so-- good call.  Strange this didn't break anything<br>
terribly :).<br></blockquote><div><br></div><div>I think they are used for debugging and logging in MMTk, so as long as you weren't printing things, you may not use the generated strings at all.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
> There is a problem if we don't add the extra fields in LLVM's struct: the<br>
> object will be emitted in the executable, and won't be big enough to contain<br>
> the two extra fields.<br>
<br>
</div>Bah, okay.  That sort of thing was why my previous (otherwise hacky)<br>
patch for adding extra fields was useful--LLVMInfo would do the right<br>
thing.<br></blockquote><div><br></div><div>Indeed. Sorry about not liking this solution :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
However, I like your idea below of trying to ditch emitting Class in<br>
AOT entirely, I'll give it a go.<br></blockquote><div><br></div><div>Thanks!</div><div><br></div><div>Nicolas</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
> I think we should drop emitting java.lang.Class instances in AOT, because it<br>
> does not work with a precise GC. When compiling MMTk (which should be the<br>
> only user of AOT without a precise GC), we could be able to just emit null<br>
> there. Could you try and confirm?<br>
<br>
</div>Will do.<br>
<div class="im"><br>
> If it turns out it does not work, we could also try to put a dummy<br>
> java.lang.Object or java.lang.Class, following the object layout but without<br>
> containing any data. In any case, your change in vmjcAddPrecompiledClass<br>
> should be removed.<br>
><br>
<br>
</div>Okay, will give this a go if the above doesn't pan out.<br>
<div class="im"><br>
>>   cl->classLoader = JCL;<br>
>> +  // Ensure the Class mapping field is set properly.<br>
>> +  // (Needed for OpenJDK, since this mapping isn't part of the Class<br>
>> type)<br>
>> +  JavaObjectClass::setClass((JavaObjectClass*)cl->getDelegatee(),cl);<br>
><br>
> Did you actually run some code that failed because of this not being set?<br>
><br>
>><br>
<br>
</div>Sorta.  I ran into failures in the precompiler (presumably due to MMTk<br>
as you mention), so never made it to any actual code without fixing<br>
the mapping one way or the other.<br>
<br>
Anyway, I'll look into the ideas you mention above and report back :).<br>
<br>
Thanks!<br>
<span class="HOEnZb"><font color="#888888"><br>
~Will<br>
</font></span></blockquote></div><br>