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] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Date Thu, 22 Mar 2007 10:39:33 GMT
Pavel, thanks.

On 3/22/07, Pavel Pervov <pmcfirst@gmail.com> wrote:
> It is used in native override for Class.newInstance to overflow allocation
> limit in fast path and fall back to slow allocation (which ignores this bit
> set, as you've mentioned earlier). Class.newInstance is not native though
> and this code simply does not work right now.

Yes, this is the same as what I think. For this purpose, newInstance
NSO can do the same as GC alloc fast, where the checking for
constraint is done explicitly by checking gcvt info.

> The only property gc now treats as "not-possible-to-allocate-fast" is "class
> has finalize method".
> Is this correct from algorithmic POV?

Yes. Finalizer (Some GC may treat large-object in slow path as well).

> WBR,
>     Pavel.
> On 3/22/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >
> > Pavel, thanks. Since the semantic of newInstance or alloc_instance or
> > gc_alloc(_fast) itself doesn't actually use NEXT_TO_HIGH_BIT, no
> > matter it is written in Java or other languages, I think NSO will not
> > use it either. Do you think so? Or would you tell me how NSO will use
> > NEXT_TO_HIGH_BIT?
> >
> > Thanks,
> > xiaofeng
> >
> > On 3/21/07, Pavel Pervov <pmcfirst@gmail.com> wrote:
> > > "is now implemented" it was supposed to be written. :)
> > >
> > > On 3/21/07, Pavel Pervov <pmcfirst@gmail.com> wrote:
> > > >
> > > > It is indirectly used in the NSO for Class.newInstance. But this code
> > is
> > > > not currently executed, since Class.newInstance is not implemented in
> > > > Java.
> > > >
> > > > WBR,
> > > >     Pavel.
> > > > On 3/21/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > > >
> > > > > Pavel, Thanks for your reply.
> > > > >
> > > > > Would let me know how NEXT_TO_HIGH_BIT is used currently in DRLVM?
> > Or
> > > > > in other words, what functionalities are dependent on
> > > > > NEXT_TO_HIGH_BIT?
> > > > >
> > > > > Thanks,
> > > > > xiaofeng
> > > > >
> > > > > On 3/21/07, Pavel Pervov <pmcfirst@gmail.com> wrote:
> > > > > > Xiao-Feng,
> > > > > >
> > > > > > All the infructructure is in place. It is just do not work at
the
> > > > > moment.
> > > > > > As Class.newInstance is not native, NSO does not replace it's
> > > > > implementation
> > > > > > with VM's stub.
> > > > > > If NEXT_TO_HIGH_BIT-supporting code is to be removed, the rest
of
> > the
> > > > > code
> > > > > > (NSO implementations for ia32 and ia64) has to be removed
> > altogether
> > > > > to not
> > > > > > provoke any errors in the future.
> > > > > >
> > > > > > Does removing NSO overrides for Class.newInstance look reasonable
> > for
> > > > > you?
> > > > > >
> > > > > > WBR,
> > > > > >     Pavel.
> > > > > >
> > > > > > On 3/21/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > > > > > >
> > > > > > > If no one objects, I will try to remove this flag in DRLVM.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > xiaofeng
> > > > > > >
> > > > > > > On 3/21/07, Xiao-Feng Li <xiaofeng.li@gmail.com>
wrote:
> > > > > > > > Hi, the source code for class preparation calls
> > > > > > > > set_instance_data_size_constraint_bit() for three
situations:
> > > > > special
> > > > > > > > alignment requirement, having finalizer, and to be
pinned. And
> > the
> > > > > > > > comments there say the constraint bit is for GC to
understand.
> > > > > > > >
> > > > > > > > But current GC actually doesn't care about this bit,
and
> > simply
> > > > > masks
> > > > > > > > it off. Does anybody know what are the situations
for the size
> > > > > > > > constraint bit to be set for allocation?
> > > > > > > >
> > > > > > > > I recall this kind of constraint bit was ORP legacy,
when the
> > > > > > > > intention was for gc_alloc_fast to be really fast,
avoiding
> > any
> > > > > > > > special allocation treatment. So once the big flag
is set,
> > > > > > > > gc_alloc_fast will simply return NULL, and the VM
will invoke
> > > > > gc_alloc
> > > > > > > > to accomplish the allocation.
> > > > > > > >
> > > > > > > > Now DRLVM has different processing, and the GC doesn't
use the
> > > > > flag in
> > > > > > > > size for allocation. I wonder what is the real purpose
of this
> > > > > size
> > > > > > > > flag in allocation.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > xiaofeng
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Pavel Pervov,
> > > > > > Intel Enterprise Solutions Software Division
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Pavel Pervov,
> > > > Intel Enterprise Solutions Software Division
> > > >
> > >
> > >
> > >
> > > --
> > > Pavel Pervov,
> > > Intel Enterprise Solutions Software Division
> > >
> >
>
>
>
> --
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
>

Mime
View raw message