Weldon Washburn wrote:
All,
Perhas the MMTk crowd knows the answer to the following questions.
Can I simply not use
org.mmtk.plan.PlanLocal.writeBarrier(ObjectReference src, Address
slot, ObjectReference tgt, Offset metaDataA, int metaDataB, int
mode);?
Instead, I want to only use writeBarrier(ObjectReference src, Offset
srcOffset, ObjectReference dst, Offset dstOffset, int bytes);. Will
this be a problem?
The two writebarriers are for separate cases. The first is a putfield
write barrier, the second is a special case for a reference array copy.
Questions about the incoming args:
ObjectReference src
From the JITs perspective, an ObjectReference is indistinguishable
from a java.lang.Object. Is this true? False?
Yes, but MMTk assumes that its target language is not necessarily Java.
An ObjectReference is a pointer to a heap object, whatever that may be
in the language being managed.
Address slot
When is "Address slot" argument actually created? Does this Address
object live long enough such that its "value" field needs to be
updated following a copying GC? Is the answer the same for both Jikes
and the Rotor ports?
A write barrier should never be invoked on an object that is being
copied. An Address is an unboxed type, so objects of that type are
never created.
Offset srcOffset
In DRLVM, the classloader resolves a field offset once and it never
changes. Does it make sense for the classloader to create all the
Offset objects during load time? Initially, I want to create these
objects _outside_ the formal java heap to have tight control over
object movement and deletion. Basically, I don't want the Offset
object to ever move or ever be deleted during the initial stages of
MMTk integration.
Offset objects are never created. Think of an offset as a primitive
type with methods.
A question about how jikesrvm-2.4.4/MMTk handles objects that are not
inside the offical heap. Are these objects simply ignored? I know
that ECMA CLI spec requires that objects which are not in the official
heap must be ignored. I simply don't know if this requirement is
incorporated in 2.4.4/MMTk source base.
Any object that MMTk encounters must be in the heap that it manages. In
JikesRVM/MMTk, there are a minimum of 4 regions of the heap, VM,
Immortal, LOS and then any plan-specific region. I think the objects
you are referring to would be in the VM space ???
While it looks like a lot of work to get DRLVM to generate Offset
object properly, it looks like even a bigger job to modify MMTk to
replace Offset class with an "int" that holds a given field's offset.
Any opinions on this statement?
Not true, IMO. The JikesRVM compiler replaces Offset "objects" with a
primitive type of the natural word length of the machine.
Hope this helps,
Robin
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
