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