RFR: 8356173: Remove ThreadCritical [v2]

[Coleen Phillimore]

On Fri, 9 May 2025 06:49:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> For these signal handler usages, I had this idea: https://bugs.openjdk.org/browse/JDK-8349578 - a double-buffering approach where we, upon entering the signal handler, open up a new ResourceArea for the current thread, and return to the original RA upon leaving signal handling.
>
>About guarding os::free, that is needed for a dreary issue (see https://bugs.openjdk.org/browse/JDK-8325890). In short, it is needed to get stable arena memory readings.

I don't think this patch makes either of these NMT problems worse.  The ChunkPoolLocker (except for the call to os::free()) holds the lock for a very short interval.  Getting interrupted here is the same as getting interrupted in any critical section in the vm.

The os::free() calls could be wrapped in an NMT specific lock.  Or the mtChunk accounting could just use atomic operations - they don't already?

I realize with this change I'm interfering with some ongoing NMT work.  I apologize for that. I was trying to get rid of a case of a raw pthread_mutex call that we were looking at in some other context, and to remove the last remnants of the once pervasive ThreadCritical lock.

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

PR Comment: https://git.openjdk.org/jdk/pull/25072#issuecomment-2867520806