Reduce cap on maximum heap size?

[Florian Weimer]

* 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