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