Reduce cap on maximum heap size?
fweimer at bfk.de
Thu Nov 10 05:50:21 PST 2011
* Tony Printezis:
> compressed oops should have similar performance to the 32-bit JVM in
> most situations (you lose some given that the JVM still uses 64-bit
> references, you gain some given that 64-bit architectures typically
> have more registers available to the JIT compiler).
There used to be several variants of compressed oops: zero-based
unscaled, zero-based scaled, and offseted and scaled, depending on where
the heap segment is located in the process address space. The
zero-based unscaled encoding does not need an address decoding step and
should therefore be faster. However, that is only possible if the heap
fits within the lowest 4 GB, which is never the case for a 12 GB heap.
For example, one of our tools runs like this (median on five runs,
including startup time):
-Xmx1g 4194ms (6184ms user+system)
default 4428ms (6620ms user+system)
-Xmx40g 4351ms (6232ms user+system)
(The old generation is never collected, even with the 1GB heap.)
I understand that there is a difficult trade-off, but increasing the
default heap size to scaled compressed oops seems to have its costs.
Florian Weimer <fweimer at bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
More information about the hotspot-dev