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 07:41:35 UTC 2023
On Wed, 18 Oct 2023 14:58:15 GMT, Afshin Zafari <azafari at openjdk.org> wrote:
>> The `attempt_allocate_memory_at(addr, size)` may fail for some reasons that `::mmap` will report. To find out why an attempt failed, an `int *` is passed down deep to the `::mmap` to return the `ERRNO` back to the callers.
>> This error code is used in gTest test case to show a proper message.
>>
>> The changed test case never failed after 10K+ repetitions, but in case it happens in future the reason is also printed out.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>
> some pd_xxx calls were missed.
I agree with David, I don't particularly like this broadening of the interface.
(quick reminder to myself why we even need multi release: because on Windows, with UseNUMA, we allocate in stripes, and deallocation then did not work because it only deallocated the first stripe, which led to eventual OOMs: https://bugs.openjdk.org/browse/JDK-8255978 )
I feel guilty since these are my tests.
The re-reserve after the multi-release is prone to intermittent errors since some concurrent thread may have been lucky and may have created a mapping there. As we see, they occur very rarely, but they do occur. There are some things we could do:
- do the whole initial striped allocation at some weird outlandish addresses that the normal allocator would probably not use. That is what I use to test low-address allocations.
- If re-reserve fails, check with os::find_mappings if some concurrent thread created existing mappings in that area. If yes, count that as test success, since it proves we successfully removed the mapping. If no, repeat the re-reserve. Do so like 20 times.
- Finally, just remove the re-reserve part of the test and give up.
@afshin-zafari If you want, you can hand this issue over to me. I am snowed in though, so it may take some time until I fix it.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/16240#issuecomment-1772237443
More information about the hotspot-runtime-dev
mailing list