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