RFR: 8281263: virtual space leakage if large page commit fails.

[Stefan Karlsson]

On Fri, 4 Feb 2022 15:53:22 GMT, Thomas Stuefe <stuefe 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.

Great suggestion. I think something like would give us enough information:

assert(false, "Large pages commit failed " PTR_FORMAT " " PTR_FORMAT " " PTR_FORMAT, p2i(aligned_start), p2i(aligned_start + large_bytes), p2i(aligned_start + bytes));

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

PR: https://git.openjdk.java.net/jdk/pull/7350