Compressed-OOP's on JVM‏

[Aleksey Shipilev]

On 06/30/2014 12:49 PM, Filipp Zhinkin wrote:
> On 06/30/2014 12:48 PM, Andrew Haley wrote:
>> On 28/06/14 13:21, serkan özal wrote:
>>
>>> In 64 bit JVM with compressed-oops enable and and with minimum heap
>>> size 1G and maximum heap size 1G, object references are 4 byte. In
>>> this case, compressed-oop is real native address.
>>> But in 64 bit JVM with compressed-oops enable and and with minimum
>>> heap size 4G and maximum heap size 8G, object references are 4
>>> byte. But in this case, compressed-oop is needed to be
>>> encoded/decoded (by 3 bit shifting) before getting real native
>>> address.
>>> In both of cases, compressed-oop is enable, but how can I detect
>>> compressed-oops are used as native address or are they need to be
>>> encoded/decoded ?
>> Like this:
>>
>>   $ java -Xmx1G -XX:+UnlockDiagnosticVMOptions
>> -XX:+PrintCompressedOopsMode -XX:HeapBaseMinAddress=1G -version
>>
>> heap address: 0x0000000040000000, size: 1024 MB, zero based Compressed
>> Oops, 32-bits Oops
>>
>> Narrow klass base: 0x0000000000000000, Narrow klass shift: 0
>> Compressed class space size: 1073741824 Address: 0x0000000080000000
>> Req Addr: 0x0000000080000000
>> openjdk version "1.8.0-internal"
>>
>>> If they are encoded/decoded, what is the value of bit shifting ?
> It is determined as binary logarithm of ObjectAlignmentInBytes' value.
> Default value of that option is 8 bytes, so value of bit shifting is 3.

See also:
 http://openjdk.java.net/projects/code-tools/jol/

...and specifically
 http://hg.openjdk.java.net/code-tools/jol/file/b4bc510cbad0/jol-core/src/main/java/org/openjdk/jol/util/VMSupport.java

Hotspot Serviceability Agent (SA) should be able to decode these as well
without guessing.

-Aleksey.