harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Date Wed, 21 Mar 2007 12:26:32 GMT

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?


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

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