8024927: Nashorn performance regression with CompressedOops

[Coleen Phillimore]

On 10/25/2013 8:22 AM, Lindenmaier, Goetz wrote:
>
> Hi Colleen,
>
> thanks a lot for the extensive explanations and adopting that name!
>

Thank you for the suggestion.

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

We make that decision afterwards, unfortunately so there'd have to be a 
bit of rearrangment.
>
> > 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
>

Thanks for the picture.  It helps!

This would require that we always have a base, right?

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

Goetz, we welcome your experimenting with this!  I think there is a lot 
of room for new ideas.  We also want to (someday) make the markOop part 
of the header smaller too, where in brainstorming we think we might need 
to allocate things in the lower 4G memory.

Thanks,
Coleen

> Thanks for all the comments!
>
> Best regards,
>
>   Goetz.
>