harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Astapchuk <alex.astapc...@gmail.com>
Subject Re: [DRLVM][JET] write barrier for Java (mmtk)
Date Wed, 11 Oct 2006 08:08:28 GMT
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 <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


Mime
View raw message