harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
Date Tue, 17 Oct 2006 05:31:00 GMT
Robin,
   I found your last set of comments very illuminating. Thanks.
   On your suggestion below...who would manage this object, ie., construct
and populate it, etc. before invoking the helper instance method? The jit? I
think that some of the VM specific information has started leaking into the
jit already! What if we want to attach a new JIT into Harmony/DRLVM ...what
would be the requirements for such a jit?
   Regarding the terse Java in the fastpath code, what one can do in the
fastpaths is somewhat constrained, isn't it? They are mostly
uninterruptible, shouldn't raise exceptions, cause gc etc. Our java layer in
the infrastructure is somewhat localized.

Thanks,
Rana


> On 10/15/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> >
> > Weldon Washburn wrote:
> > > Robin,
> > > I really like your thinking!  I would like to see Harmony drlvm
> > support
> > > MMTk
> > > fully.  this may take a while.  Please feel free to keep pushing to do
> > the
> > > right thing with the JIT.
> >
> > Well, with this encouragement, there are a few more things I'd like to
> > suggest:
> >
> > - Rather than make TLS access be a magic, how about defining an object
> > with fields that point to all the VM resources (such as TLS) that a
> > helper wants, and then calling the helper as an instance method of that
> > object ?
> >
> >   . If devirtualisation of this is problematic for the JIT at the
> > moment, perhaps introduce a magic pragma instead of the TLS access
> > handler
> >
> > - Mikhail's prototype Java helper looks like C transliterated into Java.
> > This is reminiscent of the very early days of JikesRVM.  IMO, you
> > should actually use Java here rather than fight it ... define an
> > abstract Allocator class, and a concrete BumpPointer instance for
> > example.
> >
> > One of the lessons of MMTk was how much you can trust the compiler, and
> > each revision uses more and more object orientation.  You guys are in an
> > ideal position, because you have control over the compiler as well as
> > the java code.
> >
> > cheers
> >
> >

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message