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 Thu, 22 Mar 2007 11:11:38 GMT
Originally, there were 4 cases when this bit was set and slow path was
taken:
1) pinned classes;
2) array of double aligned on 8-byte boundary;
3) special alignment of class instances, which is different from default GC
alignment;
4) finalizable instances.

My question is the following.

Is it correct to only treat finalizable objects specially and ignore the
rest of the cases in GCs or should constraint bit be used instead to
determine the possibility of fast allocation?

Pavel.
On 3/22/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>
> On 3/22/07, Pavel Pervov <pmcfirst@gmail.com> wrote:
> > I mean, if there were three conditions to fall back to slow allocation
> and
> > now there is only one such condition, is this right or it is the issue
> in
> > harmony code which should be fixed ASAP?
>
> Since finalizer is checked explicitly, the bit is never used at all.
> In other words, it doesn't make sense to keep the useless constraint
> bit in the code now.
>
> This constraint bit is still set in the code. It confuses people and
> requires GC to mask it to get the real allocation size.
>
> Now there is only a few places in the code base manipulating this bit
> (for nothing), it would be quite easy to remove them, unless there is
> something I missed.
>
> Thanks,
> xiaofeng
>
> > 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.
> > >
> > > The only property gc now treats as "not-possible-to-allocate-fast" is
> > > "class has finalize method".
> > > Is this correct from algorithmic POV?
> > >
> > > 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
> > >
> >
> >
> >
> > --
> > Pavel Pervov,
> > Intel Enterprise Solutions Software Division
> >
>



-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division

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