RFR: 8214897: ZGC: Concurrent Class Unloading

[Erik Österlund]

Hi Per,

Thanks for the review!

/Erik

On 2018-12-10 14:43, Per Liden wrote:
> 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