harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM] field_is_gc_enumerable ??
Date Wed, 07 Mar 2007 01:16:27 GMT
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 <mike.fursov@gmail.com> 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 <rdasgupt@gmail.com> 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 <xiaofeng.li@gmail.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message