You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/06/05 21:04:03 UTC
[DRLVM] MMTk write barrier -- questions about which writeBarrier() API to use
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?
Questions about the incoming args:
ObjectReference src
>From the JITs perspective, an ObjectReference is indistinguishable
from a java.lang.Object. Is this true? False?
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?
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.
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.
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?
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [DRLVM] MMTk write barrier -- questions about which writeBarrier() API to use
Posted by Weldon Washburn <we...@gmail.com>.
Robin,
Thanks. The below helps. I reread the unboxed package. It now makes
much more sense. I think I finally understand it. Sorry for being so
dense. Please tell me if the following is correct:
For 32-bit machine, instances of class Address are simply 32-bit integers.
//the jit intentionally breaks the type system and assigns the first
argument, obj1, to the location holding oref
// the jit sees oref as a regular java object, oref will be gc enumerated
ObjectReference oref = ObjectReference.fromObject(obj1);
//the jit sees adr as an int, oref.toAddress() is an intrinsic method
// that simply takes the "this" ptr and moves it to the
//32-bit int location containing adr
//adr is never gc enumerated
Address adr = oref.toAddress();
On 6/15/06, Robin Garner <ro...@anu.edu.au> wrote:
> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [DRLVM] MMTk write barrier -- questions about which writeBarrier()
API to use
Posted by Robin Garner <ro...@anu.edu.au>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org