While playing Kim's latest string deduplication code to enable string deduplication during root scan, I got following assertion:
# assert(false) failed: Attempting to acquire lock ^H<98>¬l<8d>^?/9 out of order with lock stack_watermark_lock/2 -- possible deadlock
The first lock name should be one of OopStorage's _allocation_mutex, but it showed as garbage above.
It turns out that _allocation_mutex name is generated dynamically.
e.g.
_allocation_mutex(make_oopstorage_mutex(name, "alloc", Mutex::oopstorage)),
and
static Mutex* make_oopstorage_mutex(const char* storage_name,
const char* kind,
int rank) {
char name[256];
os::snprintf(name, sizeof(name), "%s %s lock", storage_name, kind);
return new PaddedMutex(rank, name, true, Mutex::_safepoint_check_never);
}
# assert(false) failed: Attempting to acquire lock ^H<98>¬l<8d>^?/9 out of order with lock stack_watermark_lock/2 -- possible deadlock
The first lock name should be one of OopStorage's _allocation_mutex, but it showed as garbage above.
It turns out that _allocation_mutex name is generated dynamically.
e.g.
_allocation_mutex(make_oopstorage_mutex(name, "alloc", Mutex::oopstorage)),
and
static Mutex* make_oopstorage_mutex(const char* storage_name,
const char* kind,
int rank) {
char name[256];
os::snprintf(name, sizeof(name), "%s %s lock", storage_name, kind);
return new PaddedMutex(rank, name, true, Mutex::_safepoint_check_never);
}
- duplicates
-
JDK-8265682 G1: Mutex::_name dangling in HeapRegionRemSet references after JDK-8264146
-
- Resolved
-
- relates to
-
JDK-8264146 Make Mutex point to rather than embed _name
-
- Resolved
-