8024927: Nashorn performance regression with CompressedOops

[Lindenmaier, Goetz]

Hi Coleen, 

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
expensive.  
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.

Best regards,
  Goetz.



-----Original Message-----
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.

Thanks,
Coleen