harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
Date Fri, 13 Oct 2006 14:42:57 GMT
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.

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

Weldon Washburn
Intel Middleware Products Division

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