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

[Nicolas Geoffray]

On Sun, Nov 6, 2011 at 8:32 AM, Will Dietz <wdietz2 at illinois.edu> wrote:

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

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.


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

Indeed. Sorry about not liking this solution :)


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

Thanks!

Nicolas


>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/vmkit-commits/attachments/20111106/1612ad87/attachment.html>