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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Weldon Washburn Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
