On Mon, 24 Mar 2025 17:11:55 GMT, Robert Toyonaga <d...@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
