harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [Fwd: Re: [DRLVM][JET] write barrier for Java (mmtk)]
Date Thu, 12 Oct 2006 23:38:05 GMT
Robin,
This helps a bunch.  Thanks!  I have downloded
http://cs.anu.edu.au/people/Robin.Garner/mmtk-20061012.jar  and will move to
it now.



On 10/11/06, Robin Garner <robin.garner@anu.edu.au> wrote:
>
>
>
> -------- Original Message --------
> Subject: Re: [DRLVM][JET] write barrier for Java (mmtk)
> Date: Thu, 12 Oct 2006 11:36:33 +1000
> From: Robin Garner <Robin.Garner@anu.edu.au>
> To: harmony-dev@incubator.apache.org
> References:
> <4dd1f3f00610101111v715702ecybe960ddf17032756@mail.gmail.com>
> <bc79dd600610101127l5ce8c938k4cca509ac639f73c@mail.gmail.com>
> <51d555c70610101319p5aa81a32g54ebd87c2445dc50@mail.gmail.com>
> <bc79dd600610102254j2aab08e6uc849aaf517e69456@mail.gmail.com>
> <4dd1f3f00610102318n61f025ffu81d0efbdd55f4a51@mail.gmail.com>
> <452CADC2.9000408@anu.edu.au>
> <4dd1f3f00610110712i502e441al250e63a341076c7e@mail.gmail.com>
>
> Weldon Washburn wrote:
> > 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.
>
> My impression was that Steve's advance release to you included the
> refactoring into MutatorContext and CollectorContext. It's been pretty
> stable (wrt major refactorings) since then.
>
> My recollection is that writeBarrier hasn't been a method of Plan since
> mid 2005 when Daniel Frampton and I refactored and created PlanLocal.
> Could you double check ??
>
> > 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.
>
> No.  Each java thread needs a MutatorContext (or more precisely the
> correct sub-type for the given plan) for each thread, and a
> CollectorContext for each GC thread.  Logically, the objects Plan,
> MutatorContext, CollectorContaxt, Trace and TraceLocal comprise a plan.
>
> > Also, please confirm (or deny) that we should never call
> > VM.barriers.performWriteInBarrier().  It only should be called by
> > internal
> > MMTk methods (I think).
>
> Confirmed.  Well you could call it, but it just does a store without
> invoking a write barrier.  Rarely what you want outside of MMTk internals.
>
> > 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
> >>
> >>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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