AlwaysPreTouch: volatile write versus atomic update versus Linux kernel

[Peter Kessler OS]

When https://bugs.openjdk.org/browse/JDK-8272807 was fixed, we changed from using a volatile store of 0 to using an atomic increment by 0.  That allows the pre-touch threads to race against the application threads to commit reserved pages of the heap.  Asynchronous pre-touching should be a start-up time win over synchronous pre-touching.

Atomic increment by 0 also had the effect of fragmenting transparent huge pages on aarch64 Linux systems.  https://bugs.openjdk.org/browse/JDK-8315923 addressed that issue for more modern Linux systems by using a new madvise flag (MADV_POPULATE_WRITE) to pre-fault pages without needing to write each individual base page.

Why was there not an option added to choose how pages were pre-touched?  That way, users stuck on older Linux kernels could trade whatever start-up improvement they got from asynchronous pre-touching against the cost of the kernel reassembling transparent huge pages during execution.  Would there be objections to adding an AlwaysPreTouchSynchronously flag to revert to volatile stores and to delay until all the pre-touching was complete before letting Java code run in the heap?

            … peter      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-use/attachments/20251222/60e04b03/attachment.htm>