RFR: 8356173: Remove ThreadCritical [v2]

Coleen Phillimore coleenp at openjdk.org
Fri May 9 17:46:09 UTC 2025


On Fri, 9 May 2025 16:53:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> @coleenp But surely one can statically allocate a pthread_mutex_t and assign PTHREAD_MUTEX_INITIALIZER, no? I mean that's Unix 101. MacOS should be able to do that at least.
>> 
>> Looking at PlatformMutex, maybe it is not the right tool for the job. One needs a simple stupid mutex class like this:
>> 
>> 
>> struct SimpleMutex {
>>     pthread_mutex_t _m;
>>     SimpleMutex() : _m(PTHREAD_MUTEX_INITIALIZER) {}
>>     lock() -> do pthread_mutex_lock
>>     unlock() -> do pthread_mutex_unlock
>> };
>> static SimpleMutex mymutex;
>> 
>> 
>> etc.
>
> Note that such a simple solution would also reduce the number of indirections when using this mutex. One less pointer load, one less memory access.

PlatformMutex is the simple locking scheme that we use throughout the VM, so it is the right tool for the job. It is actually the same as your SimpleMutex only it had code that deals with the old macosx bug (that should be removed not with this RFE).  Actually ThreadCritical is your SimpleMutex except has to be reimplemented on both windows and posix, which again is already the same as PlatformMutex.

>  I mean that's Unix 101. MacOS should be able to do that at least.

My crash suggests otherwise.  Maybe it's a bug in PlatformMutex.  I'd rather fix that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25072#discussion_r2082196020


More information about the hotspot-dev mailing list