Compressed-OOP's on JVM
Filipp Zhinkin
filipp.zhinkin at oracle.com
Mon Jun 30 08:49:57 UTC 2014
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.
Regards,
Filipp.
> I'm not sure what this refers to.
>
> Andrew.
More information about the hotspot-dev
mailing list