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 12:35:15 GMT
On 3/22/07, Pavel Pervov <pmcfirst@gmail.com> wrote:
> 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

Pavel,  all the three GCs in DRLVM run perfect. I think the design is
correct. Don't you think so?

> or should constraint bit be used instead to
> determine the possibility of fast allocation?

Not necessarily. Constraint bit is an old design. It's not the only
way to force slow-path allocation. For example, we don't use the bit
for finalizer check in existing GCs.

Actually for fast-path allocation in jitted code, the check for
finalizer can even be removed as well, since that can be checked by
JIT beforehand.

Anyway, I don't insist on removing the bit in DRLVM if you think it's
valuable. I suggest it be clearly documented as a contract between VM
and GC.

Thanks,
xiaofeng

> 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
View raw message