I don't fully understand how MMTk vmmagic is being used. The bottom line is drlvm needs to either respect the design rules regarding "Uninterruptible" and vmmagics or relable/mutate vmmagic to some other name. For example, globally replace magic with hyRawPtr.
Briefly, "Uninterruptible" allows type-unsafe pointer arithmetic to happen in Java code by simply turning off the GC. By design the GC can't ever see a magic field. For the sake of code maintenace, please preserve this convention. On 3/6/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
field_is_reference() was used only in GC and was not used by other code. This is the reason why original 'field_is_reference' was not kept. We can rename 'field_is_gc_enumerable' to 'field_is_enumerable_reference' and do not implement field_is_reference() method (unless someone needs it). Does it makes sense? As for me both names are good. field_is_magic_addr() does not look good to me. It has too many details about magics in its name, while the only knowledge we need today is to know if to enumerate a field or not. On 3/6/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > Good point. In fact, field attributes seem better connected to field > semantics, not to GC requirements directly. Is it possible to retain > field_is_reference() and add a field_is_magic_addr() ? Though there is an > implied inefficiency here, the semantics seem clearer.Are there other > magic > field types that could interfere? > > Thanks, > Rana > > > On 3/6/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > > Hi, I found field_is_reference in original vm.h was changed to be > > field_is_gc_enumerable. The declaration is: > > > > /** > > * @return <code>TRUE</code> if the field must be enumerated by GC > > * > > * This function doesn't cause resolution of the class of the field. > > */ > > VMEXPORT Boolean field_is_gc_enumerable(Field_Handle fh); > > > > > > I wonder what is the rationality to make this interface change. > > > > From reading the code, I guess this change was made due to the > > implementation Magics. With Magics, a reference field may not always > > be enumerated by the VM during garbage collection, such as Address > > field in a Java helper. To change the function name to be > > "field_is_gc_enumerable" might help the reader to know this fact. > > > > But I think this doesn't actually help, since the user of this > > function will be confused about the type of the field, and need to > > guess what kind of field is "gc enumerable". More importantly, the > > semantics of this function are unclear: it hard-encodes the > > Magics-related semantics into the low-level field accessors. > > > > I would suggest to keep the original field_is_reference interface > > function in this vm.h file. It clearly tells if a field is reference > > type. If we really want the field_is_gc_enumerable interface, we can > > add it as a new one. We can use a new name like > > "field_is_enumerable_reference", which is probably clearer. > > > > How about it? > > > > Thanks, > > xiaofeng > > > -- Mikhail Fursov
-- Weldon Washburn Intel Enterprise Solutions Software Division
