harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [DRLVM][enumeration and helper inlining] magic Address fields should not be enumerated
Date Thu, 25 Jan 2007 12:57:56 GMT
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.

-- 
Mikhail Fursov

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