Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (hermes.apache.org: domain of pmcfirst@gmail.com designates
 209.85.132.242 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=ED9NoDHVUq9hjvTi66BgDPNbzAuu5BImNNgjiK4//++29uCfOkldEWMXGUM9vSR90j2+UrVrWUkz4OdG131TPWgbfc8Bpy/BooP4htFXWIfGuV6Ww5MKF7Qyoekp4LP3hLYMDV54HLFDhMq45setu3OJ7FQEFDcCqV2b9CfWiyU=
Message-ID: <e0f125db0703220200k7e5f6951qa359055c1cac1a2b@mail.gmail.com>
Date: Thu, 22 Mar 2007 12:00:29 +0300
From: "Pavel Pervov" <pmcfirst@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [DRLVM] what's the purpose to set NEXT_TO_HIGH_BIT_SET_MASK in
 object size?
In-Reply-To: <9623c9a50703211701xe7c8f38xb9f305e0d76c6b96@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_147784_6372051.1174554029127"
References: <9623c9a50703202224s2fc4735at5e60b32c4291648d@mail.gmail.com>
	 <9623c9a50703210459l4b81738ua89a2fd047c86c8@mail.gmail.com>
	 <e0f125db0703210526u6903c4dfq83dad7354365ca3f@mail.gmail.com>
	 <9623c9a50703210552y2e75553fn5776470780271cc1@mail.gmail.com>
	 <e0f125db0703210638q6292ed36mc4c915b099f1a189@mail.gmail.com>
	 <e0f125db0703210804x797e45bbyc4df479a929d2ab3@mail.gmail.com>
	 <9623c9a50703211701xe7c8f38xb9f305e0d76c6b96@mail.gmail.com>

------=_Part_147784_6372051.1174554029127
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_147784_6372051.1174554029127--