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

Reply via email to