8024927: Nashorn performance regression with CompressedOops
goetz.lindenmaier at sap.com
Thu Oct 24 02:16:55 PDT 2013
I appreciate this change a lot.
As you touch this anyways, I would propose to rename NarrowOopHeapMax
to UnscaledOopHeapMax. Narrow is also used in contexts where scaling is
required, thus I find this is a misleading name for the 4G boundary.
The following are my more general thoughts about this issue, not directly
to be considered by this change:
I think especially maintaining two different bases as in the current approach
is expensive. Wouldn't it be feasible to use the same base for both spaces
(oops and classes)? The class space could be placed below the base, so that
decompression requires a subtraction. This would be a bit more expensive
on platforms where shladd exists, but loading the two bases is much more
Alternatively one could use negative compressed classes, loading them
with sign extension. This would require that the sign bit is set, effectively
limiting the compressed class space to halve of the heap.
For big heaps one could even think of putting the class space into the
lower regions so that no base is needed.
One would end up with four configurations:
Oop space class space
Small: no base no base
Medium: no base base
Big: base no base
XXXL: base base
This should all be compatible with extending the compressed class space.
There should be a natural upper bound to class space given the heap size,
At least (2*class space) < heap should hold.
From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore
Sent: Donnerstag, 24. Oktober 2013 06:04
To: hotspot-dev Source Developers
Subject: RFR: 8024927: Nashorn performance regression with CompressedOops
Summary: Allocate compressed class space at end of Java heap. For small
heap sizes, without CDS, reserve some space under 32G so compressed
classes can have the same (more favorable) compression algorithm as oops.
This change may have to be reverted when we implement extending
compressed class spaces in the future, but it gets back the performance
of these nashorn benchmarks, and seems to make sense for small heaps.
open webrev at http://cr.openjdk.java.net/~coleenp/8024927/
bug link https://bugs.openjdk.java.net/browse/JDK-8024927
Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64
solaris/x64 and windows/x64 (in progress). Also running refworkload.
More information about the hotspot-dev