[9] RFR(S): 8134493: Cleaning inline caches of unloaded nmethods should be done in sweeper

[Tobias Hartmann]

Thanks, Vladimir.

On 28.08.2015 04:51, Vladimir Kozlov wrote:
> CodeCache::gc_epilogue() could be optimized more. When needs_cache_clean() is false we need to execute loop only in debug VM.

Right, I changed the implementation to only execute the loop in the product VM if needs_cache_clean() is set and always execute it in the debug VM. Like this we also save the needs_cache_clean() checks in each loop iteration in the product VM.

I changed nmethod::can_not_entrant_be_converted() to can_convert_to_zombie() because the name was misleading and caused some misconceptions in the past.

http://cr.openjdk.java.net/~thartmann/8134493/webrev.01/

Best,
Tobias

> 
> Otherwise it looks good.
> 
> Thanks,
> Vladimir
> 
> On 8/27/15 12:10 AM, Tobias Hartmann wrote:
>> Hi,
>>
>> please review the following patch.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8134493
>> http://cr.openjdk.java.net/~thartmann/8134493/webrev.00/
>>
>> Problem:
>> This is a follow up on JDK-8075805 [1] which modified CodeCache::gc_epilogue() to clean the ICs of unloaded nmethods as well. The problem is that this code is executed at a safepoint and may affect safepoint duration. The other changes of JDK-8134493 are fine.
>>
>> Solution:
>> We do the cleaning of unloaded nmethods at the unloaded -> zombie transition in the sweeper. I also modified nmethod::cleanup_inline_caches() to not emit any transition stubs if the nmethod is already dead.
>>
>> As Martin Doerr pointed out in another thread, we have to be careful with accessing CompiledIC::cached_metadata() of unloaded nmethods. For example, the following scenario may happen (IC of A references B):
>>
>>      state of A       state of B
>> -------------------------------
>>      not-entrant
>> S   [not-on-stack]
>> S   zombie
>>                  unloaded
>>
>> Now the IC of A still references the unloaded nmethod B and is_call_to_compiled() will access the unloaded metadata. I fixed this by checking caller->is_alive().
>>
>> Thanks,
>> Tobias
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8075805
>>
>>