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
 
-         
 P3
  P3