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 <robin.garner@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