RFR: JDK-8304723: Statically allocate global mutexes

[Justin King]

On Thu, 23 Mar 2023 15:51:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > I'd be very happy if startup would be fast enough for ~150 fewer mallocs to matter.
> > > A blank hello world with no args to speak of calls into malloc >10k times. ~150(?) mallocs less are a step in the right direction.
> > 
> > 
> > Baby steps. :)
> > As a compromise I'll shift to keeping the pointers and just use a static storage variable in the `def` macros, as suggested. It accomplishes the goal if not malloc'ing but is not as safe due to the two aforementioned bugs. I'll also add an assert to catch the "created twice" problem. But having the mutex pointer always be nullptr is a different story that cannot be caught with that approach.
> 
> The create twice problem is admittedly evil. The nullptr problem not so much, since we will access it anyway and crash right there, or?

Unfortunately not. It's used with MutexLocker which happily accepts `nullptr` and just doesn't do anything. That is a feature of it. So if you fail to create a mutex, you might not notice and the data being guarded by the mutex is no longer being accessed safely.

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

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