RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2]

[Richard Reingruber]

On Fri, 18 Dec 2020 10:12:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   In largeHeapAbove32GTest we have a klass shift of 3 on OSX too.
>
> src/hotspot/share/memory/metaspace.cpp line 706:
> 
>> 704:     ReservedSpace rs;
>> 705: 
>> 706:     // If UseCompressedOops=1 and the java heap has been placed in coops-friendly
> 
> s/has/had

I'm using [present perfect](https://en.wikipedia.org/wiki/Present_perfect). You suggest to use past perfect (aka [pluperfect](https://en.wikipedia.org/wiki/Pluperfect)). Is that correct so far? If so, then I'd think present perfect is the better fit, isn't it?

Note also: the current comment uses the same tense, and it was you who's added it :)

> src/hotspot/share/memory/metaspace.cpp line 710:
> 
>> 708:     //  right above the java heap.
>> 709:     // Otherwise the lower 32G are still free. We try to place ccs at the lowest
>> 710:     // allowed mapping address for efficient encoding of compressed class pointers.
> 
> `for efficient encoding of compressed class pointers` I'd reformulate this. Both cases are done to efficiently encode narrow class pointers. We place ccs atop of the heap in the hope of piggybacking its efficient allocation.
> 
> Either I would leave the statement out, since it is somewhat obvious from the context, or I would put it atop of the comment.

I'll drop it.

> src/hotspot/share/memory/metaspace.cpp line 711:
> 
>> 709:     // Otherwise the lower 32G are still free. We try to place ccs at the lowest
>> 710:     // allowed mapping address for efficient encoding of compressed class pointers.
>> 711:     address base = (UseCompressedOops && (uint64_t)CompressedOops::base() < OopEncodingHeapMax) ?
> 
> Should this not somehow take ccs size into consideration?
> eg
> size_t gap_above_heap = OopEncodingHeapMax - CompressedOops.end();
> if (gap_above_heap >= size) ...

Hm, I don't understand that one. OopEncodingHeapMax is normally 32G. CompressedOops.end() is the end of the coops heap; probably way higher than 32G. So you will get an underflow in the substraction, won't you?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1815