8024927: Nashorn performance regression with CompressedOops

[Coleen Phillimore]

Hi Goetz,

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

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

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

> 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