RFR: 8315923: pretouch_memory by atomic-add-0 fragments huge pages unexpectedly [v3]

[Liming Liu]

On Fri, 29 Sep 2023 07:08:19 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Liming Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cuddle ptr-operators in pretouch_memory_common
>
> PretouchTask attempts to parallelize the pretouching.  How well does that work
> with the use of MADV_POPULATE_WRITE?

> Like @kimbarrett, I think this needs a better regression test. Ideally (and probably not that difficult to pull off): start the VM with AlwaysPreTouch, `-Xlog:pagesize`, and +UseTHP. Then, scan smaps to check that the heap is not splintered. Please see https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/os/TestTracePageSizes.java . It may be that you can just extend that test to include running with UseTHP.

It is hard to judge whether the test is success. The only difference of smaps around JDK-8272807 (from `*p = 0` to atomic-add) and this patch (from atomic-add to madvise) is the size of AnonHugePages on aarch64:

- the term covers ~90% of the map when THP mode is always and `*p = 0`/madvise is used, while it is just ~10% when atomic-add is used.
- the term would use up adjacent regions reflected by /proc/buddyinfo when THP mode is madvise and `*p = 0`/madvise is used, while it is zero when atomic-add is used.

So it is hard to say which coverage is considered to be success.

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

PR Comment: https://git.openjdk.org/jdk/pull/15781#issuecomment-1754388017