Weldon Washburn wrote:
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??
That sounds about right. And (famous last words) I think the interface
will probably remain stable for a
Weldon Washburn wrote:
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??
By the way, the array base offset may differ
On 10/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
By the way, the array base offset may differ depending on the platform and
array type.
As as I know, currently on 32 bit platform (ia32) the array base offset
is 12 for types of size = 4.
Double[] and long[] arrays have array base offset 16.
Urgh. In that case the array base offset should be specified in the
constructor of an MMType - JikesRVM doesn't have this problem, because the
object pointer always points to element 0 of an array irrespective of
header sizes and alignment issues (and hence the align and offset
parameters to
Salikh,
Good catch! You just saved the MMTk port 20 hours of debugging. Thank you
:)
On 10/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
I actually stumbled on this bug during bringup. I replaced
...plus(arrayOffset)... with ...plus(12)... Its a hack. But now
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
:
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
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
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
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
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
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 [EMAIL PROTECTED] wrote:
On 10/11/06, Weldon Washburn [EMAIL PROTECTED] wrote:
Robin,
Thanks for
Original Message
Subject: Re: [DRLVM][JET] write barrier for Java (mmtk)
Date: Thu, 12 Oct 2006 11:18:20 +1000
From: Robin Garner [EMAIL PROTECTED]
To: harmony-dev@incubator.apache.org
References:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED
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
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
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
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
17 matches
Mail list logo
