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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > -------- Original Message -------- > Subject: Re: [DRLVM][JET] write barrier for Java (mmtk) > Date: Thu, 12 Oct 2006 11:36:33 +1000 > From: Robin Garner <[EMAIL PROTECTED]> > To: harmony-dev@incubator.apache.org > References: > < [EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > < [EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED] > > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > >> For additional commands, e-mail: > [EMAIL PROTECTED] > >> > >> > > > > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Weldon Washburn Intel Middleware Products Division
-- Weldon Washburn Intel Middleware Products Division
