harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
Date Tue, 17 Oct 2006 08:21:26 GMT
I agree with Robin and Rana both.
IMO we should move with small steps and support helpers inlining first as
Rana said. (Actually this is a big intercomponent task)
After we run primitive 'magic' code safely and we have an experience with
'magics' it will be the time to refactor and take into account everything
Robin proposed.

As for the task status: I'm going post 2 new threads today: "Java annotation
access interface" and "Details on implementation of slow helpers(native)
calls from Java". I have a local prototype ready, but it should be discussed
before adding to JIRA.


On 10/17/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>
> 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
> > >
> > >
>
>


-- 
Mikhail Fursov

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