Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc

[Robin Garner <ro...@anu.edu.au>]

The construction of the object is probably best done by the GC itself.  VM
requests a GC context object from the GC when a new thread is created, and
calls methods on it to invoke fast path functions.

The JIT and VM can probably regard this object as totally opaque.

It's true that fast path code is somewhat constrained, it should be *what*
you do that is constrained, rather than the language constructs used to
express it.  In the MMTk fastpath code you find almost every method uses
inline/noinline pragmas, we don't use invoke interface and pay attention
to the other concerns you mention, but beyond that we pretty much write
standard Java code.  Of course it *is* carefully written to ensure that
method invocations can be devirtualised, parameters are statically
resolvable etc.  But in general we write it with clarity of expression as
the primary concern, and optimize code if it needs it.

cheers

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



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org