RFR: 8214897: ZGC: Concurrent Class Unloading

Erik Österlund erik.osterlund at oracle.com
Mon Dec 10 13:18:22 UTC 2018


Hi,

Currently, ZGC lacks class unloading. We did not want this to be a STW 
operation, because we care a lot about our latencies. Therefore, this 
patch provides a concurrent class unloading implementation for ZGC.

First of all, I would like to thank Per for going through this patch and 
making many improvements and cleanups to it. I would also like to thank 
StefanK who started this investigation. And Coleen for helping me 
prepare our runtime for this patch.

All patches to prepare our runtime for concurrent class unloading have 
already been upstreamed at this point, and with this patch, we are 
plugging ZGC into the provided framework for concurrent class unloading.

The main operation for concurrent class unloading is 1) unlinking of all 
data structures that died due to class unloading, 2) a handshake with 
all JavaThreads, 3) purging of the data that was unlinked in step 1.
We plug in an nmethod entry barrier that heals oops and lazily resolves 
CompiledICs to unloading nmethods, adjust the ZNMethodTable to support 
unlinking and purging of nmethods that are unloading.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8214897

Webrev:
http://cr.openjdk.java.net/~eosterlund/8214897/webrev.00/

Testing: tier1-6, gc-test-suite, manual ad-hoc testing of unloading 
stress tests.
We have run performance tests to check for regressions. No statistically 
significant regression was found in throughput or marking times. What we 
could observe though is consistently better GC pause times, as the 
CodeCache is no longer traversed in a safepoint after these changes. 
Instead, it is processed concurrently with the help of nmethod entry 
barriers.

Thanks,
/Erik



More information about the hotspot-gc-dev mailing list