Compressed-OOP's on JVM‏

[Bernd Eckenfels]

Hello,

you can use -XX:+PrintCompressedOopsMode like this:

> java.exe -Xmx1960m-XX:+UnlockDiagnosticVMOptions
> -XX:+PrintCompressedOopsMode -version
heap address: 0x0000000080600000, size: 2042 MB, zero based Compressed
Oops, 32-bits Oops java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
> java.exe -Xmx1970m-XX:+UnlockDiagnosticVMOptions
> -XX:+PrintCompressedOopsMode -version
heap address: 0x000000077fc00000, size: 2052 MB, zero based Compressed
Oops
> java.exe -Xmx26g-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -version
heap address: 0x000000017ae00000, size: 26706 MB, zero based Compressed
Oops
> java.exe -Xmx27g-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -version
Protected page at the reserved heap base: 0x000000013f3e0000 / 65536
bytes heap address: 0x000000013f3f0000, size: 27730 MB, Compressed Oops
with base: 0x000000013f3ef000
> java.exe -Xmx31g-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -version
Protected page at the reserved heap base: 0x000000013f7a0000 / 65536
bytes heap address: 0x000000013f7b0000, size: 31826 MB, Compressed Oops
with base: 0x000000013f7af000
> java.exe -Xmx32g-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -version
java version "1.7.0_25"

The last one does not use C-OOPs.

Gruss
Bernd

PS: please dont spam so many lists simulatanously with user questions.
It not only bothers a lot of people, it also makes the target for a
followup discussion hard to figure out.

Am Sat, 28 Jun 2014 15:21:15 +0300
schrieb serkan özal <serkanozal86 at hotmail.com>:

> Hi all,
> As you know, sometimes, although compressed-oops are used, if java
> heap size < 4Gb and it can be moved into low virtual address space
> (below 4Gb) then compressed oops can be used without
> encoding/decoding.
> (https://wikis.oracle.com/display/HotSpotInternals/CompressedOops) 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 ? If they are
> encoded/decoded, what is the value of bit shifting ? Thanks in
> advance. -- Serkan ÖZAL