RFR: 8277486: NMT: Cleanup ThreadStackTracker

Coleen Phillimore coleenp at openjdk.java.net
Mon Nov 29 16:48:08 UTC 2021


On Mon, 22 Nov 2021 15:36:41 GMT, Zhengyu Gu <zgu 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.

The last comments attracted my attention.  It does seem like the shutdown logic was because of the 1.0 implementation and shouldn't be needed anymore. If you write a CSR to deprecated it for 18 (quickly), you could remove it in a couple of weeks.

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

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


More information about the hotspot-runtime-dev mailing list