RFR: JDK-8304723: Statically allocate global mutexes

[Kim Barrett]

I’ve not looked at this change in any detail, so don’t consider this any kind of review, just a passing comment.

> On Mar 23, 2023, at 2:37 AM, Thomas Stuefe <stuefe at openjdk.org> wrote:
> 
> On Wed, 22 Mar 2023 22:32:59 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> On posix, switch from pthread_cond_init to static initialization if possible.
>> 
>> Some platforms have the "wrong" default which is why we don't attempt to use the pthread static initializers. But in general statically initializing our Mutex/Monitor would be very fragile IMO - as discussed in the past.
> 
> Oh, right, there was that. Wonder if that still holds true today. Wasn't that Solaris?
> 
>> 
>> Doing the allocation statically is a different matter. But what does this gain? Is the startup improvement noticeable?
>> 
> 
> 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.

I see no mallocs for the names.  The names come from macro stringizing the associated variable in defl(), so
are string literals.

The names used to be embedded in Mutex (providing some padding around the atomic parts I think), with
the string passed to the constructor strcpy’ed into that embedded buffer, but that was removed by JDK-8264146.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230323/520b53be/signature.asc>