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

[Thomas Stuefe]

On Wed, 25 Oct 2023 07:47:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I changed the size to 1G which means two thp on aarch64 with 64KB page sizes. The test now checks the usage of thp, and will fail when the policy is madvise and the method of pretouch is atomic-add on aarch64. Timing is a factor, but have to be checked manually from the log, as there is no standard on how fast it should be.
>
> Ah, ok, now I get it. You use the size to pick out the heap from the mappings. The problem here is that 1G is a really common size, and you may e.g. find the class space first, which is 1G in default size.
> 
> May I suggest two alternatives?
> 
> 
> Alternative 1:
> 
> call the JVM with "-Xlog:pagesize". That will print out the heap location too, at least for G1, the default allocator:
> 
> 
> thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-fastdebug$ ./images/jdk/bin/java -Xlog:pagesize                                   
> ...
> [0.012s][info][pagesize] Heap:  min=8M max=16064M base=0x0000000414000000 size=16064M page_size=4K 
> 
> 
> You can then parse the heap base from the output and use that to find the mapping.
> 
> Alternative 2:
> 
> Pass a really crooked size to -Xmx. Not as safe as alternative 1, but should work reasonably well.

If you use Alternativre 1, you also can scan for UseTransparentHugePages=1 in the output and replace the mxBean call with that:


[0.001s][info][pagesize] UseLargePages=1, UseTransparentHugePages=1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15781#discussion_r1371302522