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

Thomas Stuefe stuefe at openjdk.org
Wed Mar 26 16:23:07 UTC 2025


On Tue, 25 Mar 2025 18:58:59 GMT, Stefan Karlsson <stefank 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).

Stefan, your analysis sounds reasonable. Don't see a hole. The original issue was from me I think, but I've never seen that variant in real life.

So, I am fine with leaving that scenario out.

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

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


More information about the hotspot-dev mailing list