RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v3]

[Robert Toyonaga]

On Mon, 25 Nov 2024 12:12:25 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/runtime/os.cpp line 2213:
>> 
>>> 2211:     res = pd_release_memory(addr, bytes);
>>> 2212:     if (res) {
>>> 2213:       ThreadCritical tc;
>> 
>> What is the reason for moving `pd_release_memory` out of the protection of the lock? Wouldn't it be better if the memory operation and the accounting were done together atomically like with [`os::uncommit_memory`](https://github.com/openjdk/jdk/pull/20425/files#diff-c626d392182b0193ad0e754de3f4fd42c98d959edade67490b6e1f24be38efdbR2189) for example.
>
> TBH, I don't know and this is not a change in this PR. The uncommit_memory has the same approach. I just know that if we move the pd_xxxx inside the lock some tests fail or some assertions happen, but do not remember which and why.

OK, I guess it doesn't make much of a difference at the moment since it's inconsistent across many memory operations anyway. Commit, uncommit, reserve, and release don't agree on whether to make the memory operation and NMT accounting atomic together. I opened an issue for this here: https://bugs.openjdk.org/browse/JDK-8341491

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1856951247