Bug ID: JDK-8242043 G1: Naming of HeapRegionRemSet locks contribute to startup overhead

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.

Other
tbdResolved

Encoding the heap region ID into the name of the per-region mutex adds some overhead for each region. Most usage of mutexes like this provide just a static string describing the purpose of the mutex, e.g:

diff -r b588772dff7a src/hotspot/share/gc/g1/heapRegionRemSet.cpp
--- a/src/hotspot/share/gc/g1/heapRegionRemSet.cpp	Thu Apr 02 15:05:24 2020 +0200
+++ b/src/hotspot/share/gc/g1/heapRegionRemSet.cpp	Thu Apr 02 15:38:38 2020 +0200
@@ -373,7 +373,7 @@
                                    HeapRegion* hr)
   : _bot(bot),
     _code_roots(),
-    _m(Mutex::leaf, FormatBuffer<128>("HeapRegionRemSet lock #%u", hr->hrm_index()), true, Mutex::_safepoint_check_never),
+    _m(Mutex::leaf, "HeapRegionRemSet lock", true, Mutex::_safepoint_check_never),
     _other_regions(&_m),
     _hr(hr),
     _state(Untracked)

This would remove ~15% of the remaining per-region startup execution overhead.

JDK-8315503 removed the mutex completely.
23-02-2024
"Actually the use of FormatBuffer here may be incorrect. The FormatBuffer is a nameless temporary object containing the char[] field, it could be destroyed immediately, then the mutex name could become dangling pointer. " [~manc]: this particular issue with the dangling pointer in HeapRegionRemSet mutex had been (temporarily) introduced by JDK-8264146 and is already fixed. The second issue with the use in GCTraceConcTime has also been fixed. The integer does have (some) value when debugging, but maybe less so now with the new remembered sets (JDK-8017163).
01-09-2021
Actually the use of FormatBuffer here may be incorrect. The FormatBuffer is a nameless temporary object containing the char[] field, it could be destroyed immediately, then the mutex name could become dangling pointer. I encounter real GC log corruption with a JDK built with our internal LLVM and glibc, due to the following line added in https://bugs.openjdk.java.net/browse/JDK-8240556: GCTraceConcTime(Info, gc) tt(FormatBuffer<128>("Concurrent %s Cycle", _state == FullMark ? "Mark" : "Undo")); I'd like to fix both misuses of FormatBuffer. Can we just use the static string "HeapRegionRemSet lock" for all of these mutexes?
26-03-2021
An alternative would be to improve the mutex implementation to have an (optional) int value that we append to the name whenever it's printed out. Since mutex name buffer is chosen to be 64 chars mostly to help avoid false sharing, we could carve this out of the name buffer to stay footprint neutral.
02-04-2020