RFR: 8277486: NMT: Cleanup ThreadStackTracker
Zhengyu Gu
zgu at openjdk.java.net
Wed Nov 24 14:29:09 UTC 2021
On Wed, 24 Nov 2021 08:51:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> src/hotspot/share/services/threadStackTracker.cpp line 103:
>>
>>> 101: assert(MemTracker::tracking_level() < NMT_summary, "Must be");
>>> 102: return false;
>>> 103: }
>>
>> I looked at `MemTracker::transition_to`, the downgrade path:
>>
>>
>> } else if (current_level > level) {
>> // Downgrade tracking level, we want to lower the tracking level first
>> _tracking_level = level;
>> // Make _tracking_level visible immediately.
>> OrderAccess::fence();
>> VirtualMemoryTracker::transition(current_level, level);
>> MallocTracker::transition(current_level, level);
>> ThreadStackTracker::transition(current_level, level);
>>
>> Is the comment about "immediately" correct? I would have assumed OrderAccess::fence() has not have anything to do with timing, just with the order the writes are perceptible from outside?
>>
>> So, concurrent threads may observe tracking level == minimal but the pointers to the infrastructure are still there?
>>
>> I see that you do not guard `MemTracker::transition_to` with ThreadCritical. You do guard teardown inside `ThreadStackTracker::transition` and `VirtualMemoryTracker::transition` but it looks like teardown in `MallocTracker::transition` is unguarded by ThreadCritical at least.
>>
>> Just a proposal, would guarding upstairs in `MemTracker::transition_to` not be clearer and safer, especially if it includes changing the tracking level?
>>
>> Alternatively, do we even have to delete all those structures on shutdown? They are not that costly. We shut down either manually - nobody cares then - or if we encounter native OOM. In the latter case, those detail structures are arguably important since they contain data that may help analyze the OOM. The malloc site table, for instance.
>
> To add to that, I always wondered why we even expose `shutdown` via jcmd... especially since this is a one-way operation, so its use is limited.
`ThreadStackTracker` could be tracked as `malloc` memory, and yes, `MallocTracker::transition` is not guarded by `ThreadCritical`, because it is too expensive on other operations.
Yes, I believe we have yet seen any bug reported, solely due to limited use of shutdown function :-)
-------------
PR: https://git.openjdk.java.net/jdk/pull/6504
More information about the hotspot-runtime-dev
mailing list