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]
