[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR: 8277486: NMT: Cleanup ThreadStackTracker
From:       Coleen Phillimore <coleenp () openjdk ! java ! net>
Date:       2021-11-29 16:48:10
Message-ID: J8PKSpNW4IX34Jb3lri9gfyrG_M0K0nEFTctK2KjbP4=.ee53bb3a-8c2a-403b-86ae-1affb4c87d70 () github ! com
[Download RAW message or body]

On Wed, 24 Nov 2021 14:16:35 GMT, Zhengyu Gu <zgu@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


[prev in list] [next in list] [prev in thread] [next in thread]