RFR: JDK-8304723: Statically allocate global mutexes

Thomas Stuefe stuefe at openjdk.org
Fri Mar 24 16:58:00 UTC 2023


On Thu, 23 Mar 2023 15:58:27 GMT, Justin King <jcking 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?
>
>> > > 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.

@jcking looks a lot better, thank you!

You already have enough reviews. Gave it a cursory glance and it looks good to me.

Cheers, Thomas

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

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


More information about the hotspot-dev mailing list