RFR: 8281263: virtual space leakage if large page commit fails.
Thomas Stuefe
stuefe at openjdk.java.net
Fri Feb 4 15:56:11 UTC 2022
On Fri, 4 Feb 2022 15:32:30 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
> I'm not convinced that this is needed or even safe. My understanding is that you have already lost the reservation [aligned_start, aligned_start + large_bytes) when the large page commit failed. If that is the case, then it is unsafe to unmap it again, since another thread could race and reserve that memory, and then this thread would potentially unmap the other thread's memory.
I thought so too. See also https://bugs.openjdk.java.net/browse/JDK-8007074, which was caused by a failing commit leaving the address range in question unmapped and available for concurrent reservations.
>
> Could you provide some data help me understand the problem you are seeing?
>
> I'd like to see the values of aligned_start, large_bytes and bytes and a preferably a dump of `/proc/<pid>/maps` when the coded enters the if statement:
>
> ```
> if (!large_committed) {
> // Failed to commit large pages, so we need to unmap the
> ```
Note that an easy way to get this would be to just assert at that point, the hs-err file should contain a copy of the maps file.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7350
More information about the hotspot-runtime-dev
mailing list