harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM] field_is_gc_enumerable ??
Date Wed, 07 Mar 2007 01:27:30 GMT
Alexey, I think it's probably good idea to add field_is_reference()
and field_is_magic(), to replace the field_is_gc_enumerable()
interface, since it gives the user of the interfaces more flexibility
and probably future-proof. Then we have:

bool field_is_enumerable_reference()
{
  return  field_is_reference() && !field_is_magic();
}

This function can be implemented by GC itself if it wants to abstract
it. As you mentioned, if its only customer is GC module, there is no
need to put it in the general interface.

There is no need to implement field_is_primitive() because it's
!field_is_reference().

How do you think?

Thanks,
xiaofeng

On 3/7/07, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> Apparently field_is_gc_enumerable() has it's customers, and reasonably
> shields them from unrelated low-level details - be it magics or some
> other vm-injected data. I'm OK to rename it to
> field_is_enumerable_reference() or any other name which is considered
> more descriptive.
> And what purpose do you see for the plain accessor
> field_is_reference()? Do we need field_is_primitive() and/or
> field_is_magic() also? Note there is already field_get_descriptor()
> which basically provides this kind of info. If we have no clear
> usecase, I'd prefer to keep interface smaller.
>
> --
> Alexey
>
> 2007/3/6, Rana Dasgupta <rdasgupt@gmail.com>:
> > I don't have a strong opinion. But is_reference is a field sematic, it may
> > not matter who consumes it at the moment. Also, not implementing an
> > interface is OK, but not because noone needs it, it is a constraint of the
> > implementer. That's valid, but in that case, one needs to go away from
> > Boolean and support a NOT_IMPLEMENT return value also. Sorry if I am
> > sounding convoluted.
> >
> > Rana
> >
> >
> > 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
> > >
> >
>

Mime
View raw message