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