RFR (M) 8203837: Split nmethod unloading from nmethod cache cleaning

[coleen.phillimore at oracle.com]

On 6/5/18 12:45 PM, Erik Österlund wrote:
> Hi Coleen,
>
> Looks like a nice cleanup. I don't mind the cheeky logging changes 
> squeezed into this change. Reviewed.

Thank you, Erik!

Coleen
>
> Thanks,
> /Erik
>
> On 2018-05-30 14:23, coleen.phillimore at oracle.com wrote:
>> Summary: Refactor cleaning inline caches to after GC do_unloading.
>>
>> See CR for more information.  This patch refactors 
>> CompiledMethod::do_unloading() to unload nmethods in case of 
>> !is_alive oop.  If the nmethod is not unloaded, cleans the inline 
>> caches, and exception cache, for unloaded classes and unloaded 
>> nmethods.  The CodeCache walk in gc_epilogue is moved earlier to 
>> combine with cleanup for class unloading.
>>
>> It doesn't add CodeCache walks to any of the GCs, and keeps the G1 
>> parallel nmethod unloading intact.  This patch also uses common code 
>> for CompiledMethod::clean_inline_caches which was duplicated by the 
>> G1 functions.
>>
>> The patch also fixed a case in AOT where clear_inline_caches should 
>> be called instead of clean_inline_caches.   I think neither is 
>> necessary for the nmethods that are deoptimized because of 
>> redefinition, but clear_inline_caches clears up redefined Methods* 
>> not for unloaded nmethods.  Once the method is cleaned by the 
>> sweeper, clean_inline_caches will be called on it.  clear vs. clean ...
>>
>> The patch also converts TraceScavenge to -Xlog:gc+nmethod=trace. I 
>> can revert this part and do it separately; I had just converted it 
>> while looking at the output.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8203837.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8203837
>>
>> Tested with mach5 hs-tier1-5, the gc-test-suite (including 
>> specjbb2015, dacapo, gcbasher), runThese with all GCs with and 
>> without class unloading.
>>
>> This is an enhancement that we can use for making nmethod cleaning 
>> concurrent in ZGC.
>>
>> Thanks,
>> Coleen
>