RFR: 8277486: NMT: Cleanup ThreadStackTracker

[David Holmes]

On Wed, 24 Nov 2021 08:49:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> There are several issues with `ThreadStackTracker`.
>> 
>> 1) Following assertion:
>>   `assert(MemTracker::tracking_level() >= NMT_summary, "Must be");`
>> in `ThreadStackTracker::record/release_thread_stack()` is unreliable. The full fence after downgrading tracking level is *not* sufficient to avoid the racy.
>> 
>> 2) NMT tracking level is downgraded without `ThreadCritical` lock held. But, it does require `ThreadCritical` lock to be held when it actually downgrade internal tracking data structure, so checking internal state is reliable to determine current tracking state.
>> Add assertion to ensure correct tracking state
>> 
>> 3) `_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.
>> 
>> 4) NMT events are relative rare. So far, I have yet seen (1) assertion failure but add new test may help to spot such problem.
>
> Changes requested by stuefe (Reviewer).

@tstuefe :

>  I would have assumed OrderAccess::fence() has not have anything to do with timing, just with the order the writes are perceptible from outside?

fence() is supposed to be a sledgehammer that forces a consistent view of memory for all threads/processors. Any writes before a fence should be made visible to all other processors before the fence returns, such that loads of any of this locations will see the value written. It is "immediate" in that sense.

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

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