RFR 8247670: Shenandoah: deadlock during class unloading OOME

Zhengyu Gu zgu at redhat.com
Tue Jun 16 19:48:18 UTC 2020


The deadlock is caused by one thread holding per-nmethod lock, then 
encountering evac-oom. At the same time, another thread entering 
evac-oom scope, then acquiring the same per-nmethod lock.

The first thread expects the second thread to see evac-oom and exit the 
scope, but the second thread is blocked on acquiring per-nmethod lock.

The solution is to introduce an abortable locker on per-nmethod lock. If 
the second thread can not acquire the lock, but see evac-oom, it simply 
aborts, so it can exit evac-oom scope.

The solution does come with penalties:

If the second thread is a Java thread (via nmethod entry barrier), the 
nmethod will be deopt.

If the second thread is worker, it causes current code root processing 
to abort, then restart.


Bug: https://bugs.openjdk.java.net/browse/JDK-8247670
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8247670/webrev.00/

Test:
   hotspot_gc_shenandoah (x86_64 and aarch64)

Thanks,

-Zhengyu




More information about the hotspot-gc-dev mailing list