RFR: JDK-8312018: Improve reservation of class space and CDS [v5]

[Thomas Stuefe]

On Tue, 22 Aug 2023 04:53:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Roman: better comment in metaspaceShared
>>  - Changes to os::vm_min_addr
>
> src/hotspot/share/runtime/os.cpp line 1818:
> 
>> 1816: 
>> 1817:   // Number of mmap attemts we will undertake.
>> 1818:   constexpr unsigned max_attempts = 32;
> 
> Is this sufficient?

The original code (only for aarch64+ppc) attempted 8 + 32 = 40 attach operations: 8 in the lower 32g, 32 above that. +1 probe attempt at HeapBaseMinAddress.

We now attempt a bit more: 2 * 32 for the two low address regions, 32 for the upper address regions.

When experimenting with different approaches, I originally wanted to scan the procfs on Linux to spot address space holes. But I then saw that accessing procfs is expensive (50-200us per op depending on hardware) whereas failed mmaps are dirt cheap. Especially if one uses MAP_FIXED_NOREPLACE (see https://github.com/openjdk/jdk/pull/15170, if you feel like reviewing that, its very small). On my desktop, about 100 failed mmaps cost as much as a single procfs access.

Cranking this value up too much may cause us to needlessly probe large occupied areas, negatively affecting startup performance. OTOH, that is why I implemented the hemi-split probing (alternating between high and low addresses), which works quite well. I rarely see more than 3-5 attach attempts.

I think we could increase it to 64, maybe. 32 seems a good spot though. I'm open for suggestions. There is no clear answer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15041#discussion_r1301085515