RFR: 8277486: NMT: Cleanup ThreadStackTracker

Zhengyu Gu zgu at openjdk.java.net
Tue Nov 23 13:58:05 UTC 2021


On Tue, 23 Nov 2021 01:46:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > _thread_counter is updated with ThreadCritical lock, but is read without the lock. Change to atomic update to ensure reader will not read stale value.
> 
> Use of atomic updates with MO_RELAXED will not affect whether an Atomic::load sees a stale value or not.

I thought we settled this in [PR 6065](https://github.com/openjdk/jdk/pull/6065), as you stated:

> I see now that the C++ "Modification Order" definition requires the write to the counter to be (for want of a better term) "immediately visible" to any subsequent read - so no stale value could be read.

If you are referring the inaccurate read of the counter w/o the lock, then yes, it is a general problem with NMT, where various counters are *not* strictly sync'd to avoid taking locks.

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

PR: https://git.openjdk.java.net/jdk/pull/6504


More information about the hotspot-runtime-dev mailing list