compressed oops and 64-bit header words

[Dan Grove]

Hi Colleen-

I'm not  worried about the shift instruction - I agree that it's
unlikely to matter. What I am worried about is have the standard
object header have 2 64-bit words in (well, 1 64-bit word, 1 32-bit
word, and 32 bits of pad).

What I'm worried about is the increase in memory footprint and its
impact on performance. I was pointed to
http://ieeexplore.ieee.org/iel5/9012/28612/01281667.pdf?arnumber=1281667
, which (conveniently) breaks out the performance impact of
compressing the header versus compressing references versus both.

So what I would really be interested would be a way to have both the
pointers/words in the header and the oops be 32 bits. I think this
would be a good win, when coupled with the extra registers when using
the 64-bit ABI.

Dan

On Mon, May 5, 2008 at 3:47 PM, Coleen Phillimore
<Coleen.Phillimore at sun.com> wrote:
>
>  Hi,
>  It made sense when I first read it but in order to have 32 bit pointers in
> #3, I can't imagine not having to encode and decode them by some heap base
> in order to dereference these pointers, so the only difference between #2
> and #3 is the shift instruction to get to 32G.  We didn't believe that the
> shift causes much of a performance penalty so we didn't implement it this
> way.  We would like to measure this at some point though, and if it is
> faster could add this mode fairly easily.
>
>  thanks!
>  Coleen
>
>
>
>  Dan Grove wrote:
>
> > Thanks Colleen and Vladimir-
> >
> > What I'm wondering is whether there could be a third mode:
> >
> > 1. > 32GB - uses uncompressed pointers
> > 2. (something less than 4GB) < Xmx < 32GB - uses compressed pointers
> > (along with 64-bit mark word), 64-bit ABI
> > 3. whole app fits in 4GB - uses 32-bit pointers in heap, but 64-bit ABI.
> >
> > The idea here is that I'd prefer to pay no penalty over 32-bit when my
> > app runs in 64-bit mode and the app fits in 4GB of memory (my reason
> > for this is that I want to support our JNI libraries only in 64-bit
> > mode, and deprecate the 32-bit JNI libraries).
> >
> > Does this make any sense to you?
> >
> > Dan
> >
> > On Mon, May 5, 2008 at 12:20 PM, Coleen Phillimore - Sun Microsystems
> > <Coleen.Phillimore at sun.com> wrote:
> >
> >
> > >  Actually, we are using the gap for a field and array length in the code
> > > now, but the code Vladimir showed me makes the allocation code a lot
> cleaner
> > > for the instance field case.
> > >
> > >  In the array case in 64 bits, compressing the _klass pointer into 32
> bits
> > > allows us to move the _length field into the other 32 bits, which
> because of
> > > alignment saves 64 bits.  There was a 32 bit alignment gap after the
> _length
> > > field, if not compressed with the klass pointer.
> > >
> > >  The mark word can also contain a forwarding pointer used during GC, so
> > > can't be 32 bits.
> > >
> > >  The compression that we use allows for 32G because we shift into the
> least
> > > significant bits - the algorithm is (ptr-heap_base)>>3.
> > >
> > >  Coleen
> > >
> > >
> > >
> > >  Vladimir Kozlov wrote:
> > >
> > >
> > >
> > > > Dan,
> > > >
> > > > Only the mark word is 64 bits. The klass pointer is 32-bits but
> > > > in the current implementation the gap after klass is not used.
> > > >
> > > > I am working on to use the gap for a field or array's length.
> > > >
> > > > The mark word may contain a 64-bits tread pointer (for Biased
> Locking).
> > > >
> > > > Thanks,
> > > > Vladimir
> > > >
> > > > Dan Grove wrote:
> > > >
> > > >
> > > >
> > > > > Hi-
> > > > >
> > > > > I talked some with the Nikolay Igotti about compressed oops in
> > > > > OpenJDK7. He tells me that the mark word and class pointer remain 64
> > > > > bits when compressed oops are being used. It seems that this leaves
> a
> > > > > fair amount of the bloat in place when moving from 32->64 bits.
> > > > >
> > > > > I'm interesting in deprecating 32-bit VM's at my employer at some
> > > > > point. Doing this is going to require that 64-bit VM's have as
> little
> > > > > bloat as possible. Has there been any consideration of making the
> mark
> > > > > word and class pointer 32 bits in cases where the VM fits within
> 4GB?
> > > > > It seems like this would be a major win. A second benefit here is
> that
> > > > > the "add and shift" currently required on dereference of compressed
> > > > > oops could be eliminated in cases where the VM fit inside 4GB.
> > > > >
> > > > > Dan
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>