RFR: JDK-8312018: Improve zero-base-optimized reservation of class space [v2]

[Roman Kennke]

On Fri, 14 Jul 2023 13:06:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> TL;DR This patch introduces a new reservation API to reserve memory in low address space; depending on the OS, it may use optimized placement techniques. That new API is used to optimize the placement of class space and CDS for zero-based encoding. 
>> 
>> A future RFE will use the same API to optimize the zero-based heap reservation and thereby consolidate a lot of coding. We also plan to use this API in other places, e.g. for Shenandoah CollectionSet reservation.
>> 
>> -------
>> 
>> With CDS off or at dump time, we currently attempt to optimize class space location by reserving in low address ranges.
>> 
>> We do this by examining the *java heap* end (which has been allocated at that point) and, if that had been allocated in lower address regions, attempt to allocate adjacent to it. Essentially, we piggyback on what we hope for is an optimized heap placement. If that fails, we attempt to map at HeapBaseMinAddress.
>> 
>> This approach has many disadvantages:
>> 
>> - it depends on the VM either using CompressedOops and getting a zero-based heap or the region around HeapBaseMinAddress being free. 
>>  
>> - HeapBaseMinAddress is an odd choice: it is 2G on all platforms, for reasons unknown to me, but that denies us half of the valuable low address range below 4G right away.
>> 
>> - We only get 1 shot. It's either one of these two addresses.
>> 
>> - And we only use this strategy for CDS=off or CDS=dumptime; we don't use it for the CDS-runtime-fallback-case when attaching to the primary attach point failed.
>> 
>> - It assumes narrow Klass encoding uses the same geometry (bit size, shift) as narrow Oops, which is not guaranteed with future developments (lilliput).
>> 
>> - It actually reduces the chance of getting a zero-based *java heap*. This is because when attempting to place the heap, we leave a gap for what we assume will be the later class space. That gap is `CompressedClassSpaceSize` bytes, which is often grossly over-dimensioned. A zero-based heap is more valuable than a zero-based class space. Therefore the heap should get the best chance of low-address heap reservation.
>> 
>> - It introduces an unnecessary dependency between heap reservation, narrow Oop encoding, and class space reservation. That makes the code base brittle.
>> 
>> - Getting the heap region to place class space adjacent to it is actually tricky. We lack a common get-heaprange-API because ZGC. This code misuses the CompressedOops interface. But CompressedOops is the encoding range and thus only loos...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Roman; fix off-by-1; fix tracing

Looks good to me now, but somebody else who is more familiar with these things should review it as well. Thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14867#pullrequestreview-1530426524