JEP 522 performance regression with large pages

[Brian S O'Neill]

On 2025-08-28 08:20 AM, Thomas Stüfe wrote:
> Disclaimer: I am not a G1 expert, just a curious bystander.
> 
> Just some questions:
> - what is the standard deviation on those tests; meaning, how reliable 
> are the results?

Other than the first one, the timing differed by 1 second between each 
test run.

> - you are sure that THP is set to madvise mode on the OS side, right? 
> Not always?

Yes.

> - can you exclude the (as you say, large) off-heap memory as a cause for 
> the delta? So the only THP memory in use is the Java heap? Is anyone 
> madvising those offheap memory regions, third-party native code maybe?
> 

The off-heap memory is allocated using THP, 16GB, fully allocated and 
touched at the start of each test run. There's no third-party code 
running. The machine has 48GB in total, and nothing else is running. 
This leaves about 28GB of free memory.

> Note, you can use jcmd System.map to get a look at the THP state of all 
> memory regions of the process. It shows you which areas are eliglbe for 
> THP coalescation, and which are already coalesced. That includes heap 
> and your offheap memory (if you happen to know its address).
> 
> Other than that, my first guess would be that any performance regression 
> with THP stems from THP repeatedly forming and shattering. E.g. the OS 
> coalesces large pages concurrently to the JVM uncommitting small-page- 
> sized-portions of just coalesced large THP pages.
> 
I've not looked, but considering that there's a ton of free memory, the 
performance is consistent, and nothing else is running, leads me think 
that the regression is due to some change in the PR.