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

[Ioi Lam]

On Fri, 21 Jul 2023 05:48:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/memory/metaspace.cpp line 597:
>> 
>>> 595:   {
>>> 596:     // First try for zero-base zero-shift (lower 4G); failing that, try for zero-based with max shift (lower 32G)
>>> 597:     constexpr int num_tries = 8;
>> 
>> num_tries should be computed instead of hard-coded.
>
> Why? In pre-existing code that does similar things, we always hardcode them implicitly (typically by attempt-mapping from A->B in hardcoded stride C). And how would I calculate it?

Hmm, I am a bit unsure about the meaning of the `num_tries` parameter. It looks like Windows and Linux will scan the system's memory map and look for the first hole that's larger than `size`. However, if there are a lot of small holes at lower addresses, then doing 8 tries won't find a large enough block, even though such a block may exist below `unscaled_max`.

The default implementation will try to find a free block with fixed steps. In this case, it seems like 


num_tries = (unscaled_max + size - 1) / size;


would be more appropriate. Otherwise if `size` changes in the future (to be smaller), again you won't be able to find an appropriate block, even if one exists.

So I am not sure if the caller passing in an arbitrary `num_tries` parameter is a good idea. Maybe the API needs to be redesigned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14867#discussion_r1271375406