8024927: Nashorn performance regression with CompressedOops

[Lindenmaier, Goetz]

Hi Colleen,



thanks a lot for the extensive explanations and adopting that name!



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

OK, I understand.  But the VM should know that it runs with CDS,

and could choose a common base if running without.  But well, that

increases the test-space even more.



> 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!

No, you definitely don't want the subtraction for oops (if there is shladd or the like).



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

Compressed oops are treated as 32-bit positive offsets.  They are loaded

as unsigned ints (zero extended) and then added to the base.

You could treat the compressed klasses as singed ints, load them

signextended and then add them to the base.  If only negative

ints are used, this addresses the part before the base.  But there

are only 2g negative (signed) offset, while there are 4g positive ones.

On sparc you would use ldsw for compressed classes, lduw for

compressed oops.



I think there would be enough space for extending the compressed

class space to higher addresses, if you  layout the spaces like this

(assuming shift 3):



0        base-16G             base                          base+32G

|------------|xxxxxx------------|xxxxxxxxxxxxxxxxxxxxxxx-------|-------------------...

               /|\      /|\             /|\

                |        |               |

        klass space      |               heap

                     space to extend

                       klass space





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

I understand.  I'll benchmark the two variants once I implemented your

change on PPC. Maybe it really makes no big difference.

If the compressed classes compete with other spaces for the lower bits

also benchmarking will have to make the decision, I guess.



Thanks for all the comments!



Best regards,

  Goetz.