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][JET] write barrier for Java (mmtk)
Date Wed, 11 Oct 2006 14:12:18 GMT
Robin,

Thanks for helping clarify the issues.  The MMTk code base we are using is
what Steve Blackburn supplied us in mid July.  I don't know when it will be
suggested we move to a more recent version of MMTk.  I suspect a major part
of the confusion has been because of working with a code base where the Plan
interface is in transition.

In any case, please confirm that each java thread needs to put an instance
of Plan in its thread-local storage and that writeBarrier() and alloc()
virtual method entry points need to be materialized from thread-local Plan
object.

Also, please confirm (or deny) that we should never call
VM.barriers.performWriteInBarrier().  It only should be called by internal
MMTk methods (I think).




On 10/11/06, Robin Garner <robin.garner@anu.edu.au> wrote:
>
> I think you must be looking at a fairly old version of MMTk.
> writeBarrier is an instance method of a MutatorContext (in org.mmtk.plan).
>
> MutatorContext exists to hold unsynchronized thread-local data
> structures.  Particularly relevant to the write barrier, each mutator
> context has its own thread-local remset.  All of the mutator context
> methods of MMTk need fast access to the MMTk thread local data
> structures, which is why they are instance methods.  The other critical
> instance method of a MutatorContext is 'alloc', which also has it's
> thread-local chunk of the space(s) it allocates into.
>
> As far as the VM is concerned, it will be calling instance methods of a
> final class.  The various classes in org.mmtk.plan.* aren't final, but
> the VM interface code is expected to wrap the currently selected plan in
> some final class.  JikesRVM wraps the currently selected plan classes
> in a 'SelectedPlan', 'SelectedMutatorContext' etc.
>
> As far as the VM.barriers.performWriteInBarrier() call is concerned,
> the optimization required to devirtualize a call to a final method of a
> static final field shouldn't be too hard to implement.  MMTk recently
> moved away from using static methods for this part of the interface, to
> the current abstract factory, and improved the structure of the software
> significantly.  We don't want to go back!
>
> >                                  I erroneously thought we could call
> > VM.barriers.performWriteInBarrier() directly.  This sort of, kind of
> breaks
> > MMTk architecture.
>
> well, it less 'breaks the architecture' than performs a no-op :)
>
> -- robin
>
> Weldon Washburn wrote:
> > Ooops.  I really tangled things up.  You are right about how we are
> > supposed
> > to find the Java write barrier method.  It is located in
> > Plan.writeBarrier().
> > Each GC algorithm has a Plan class that overrides the writeBarrier()
> > method.  I erroneously thought we could call
> > VM.barriers.performWriteInBarrier() directly.  This sort of, kind of
> breaks
> > MMTk architecture.  By design, each GC algorithm in MMTk is supposed to
> > call
> > Plan.writeBarrier() which, in turn, will call
> > VM.barriers.performWriteInBarrier.
> >
> > Sorry for the confusion.
> >
> >
> >
> >
> > On 10/10/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> >>
> >> Yes, we can run the usual inliner after helpers are inlined.
> >> The only problem I want to notice is that once we have different
> helpers
> >> for
> >> different GCs it's a bad idea to use virtual method calls in
> performance
> >> sensitive helpers. You are allowed to do it, but the better solution
> >> is to
> >> teach the helper to use a final implementation of the Barrier and
> replace
> >> the helper once the implementation of the Barrier class is changed.
> >>
> >> On 10/11/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> >> >
> >> > Makes sense, using a standard barrier invocation fastpath. But I
> assume
> >> > that
> >> > the MMTk WB helper that it will call needs to be inlined too.
> >> >
> >> > Thanks
> >> >
> >> >
> >> > On 10/10/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> >> > >
> >> > > Weldon,
> >> > > > I thought about slightly different approach.
> >> > > > Why not to write fast-path VM helper like was proposed in the
> >> thread
> >> > > > "[drlvm]Extending..."
> >> > > > This helper (a static method) can be inlined by JIT without any
> >> > > > devirtualization and call any method needed from MMTk or native
> >> > > > implementation. So JIT won't know if it works with MMTk or with
a
> >> > native
> >> > > > GC:
> >> > > > all you need is just to replace the Java version of the helper.
> >> > > > ?
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >> --
> >> Mikhail Fursov
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> 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

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