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 Fri, 13 Oct 2006 04:54:26 GMT
Robin,

I did a diff of the mmtk/vm directory.  It looks like nothing really changed
in the vm interface code which is good.  Am I understanding this right??

I did notice a change in utility/scan/mmtype.java.  getSlot(ObjectReference,
int) returns addr.plus(VM.ARRAY_BASE_OFFSET).... instead of
...plus(arrayOffset)...

I actually stumbled on this bug during bringup.  I replaced
...plus(arrayOffset)... with ...plus(12)...  Its a hack.  But now it looks
like I simply set ARRAY_BASE_OFFSET to 12 during <clinit>.  Does this seem
right??


On 10/12/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
>
> 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
>



-- 
Weldon Washburn
Intel Middleware Products Division

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