RFR: 8298992: runtime/NMT/SummarySanityCheck.java failed with "Total commi…tted (MMMMMM) did not match the summarized committed (NNNNNN)
Johan Sjölen
jsjolen at openjdk.org
Wed Aug 23 09:09:55 UTC 2023
On Wed, 16 Aug 2023 12:18:35 GMT, Afshin Zafari <azafari at openjdk.org> wrote:
> During exhaustive tests, it is observed that during taking snapshot of NMT metrics it is possible that new allocations happen concurrently, although a `ThreadCritical` is used during copying current metrics to the snapshot.
> A loop is surrounding the copying and checks whether the copied and original are the same.
>The ThreadCritical in the code was supposed to block other threads' allocations while copying. But it did not work as expected, since the ThreadCritical is used in a few deallocations in the code.
I don't understand what kind of concurrency problem we're reaching here. If the `ThreadCritical` lock is held during the summation and it attempts to be taken by the deallocations, then surely this would prevent any concurrent tampering of the data?
>It is expected that replacing ThreadCritical with mutex for NMT, will resolve the issue and no while-loop is needed anymore.
I don't expect that to be true, ThreadCritical is a mutex.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15306#issuecomment-1689561620
More information about the hotspot-runtime-dev
mailing list