RFR: 8366671: Refactor Thread::SpinAcquire and Thread::SpinRelease [v12]

[David Holmes]

On Fri, 5 Dec 2025 20:42:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Well we moved it for convenience but we really don't want it to start being used all over. :) I don't like this kind of "just in case" code as it indicates to me that we don't really know how/where the code is being used - and where do you draw the line? This is debug code so the performance aspect is not a concern, but I prefer not to have it but if you like document that this is not for use in signal-handling context. But this isn't a deal-breaker if others think it worth being ultra-conservative here.
>
> I hadn't noticed the 'safe' variant of Thread::current_or_null, but it seems like it might be appropriate from the implementation if this can be called very early in VM initialization for ParkEvents.
> 
> 
> inline Thread* Thread::current_or_null_safe() {
>   if (ThreadLocalStorage::is_initialized()) {
>     return ThreadLocalStorage::thread();
>   }
>   return nullptr;
> }
> 
> 
> It seems to cover more than the case of being called in a signal handler.  I think it's not a bad usage.  I was going to vote the other way until I saw the implementation.

Coleen I am not at all sure what you mean by that. The "safe" implementation has to use library-based TLS, rather than language/compiler-based as the latter is definitely not signal-safe while the former is deemed safe enough for reading TLS values. Because the safe version can be called very early in VM init we have to check the library-based TLS is initilalized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28264#discussion_r2596661529