harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Garner" <robin.gar...@anu.edu.au>
Subject Re: [DRLVM][enumeration and helper inlining] magic Address fields should not be enumerated
Date Thu, 25 Jan 2007 23:55:21 GMT
> On 1/25/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:
>> On 1/25/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>> >
>> > Mikhail, thanks.
>> >
>> > > Xiao-Feng,
>> > > JIT does not report objects with type of Address today, because JIT
>> > knows
>> > > them like UnmanagedPointers but not like Objects.
>> > > Address/Offset/Reference and other magics types could be enumerated
>> only
>> > if
>> > >
>> > > 1) We have a field of magic type.
>> > > 2) VM reports it as part of protected JNI arguments.
>> >
>> > This is reasonable.
>> >
>> > > When I wrote helpers with magics I cared not to use any of the cases
>> > above.
>> > > In the case when I have to save an address to the field I saved its
>> > 'int'
>> > > representation.
>> > >
>> > > But If we want to enable fast-path helpers on EM64T we have to
>> support
>> > at
>> > > least case 1)
>> > > I see only one solution here: GC must care about magic types and
>> sizes.
>> >
>> > In GCv5 new patch submitted by YuNan, the GChelper class has an
>> > Address field NOS_BOUNDARY. In my test, I found it's enumerated.
>> > NOS_BOUNDARY is only a return value of a JNI method, not JNI argument.
>> >
>> > What can be the reason for its being enumerated? Btw, I tested with
>> > today's SVN.
>> >
>>
>> Xiao-Feng,
>> If you changed the type of
>>    public static final int NOS_BOUNDARY = getNosBoundary();
>> to
>>    public static final Address NOS_BOUNDARY = getNosBoundary();
>>
>> there is no surprise it's enumerated because of the case 1)
>> It's not a JIT who reports it. So you can't use fields with Address type
>> before we teach VM and GC to exclude magic types from enumeration.
>
> Yes, it's not JIT's issue. I start this thread asking for
> modifications in VM enumeration code to exclude the Address field.
> People who work on this piece of code probably can help us.
>
> Thanks,
> xiaofeng

The intended semantics for Address is that it isn't enumerated at GC time
and doesn't trigger barriers.  The vmmagic ObjectReference type is a
version of an Address that *is* enumerated, triggers barriers etc.  There
should be no need to save Addresses as ints - which of course is not
64-bit safe in any case.

Sorry if this isn't clear in the vmmagic spec - I'll make sure it gets
written up.

regards,
Robin


Mime
View raw message