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

[Johan Sjölen]

On Fri, 18 Apr 2025 09:37:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> > > ... however when working with certain code you may want to allocate before NMT is initialized. This leads to you having to use raw malloc. This is probably something you find out after having used os::malloc and already had a strange crash when building your code.
>>> > 
>>> > 
>>> > ? No, this should not happen. You can, of course, use `os::malloc` before NMT is initialized; that is why NMT preinit mode exists. If you get strange crashes (do you have JBS issues for them?), those are bugs and should be fixed.
>>> > If this is the only motivation for this PR, we may be able to save a lot of time.
>>> 
>>> You're right, I managed to confuse this with another bug I had, where I mmapped before the VMT was intialized. Sloppy of me.
>>> 
>>> Happy Easter, let's talk more later.
>> 
>> Aah sorry, I looked at the description again. The `MemBaseline` example comes much further down. There's been a lot of internal talk about this, and  I've forgotten which details I've said here and what I've only said internally.
>> 
>> To me, `StableValue` is an ergonomic feature. We can make do without it, but I'd rather not.
>> 
>> I dislike that I:
>> 
>> 1. Can't simply statically allocate values, but I have to always have a null pointer which I do the malloc + new placement for every time. `StableValue` gets rid of that ceremony, which I appreciate.
>> 2. That a trivially allocated data structure can trip up when it becomes non-trivial. `StableValue` let's me be defensive for my own data, without having to resort to malloc.
>> 
>> 
>> (But seriously, let's talk about this more after the Easter weekend)
>
> @jdksjolen  Can you please give some concrete examples of existing things in the codebase that have this initialization problem and which would be candidates for this `StableValue`?
> 
> Also I think the name will have to change as it may be confused with "stable values" as they relate to Java code and compiler optimizations.
> 
> Happy Easter. :)

@dholmes-ora , @tstuefe 

I hope you had a good Easter :).

>@jdksjolen Can you please give some concrete examples of existing things in the codebase that have this initialization problem and which would be candidates for this StableValue?

To be clear, no issues exist today because we circumvent the issue using malloc. I'm suggesting an alternative way of circumventing the problem, while allowing us to more clearly express the intent of our code. If we have code like this:

```c++
class Foo {
  static Bar* _bar;
  // ...
};


Here, `_bar` may be reassigned, it may be null and it has an unknown lifetime. When I'm reading the code, I want to ensure that I understand it, so I may look at how often and when it is assigned and so on.

If we have this, instead:

```c++
class Foo {
  static StableValue<Bar> _bar;
};


Then we know that `_bar` will be assigned exactly once, that it will be uninitialized prior to the point that it's initialized, it cannot be null,  and that it will never be deallocated.

I think that conveys a lot more about the specific usage of the value, just from reading that line. **This PR  doesn't aim for further correctness**, it aims for developer ergonomics. This class would make my life easier and less tedious when writing and reading code, and I'm hoping that others agree that it would help them as well.

In the PR I give two concrete places where I switch to using StableValue, but there are of course more.

See `ZInitialize::initialize` and `ZDriver::initialize`. There's a strict initialization order, as objects need to materialize in the order that they depend on each other. The `ZLock` in `ZDriver::initialize` is `malloc`ed, why? Probably because they didn't want to take the risk of having a static initialization fiasco.

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

PR Comment: https://git.openjdk.org/jdk/pull/24689#issuecomment-2823556707