compressed oops and 64-bit header words
Coleen Phillimore - Sun Microsystems
Coleen.Phillimore at Sun.COM
Mon May 5 12:20:49 PDT 2008
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.
Vladimir Kozlov wrote:
> 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).
> Dan Grove wrote:
>> 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.
More information about the hotspot-runtime-dev