RFR: JDK-8304723: Statically allocate global mutexes

[Thomas Stuefe]

On Wed, 22 Mar 2023 15:23:59 GMT, Justin King <jcking at openjdk.org> wrote:

> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.

Makes sense, but I think you can do a large part of what you want with a fraction of the changes.

- we can probably switch from dyn. allocating the mutex name to keeping it inline as a static buffer. Cuts allocations down by half already. The name lengths are not that surprising, and even if we truncate (we shouldn't) it's probably fine.
- On posix, switch from pthread_cond_init to static initialization if possible.

Other than that, moving initialization to static now runs the initializers at dll load time, not at VM initialization time. Should be fine, but it's a semantic change to be aware of. I'm especially not keen on calling into the pthread lib at dll load time. But if you change it to static initialization it should be fine (PTHREAD_COND_INITIALIZER).

Like Coleen I don't like the invasiveness of this patch, esp. considering what it is doing. Pls try to simplify. You could probably keep the outside semantics, and do without templates. Eg define the mutexes in a compilation unit and export pointers to them to the outside?

e.g. 
x.cpp
static whatever-mutex-type Currentname_obj;
extern whatever-mutex-type* Currentname = &Currentname_obj;

and the hpp file accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1479967039