harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
Date Mon, 16 Oct 2006 05:12:22 GMT
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

> On 10/13/06, Robin Garner <robin.garner@anu.edu.au> wrote:
>>
>> Mikhail Fursov wrote:
>> > On 10/13/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>> >>
>> >> Why is this a problem, am I misunderstanding? Even with conventional
>> >> helpers, the jit needs to know the helper method signatures. We don't
>> >> need
>> >> to worry about universality of GC's. Any compatible GC will need to
>> >> implement  exactly the same helper fastpath contract interface as Xiao
>> >> Feng
>> >> says elsewhere.
>> >
>> >
>> > Yes. The only amendment from me is that JIT does not want to know if GC
>> is
>> > compatible or not. For example some GC developers may try to implement
>> bump
>> > pointer allocation by decrementing the offset in a block (like a stack)
>> or
>> > to do some cleaning like Ivan did.
>> > But I'm agree with you that our GCv4.1 and GC_GEN could use the same
>> > fast-path helper.
>> >
>> > I asked this question because of MMTk collectors. It has slightly
>> different
>> > format of the allocation sequence. If you look into the WB helpers you
>> see
>> > that the difference is even more than allocation one. IIRC the MMTk WB
>> > helper needs 4 params to be reported from JIT while our GC_GEN only 2.
>> > So we
>> > have to support in JIT different versions of the same helper.
>>
>> As far as the MMTk 'alloc' method goes, MMTk is simply providing
>> flexibility that you don't need to use if you don't want to.  The Java
>> helper can supply default values for alignment and allocator, and MMTk
>> won't mind.
>>
>> The barriers are slightly different.  We require the Source object,
>> target object and slot in order to a) be a substituting write barrier,
>> b) implement object-remembering barriers, c) implement reference
>> counting.  The fourth parameter differentiates between ASTORE, AASTORE
>> and PUTSTATIC barriers, and again if you only have one of these (or take
>> the same action in all cases), a hard-wired default will do.
>>
>> If there's a really good reason you can only supply slot and target,
>> some of the MMTk generational collectors (eg GenMS) will work, but some
>> of the more interesting ones like GenRC won't.
>>
>> >
>> >> I don't think that the jit  needs to know that an object being
>> >> finalizable
>> >> implies not to invoke the fastpath. This to me suggests that the jit
>> >> determines allocation policy. I don't see a problem passing the object
>> >> typeinfo or allocation handle to the helper. It is needed for object
>> init
>> >> anyway.
>> >
>> >
>> > Doing isFinalizable check during a compile time instead of runtime 
>> looks
>> > like a reasonable optimization to me.Moreover, once you want to do 
>> it in
>> > runtime, you have to add special magic isFinalizable(type). So we can
>> add
>> > such an option (configurable from the command-line or property file) to
>> the
>> > JIT.
>>
>> There are reasons why the JIT might want to - if not control, then at
>> least influence - allocation policy.  Pretenuring is one optimization
>> that comes to mind.
>>
>> One advantage of controlling allocation through method parameters is
>> that if they are statically resolvable, they are easy for the compiler
>> to optimize out after constant propagation.  Having the compiler
>> specialize code that involves (eg) looking up an allocation handle is a
>> much bigger ask than checking a bit in a parameter.  MMTk takes
>> advantage of this quite a lot - the allocation fastpath of a typical
>> plan may look impossibly heavy at first glance, but in most cases it
>> optimizes out to a handful of instructions.
>>
>> Designing the interface in a way that appears like you are dynamically
>> checking for finalizability(is that a word?), coupled with some constant
>> folding and dead code elimination can give you the best of both worlds.
>> It allows you to implement compile time optimization (in which case
>> inlining, constant folding, dead code elimination etc do the work), but
>> also gives you the opportunity to implement initially a slow way, and if
>> there are infrequent difficult cases, leave them as runtime checks.
>>
>> cheers
>>
>> -- robin
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
> 
> 


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


Mime
View raw message