[vmkit-commits] [PATCH] Refactor AOT into ClassLib-specific components, add support for OpenJDK

[Will Dietz]

On Fri, Nov 4, 2011 at 4:57 PM, Nicolas Geoffray
<nicolas.geoffray at gmail.com> wrote:
> Don't you need to fix java.lang.String also?
>

Hmm, I'd imagine so-- good call.  Strange this didn't break anything
terribly :).

> There is a problem if we don't add the extra fields in LLVM's struct: the
> object will be emitted in the executable, and won't be big enough to contain
> the two extra fields.

Bah, okay.  That sort of thing was why my previous (otherwise hacky)
patch for adding extra fields was useful--LLVMInfo would do the right
thing.

However, I like your idea below of trying to ditch emitting Class in
AOT entirely, I'll give it a go.

> I think we should drop emitting java.lang.Class instances in AOT, because it
> does not work with a precise GC. When compiling MMTk (which should be the
> only user of AOT without a precise GC), we could be able to just emit null
> there. Could you try and confirm?

Will do.

> If it turns out it does not work, we could also try to put a dummy
> java.lang.Object or java.lang.Class, following the object layout but without
> containing any data. In any case, your change in vmjcAddPrecompiledClass
> should be removed.
>

Okay, will give this a go if the above doesn't pan out.

>>   cl->classLoader = JCL;
>> +  // Ensure the Class mapping field is set properly.
>> +  // (Needed for OpenJDK, since this mapping isn't part of the Class
>> type)
>> +  JavaObjectClass::setClass((JavaObjectClass*)cl->getDelegatee(),cl);
>
> Did you actually run some code that failed because of this not being set?
>
>>

Sorta.  I ran into failures in the precompiler (presumably due to MMTk
as you mention), so never made it to any actual code without fixing
the mapping one way or the other.

Anyway, I'll look into the ideas you mention above and report back :).

Thanks!

~Will