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