Compressed-OOP's on JVM‏

[Bernd Eckenfels]

Hello,

JOL does print out the C-OOPs characteristics. It is printed with
VMSupport#vmDetails().

I think there are a lot of heuristics used, for
hotspot it queries getVMOptions() on the HotSpotDiagnotic MBean with
"UseCompressedOops" and "ObjectAlignmentInBytes" options.

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

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

Gruss
Bernd

 Am Sun, 29
Jun 2014 00:28:48 +0300 schrieb serkan özal <serkanozal86 at hotmail.com>:

> Thanks Bernd,
> How can I check it programmatically?
> 
> > Date: Sat, 28 Jun 2014 19:36:21 +0200
> > From: bernd-2014 at eckenfels.net
> > To: serkanozal86 at hotmail.com
> > CC: hotspot-gc-use at openjdk.java.net
> > Subject: Re: Compressed-OOP's on JVM‏
> > 
> > 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 
>