compressed oops and 64-bit header words

[Coleen Phillimore - Sun Microsystems]

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