harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [DRLVM] field_is_gc_enumerable ??
Date Tue, 06 Mar 2007 15:43:29 GMT
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
>

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