You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Xiao-Feng Li <xi...@gmail.com> on 2007/03/21 06:24:57 UTC
[DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
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
Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 3/22/07, Pavel Pervov <pm...@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 <xi...@gmail.com> wrote:
> >
> > On 3/22/07, Pavel Pervov <pm...@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 <pm...@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 <xi...@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 <xi...@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 <pm...@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 <xi...@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
>
Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Posted by Pavel Pervov <pm...@gmail.com>.
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 <xi...@gmail.com> wrote:
>
> On 3/22/07, Pavel Pervov <pm...@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 <pm...@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 <xi...@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 <xi...@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 <pm...@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 <xi...@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
Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 3/22/07, Pavel Pervov <pm...@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 <pm...@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 <xi...@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 <xi...@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 <pm...@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 <xi...@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
>
Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Posted by Pavel Pervov <pm...@gmail.com>.
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?
On 3/22/07, Pavel Pervov <pm...@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 <xi...@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 <xi...@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 <pm...@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 <xi...@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
Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Posted by Xiao-Feng Li <xi...@gmail.com>.
Pavel, thanks.
On 3/22/07, Pavel Pervov <pm...@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 <xi...@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 <pm...@gmail.com> wrote:
> > > "is now implemented" it was supposed to be written. :)
> > >
> > > On 3/21/07, Pavel Pervov <pm...@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 <xi...@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 <pm...@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 <xi...@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 <xi...@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
>
Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Posted by Pavel Pervov <pm...@gmail.com>.
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 <xi...@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 <pm...@gmail.com> wrote:
> > "is now implemented" it was supposed to be written. :)
> >
> > On 3/21/07, Pavel Pervov <pm...@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 <xi...@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 <pm...@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 <xi...@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 <xi...@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
Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <pm...@gmail.com> wrote:
> "is now implemented" it was supposed to be written. :)
>
> On 3/21/07, Pavel Pervov <pm...@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 <xi...@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 <pm...@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 <xi...@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 <xi...@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
>
Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Posted by Pavel Pervov <pm...@gmail.com>.
"is now implemented" it was supposed to be written. :)
On 3/21/07, Pavel Pervov <pm...@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 <xi...@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 <pm...@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 <xi...@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 <xi...@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
Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Posted by Pavel Pervov <pm...@gmail.com>.
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 <xi...@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 <pm...@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 <xi...@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 <xi...@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
Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <pm...@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 <xi...@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 <xi...@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
>
Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Posted by Pavel Pervov <pm...@gmail.com>.
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 <xi...@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 <xi...@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
Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in object size?
Posted by Xiao-Feng Li <xi...@gmail.com>.
If no one objects, I will try to remove this flag in DRLVM.
Thanks,
xiaofeng
On 3/21/07, Xiao-Feng Li <xi...@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
>