RFR: 8277486: NMT: Cleanup ThreadStackTracker

[Coleen Phillimore]

On Wed, 24 Nov 2021 14:16:35 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> src/hotspot/share/services/memTracker.hpp line 270:
>> 
>>> 268:     if (tracking_level() < NMT_summary) return;
>>> 269:     if (addr != NULL) {
>>> 270:       ThreadCritical tc;
>> 
>> Would this not require, to prevent the assert in (new|delete)_thread_stack, to repeat the tracking level check inside the ThreadCritical scope? Since the tracking level could have changed between lines 268 and 270?
>
> With/without `ThreadCritical lock`, the assertion in `(new|delete)_thread_stack` is unreliable, because tracking level is undergraded without `ThreadCritical` lock, therefore, there is no synchronize-with relationship. So to check tracking level inside `(new|delete)_thread_stack`, it can only rely on 
> 
> Early return at line #268 avoids very expensive `ThreadCritcal` lock, given NMT is off by default and also tracking level can only be downgraded monotonically.
> 
> Anyway, I believe current shutdown logic for virtual memory tracking is racy, filed [JDK-8277788](https://bugs.openjdk.java.net/browse/JDK-8277788).

Also would like one less use of ThreadCritical lock, since it's used for malloc if needed for resource allocation.

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

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