You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/10/10 20:11:44 UTC
[DRLVM][JET] write barrier for Java (mmtk)
I am just now getting back to the MMTk port.
Looking at MMTk code base, I see that during bootup MMTk creates an
org.mmtk.vm.VM object. The VM object contains a static field that holds an
instance of Barriers. It is called org.mmtk.vm.VM.barriers.
The complete VM declaration is:
public static final Barriers barriers;
And, of course, the instance method performWriteInBarrier() can be
devirtualized by an optimizing JIT. There is no need to improve the
performance of the write barrier in JET. Thus there is no need to change
the existing MMTk interface.
I can create something like
class MMTkInitization {
static org.mmtk.vm.VM vmBoot;
void init() {
vmBoot = new org.mmtk.vm.VM();
}
The JIT would use reflection to find vmBoot field and then find
performWriteInBarrier() entry point.
Another approach would be to add a new API to JIT/VM interface that would
return the entry point performWriteInBarrier(). Its certainly not as clean
and maintainable since its an ugly "devirtualization" hack that will break
if MMTk even wants to subclass Barriers.java
--
Weldon Washburn
Intel Middleware Products Division
Re: [DRLVM][JET] write barrier for Java (mmtk)
Posted by Weldon Washburn <we...@gmail.com>.
hmm.... we may have version skew going on here. Mikhail, Robin can we stay
with the July 14 (or there abouts) version that Steve Blackburn posted to
his web page?
On 10/11/06, Mikhail Fursov <mi...@gmail.com> wrote:
>
> On 10/11/06, Weldon Washburn <we...@gmail.com> wrote:
> >
> > Robin,
> >
> > Thanks for helping clarify the issues. The MMTk code base we are using
> is
> > what Steve Blackburn supplied us in mid July.
>
>
> Looks like 'unboxed' package from MMTk has been updated recently too. I've
> found 'Address::prefetchNTA()' op today we do not have in our version.
>
>
>
>
> --
> Mikhail Fursov
>
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [DRLVM][JET] write barrier for Java (mmtk)
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/11/06, Weldon Washburn <we...@gmail.com> wrote:
>
> Robin,
>
> Thanks for helping clarify the issues. The MMTk code base we are using is
> what Steve Blackburn supplied us in mid July.
Looks like 'unboxed' package from MMTk has been updated recently too. I've
found 'Address::prefetchNTA()' op today we do not have in our version.
--
Mikhail Fursov
Re: [DRLVM][JET] write barrier for Java (mmtk)
Posted by Weldon Washburn <we...@gmail.com>.
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.
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.
Also, please confirm (or deny) that we should never call
VM.barriers.performWriteInBarrier(). It only should be called by internal
MMTk methods (I think).
On 10/11/06, Robin Garner <ro...@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 <mi...@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 <rd...@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 <mi...@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
>
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [DRLVM][JET] write barrier for Java (mmtk)
Posted by Robin Garner <ro...@anu.edu.au>.
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 <mi...@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 <rd...@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 <mi...@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
Re: [DRLVM][JET] write barrier for Java (mmtk)
Posted by Alex Astapchuk <al...@gmail.com>.
Weldon,
I'm a bit confused what to call finally...
The previous WB4J version did a call to
org/mmtk/plan/PlanLocal::writeBarrier().
The problem was with getting an instance of PlanLocal. We solved it by
adding a stub static method PlanLocal::getPlanLocal() - just for the
sake of testing functionality.
In the latest version (HARMONY-1806) I'm doing a call to static
Barriers::performWriteInBarrier(). However, as long as this method is
presented in old MMTk javadoc, I could not find it in the MMTk/ sources
from Harmony svn.
Also, looking into MMTk/ I could not find a PlanLocal class either.
The javadoc says that writeBarrier() is only presented in xxMutator classes.
I was about to call org.mmtk.vm::barriers::writeInBarrier() but just saw
your post.
So, now I'm a in deep thoughts on which method to call and what instance
to use. :-)
Could please give me a clue?
--
Thanks,
Alex
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 <mi...@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 <rd...@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 <mi...@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
Re: [DRLVM][JET] write barrier for Java (mmtk)
Posted by Weldon Washburn <we...@gmail.com>.
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 <mi...@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 <rd...@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 <mi...@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
>
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [DRLVM][JET] write barrier for Java (mmtk)
Posted by Mikhail Fursov <mi...@gmail.com>.
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 <rd...@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 <mi...@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
Re: [DRLVM][JET] write barrier for Java (mmtk)
Posted by Rana Dasgupta <rd...@gmail.com>.
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 <mi...@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.
> > ?
> >
>
>
Re: [DRLVM][JET] write barrier for Java (mmtk)
Posted by Mikhail Fursov <mi...@gmail.com>.
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.
?
On 10/11/06, Weldon Washburn <we...@gmail.com> wrote:
>
> I am just now getting back to the MMTk port.
>
>
> Looking at MMTk code base, I see that during bootup MMTk creates an
> org.mmtk.vm.VM object. The VM object contains a static field that holds
> an
> instance of Barriers. It is called org.mmtk.vm.VM.barriers.
>
>
>
> The complete VM declaration is:
>
>
>
> public static final Barriers barriers;
>
>
>
> And, of course, the instance method performWriteInBarrier() can be
> devirtualized by an optimizing JIT. There is no need to improve the
> performance of the write barrier in JET. Thus there is no need to change
> the existing MMTk interface.
>
>
>
> I can create something like
>
>
>
> class MMTkInitization {
>
> static org.mmtk.vm.VM vmBoot;
>
>
>
> void init() {
>
> vmBoot = new org.mmtk.vm.VM();
>
> }
>
>
>
> The JIT would use reflection to find vmBoot field and then find
> performWriteInBarrier() entry point.
>
>
>
> Another approach would be to add a new API to JIT/VM interface that would
> return the entry point performWriteInBarrier(). Its certainly not as
> clean
> and maintainable since its an ugly "devirtualization" hack that will break
> if MMTk even wants to subclass Barriers.java
> --
> Weldon Washburn
> Intel Middleware Products Division
>
>
--
Mikhail Fursov