8024927: Nashorn performance regression with CompressedOops
coleen.phillimore at oracle.com
Thu Oct 24 07:31:13 PDT 2013
Thank you for looking at this code.
On 10/24/2013 5:16 AM, Lindenmaier, Goetz wrote:
> 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.
Ok. I made this change. I reverted the change to globalDefinitions.hpp
so UnscaledOopHeapMax is in universe.cpp only. It seems to read better
in the code.
> 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
We implemented two different bases to support CDS which is independent
of the Java heap and has to have a fixed address. While it's not
something we have in the documentation yet, you can use CDS with -server
with 64 bits. But there's a bit more work we need to do to provide a
class list and with performance. But this is why we chose the 2 base
Also, if we add the ability to mmap more compressed class spaces, we
need to mmap at higher addresses, so if the single base was between the
java heap and the compressed class space, the java heap would have the
subtraction. I suppose this is possible. We have to go up because
solaris malloc needs lower addresses. All of the new features we talk
about want to have the lower addresses too!
> 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.
Hmm. I don't get it.
> 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.
See above though, we're trying to avoid making things go in lower heap
so we have space for other things we will want in the future in lower
heap. Also, through benchmarking (obviously we didnt' run these ones)
we found there wasn't a lot of expense with the second base.
The change I really wanted to do is have a near-class/far-class
implementation and we can put the near classes in lower heap in a much
smaller space. And the near classes are fixed size. The prototype I
did, where near-class was just a pointer to Klass, had 8% performance
regression with javac and would probably be slower with these nashorn
tests too. But they had some nice properties where you could predict
the size of the class metaspace from number of classes, didn't interact
with the CDS address (only pointers to what we stored in CDS), and
didn't fragment. The main performance problem I had was with compiler
calls through vtables, which we are supposed to avoid and I should
measure that prototype against these tests.
Thank you for the thoughts and comments.
> Best regards,
> -----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.
More information about the hotspot-dev