RFR: 8372564: Convert StringDedup to use Atomic<T>

[Kim Barrett]

On Tue, 2 Dec 2025 13:51:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.hpp line 56:
>> 
>>> 54: 
>>> 55:   static OopStorage* _storages[2];
>>> 56:   static DeferredStatic<Atomic<StorageUse*>> _storage_for_requests;
>> 
>> What is the reason for the `DeferredStatic`?
>> 
>> Is it just for the init once semantics and asserts?
>> 
>> _Is this a style we should adapt more broadly for our init once static variables?_
>
> The Style Guide says
> 
> "Variables with static storage duration and _dynamic initialization_
> [C++14 3.6.2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf)).
> should be avoided, unless an implementation is permitted to perform the
> initialization as a static initialization."
> 
> It may not be immediately obvious whether dynamic initialization is required.
> (Currently, a non-local Atomic has dynamic initialization that is likely
> reducible to static initialization when the ctor argument is a constant.
> Making the Atomic ctors constexpr would make most such static. Translated
> Atomics might also need the decay function to be constexpr.)
> 
> So the safe thing to do in this respect is to use DeferredStatic for a
> non-local variable of class type. Of course, then you need to find a good
> place to put the initialization. That already existed in the case at hand.

We discussed this a bit more, and decided to make the Atomic ctors constexpr
so that, with constant arguments, they are guaranteed to be static initialized.
And then change this to remove the use of DeferredStatic and instead have the
uses assert non-null the way they used to, instead of using the DeferredStatic
initialization check. The benefit is that many uses of non-local Atomic
definitely don't need the additional DeferredStatic ceremony.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28524#discussion_r2581765344