RFR: 8304824: NMT should not use ThreadCritical [v8]

Robert Toyonaga duke at openjdk.org
Mon Oct 28 16:12:40 UTC 2024


On Fri, 25 Oct 2024 14:32:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/utilities/vmError.cpp
>>   
>>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/utilities/vmError.cpp line 724:
> 
>> 722:     MemTracker::reduce_tracking_to_summary();
>> 723:     // Manually unlock if already holding lock upon entering error reporting.
>> 724:     NmtVirtualMemory_lock->unlock();
> 
> Thinking this through some more, I am now unsure about my old advice. I think if we force-unlock the mutex here, there should be no need for dropping the tracking mode to summary. Sorry if I gave conflicting advice before.
> 
> So I think you could remove the reduce_tracking call (and its implementation).
> 
> Dropping to summary has the disadvantage that it makes the NMT report in the hs-err file look like user ran with summary more active, which may confuse analysts. Force-unlocking is the way to go.

Ok I see. I've removed the dropping of the tracking level and just kept the force unlocking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1819339376


More information about the serviceability-dev mailing list