Bug ID: JDK-8264146 Make Mutex point to rather than embed

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 17
17 b16Fixed

ie.
-// The default length of mutex name was originally chosen to be 64 to avoid
-// false sharing. Now, PaddedMutex and PaddedMonitor are available for this purpose.
-// TODO: Check if _name[MUTEX_NAME_LEN] should better get replaced by const char*.
-static const int MUTEX_NAME_LEN = 64;
-

Since HandshakeState embeds Mutex, it adds 512 extra bits to JavaThread.

I ran performance tests on this and there was no change in performance.

This change breaks the use of FormatBuffer in the HeapRegionRemSet constructor.
21-04-2021
There is a bit of history here. Prior to JDK-6610420 Mutex declared: const char * _name; // Name of mutex int NotifyCount ; // diagnostic assist double pad [8] ; // avoid false sharing and that code came in with JDK-6575424. But the code had a bug - they forgot to actually assign the name passed in to the constructor to the _name field. When 6610420 was being worked on it was realized that as Mutex names are short, we don't need to have both a _name pointer field and 64 bytes of padding, we can just make the name array be the padding. Hence: char _name[MONITOR_NAME_LEN]; But then JDK-8166970 introduced more flexible padding based on the cache line size and so we got PaddedMonitor. And it then added the comment: +// The default length of monitor name was originally chosen to be 64 to avoid +// false sharing. Now, PaddedMonitor is available for this purpose. +// TODO: Check if _name[MONITOR_NAME_LEN] should better get replaced by const char*. There's some extensive discussion in the review thread for that: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-October/021466.html but in the end we left the _name situation unresolved, with just the comment to indicate we should look at this further. And now we have.
25-03-2021
Changeset: a1e717f1 Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2021-03-25 12:37:28 +0000 URL: https://git.openjdk.java.net/jdk/commit/a1e717f1
25-03-2021
I have an instrumented build that counts Mutex and contentions, and these are the top locks for DaCapo. ===== DaCapo 9.12 xalan starting ===== ===== DaCapo 9.12 xalan PASSED in 3451 msec ===== Lock counts: lock=Compile_lock count=354530 contentions=17009 lock=CompiledIC_lock count=265486 contentions=9342 lock=SystemDictionary_lock count=217494 contentions=1026 lock=CodeCache_lock count=215882 contentions=1135 lock=ProtectionDomainSet_lock count=85077 contentions=929 lock=AdapterHandlerLibrary_lock count=71769 contentions=6 lock=DirectivesStack_lock count=63390 contentions=206 lock=Module_lock count=52501 contentions=21 lock=MethodCompileQueue_lock count=45999 contentions=6876 lock=CompiledMethod_lock count=36973 contentions=626 lock=CompileTaskAlloc_lock count=30427 contentions=51 lock=SymbolArena_lock count=27469 contentions=0
24-03-2021

Relates :	JDK-8265682 - G1: Mutex::_name dangling in HeapRegionRemSet references after JDK-8264146
Relates :	JDK-8166970 - Adapt mutex padding according to DEFAULT_CACHE_LINE_SIZE
Relates :	JDK-6610420 - Debug VM crashes during monitor lock rank checking
Relates :	JDK-8265921 - Mutex name may point to garbage after JDK-8264146