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 [Fwd: Re: [DRLVM][JET] write barrier for Java (mmtk)]
Date Thu, 12 Oct 2006 04:56:12 GMT


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


Mime
View raw message