RFR: 8214897: ZGC: Concurrent Class Unloading

[Per Liden]

On 12/10/18 2:18 PM, Erik Österlund wrote:
> 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.

Great work everyone!

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

Looks good!

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

For those interested, a pause time comparison between JDK 11 and JDK 12 
running SPECjbb2015 (composite mode, 128G heap, 32 hw-threads) looks 
like this:

JDK 11: Avg=1.10ms, Max=1.96ms  (without class unloading)
JDK 12: Avg=0.59ms, Max=1.59ms  (with class unloading)

So this takes us one step closer to our long term goal of having 
sub-millisecond max pause times. Awesome!

cheers,
Per