RFR: 8280056: gtest/LargePageGtests.java#use-large-pages failed "os.release_one_mapping_multi_commits_vm" [v2]

Thomas Stuefe stuefe at openjdk.org
Fri Oct 20 12:33:29 UTC 2023


On Fri, 20 Oct 2023 12:17:21 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> Using `MAP_FIXED_NOREPLACE` in `::mmap` makes it thread-safe (only one thread will succeed). [mmap man page](https://man7.org/linux/man-pages/man2/mmap.2.html#:~:text=flag%20in%20NOTES!-,MAP_FIXED_NOREPLACE) In `hotspot/os/linux/os_linux.cpp:3506` ([here](https://github.com/openjdk/jdk/blob/40106422bd2ae3da98d028bdbab2c240a71081e3/src/hotspot/os/linux/os_linux.cpp#L3506)) that flag is used if the requested address is not null.
> 
> Are we still suspicious about multi-thread reasons?

??

MAP_FIXED_NOREPLACE has nothing to do with it.

The test tries to prove that release across multiple areas that have been allocated with different calls to os::reserve_memory() works.

It does that by reserving, then releasing such memory, and then attempting to re-reserve within that same address range. If the re-attempt succeeds, this means that the release worked because the address space was apparently up for grabs. If it does not work, it may have failed for one of two reasons:
A the multi-release did not work, and maybe it failed without telling us (return code "ok")
B some concurrent thread allocated within that address range in the time span between us releasing it and us attempting the re-reserve.

A is an error we want to know. B can sporadically happen, as I explained. We want to know A and filter out noise from B as much as possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/16240#issuecomment-1772653417


More information about the hotspot-runtime-dev mailing list