8024927: Nashorn performance regression with CompressedOops
goetz.lindenmaier at sap.com
Fri Oct 25 05:22:21 PDT 2013
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
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
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
/|\ /|\ /|\
| | |
klass space | heap
space to extend
> 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!
More information about the hotspot-dev