RFR: 8341491: Reserve and commit memory operations should be protected by NMT lock

Stefan Karlsson stefank at openjdk.org
Tue Mar 25 19:01:10 UTC 2025


On Mon, 24 Mar 2025 17:11:55 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> Hi stefank, I think you're right about (1.1) (2.1) (2.2) (1.2) being prevented by the current implementation. Is there a reason that the current implementation only does the wider locking for release/uncommit? Maybe (2.1) (1.1) (1.2) (2.2) isn't much of an issue since it's unlikely that another thread would uncommit/release the same base address shortly after it's committed/reserved?

I'm very curious to find out if anyone knows how this could happen without a race condition hand-over from one thread to another. (See my answer to Stüfe).

> 
> > Have you seen an issue that this proposed PR intends to solve? If there is such a problem I wonder if there's just a missing lock extension in one of the "release" operations.
> 
> I haven't seen that race in the wild, I just noticed that the memory operations weren't protected and thought that it could be a problem.

OK. Let's see if anyone finds a hole in my arguments given above.

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2752247631


More information about the hotspot-dev mailing list