RFR: 8354954: Typed static memory for late initialization of static class members in Hotspot [v4]

[Kim Barrett]

On Sun, 20 Apr 2025 11:41:07 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/share/utilities/stableValue.hpp line 44:
>> 
>>> 42:   union {
>>> 43:     T _t;
>>> 44:   };
>> 
>> All of this stuff about laundering and this union trick could go away if we're willing to add a pointer
>> to the StableValue class.  Something like this (not tested):
>> 
>> template<typename T>
>> class StableValue {
>>   alignas(T) char _data[sizeof(T)];
>>   T* _p;
>> public:
>>   StableValue() : _p(nullptr) {}
>>   ~StableValue() = default;
>>   NONCOPYABLE(StableValue);
>>   T* ptr() {
>>     assert(_p != nullptr, "uninitialized");
>>     return _p;
>>   }
>>   T* operator->() { return ptr(); }
>>   T& operator*() { return *ptr(); }
>>   template<typename... Args>
>>   void initialize(Args&&... args) {
>>     assert(_p == nullptr, "already initialized");
>>     _p = ::new (_data) T(std::forward<Args>(args)...);
>>   }
>> };
>> 
>> Regarding the destructor, quoting from the style guide: "HotSpot doesn't generally try to cleanup
>> on exit, and running destructors at exit can also lead to problems."
>
> This would induce an additional indirection on every access, though.

That additional indirection is what we already have with the current idiom.  I'm looking for a way to be
safe while removing the "do we need to do laundry" question.  But I'm currently thinking we don't need
to do laundry, though I'm still working through the details of the rationale, and still might end up deciding
I'm wrong.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24689#discussion_r2052928298