harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [DRLVM] MMTk write barrier -- questions about which writeBarrier() API to use
Date Thu, 15 Jun 2006 07:02:54 GMT
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,

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

View raw message