[11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK 11

[Vladimir Kozlov]

+1

Thanks,
Vladimir K

On 10/12/20 5:29 AM, Tobias Hartmann wrote:
> Hi Nils,
> 
> looks good to me.
> 
> Best regards,
> Tobias
> 
> On 09.10.20 16:34, Nils Eliasson wrote:
>> Hi,
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8254185
>> Webrev: http://cr.openjdk.java.net/~neliasso/8254185/webrev.01/
>>
>> This fix is a replacement for JDK-8244660 that I consider to risky to back port.
>>
>> This issue can't be seen unless JDK-8254185 is applied. That bug causes the sweeper to trigger on every code cache 
>> allocation. When JDK-8254185 is applied then no sweeps can be observed at all.
>>
>> The main issue is that the sweeper thread is never woken. And if it isn't woken, it can't check the counters to see if 
>> it is time to sweep.
>>
>> This fix include two changes:
>>
>> 1) Notifying waiters on the codecache_lock when a threshold for reclaimed nmethods has been reached. This fix is 
>> enough on its own.
>>
>> In JDK 15 I introduced a new lock for the sweeper because a adding a notify in NMethodSweeper::possibly_enable_sweeper 
>> conflicted with the compiledMethod_lock in add_osr_method. That lock was added when deoptimization was converted to 
>> using handshakes. So in 11 it is still ok to use the codecache_lock.
>>
>> 2) Moving the updates of _total_nof_code_cache_sweeps and _last_sweep inside block that is only run when doing a sweep.
>> This change just makes the counters update as expected. _last_sweep is used to trigger sweeps after a number of 
>> safepoints. This is counted by _time_counter. But since updates of _time_counter doesn't wake the sweeper - it still 
>> doesn't work.
>>
>> In JDK 15 I removed all of this code since we can't even rely on safepoints happening at all. I don't want to 
>> introduce any bugs in JDK 11 by mistake - so I am leaving it as it is.
>>
>> Please review.
>>
>> Best regards,
>> Nils Eliasson
>>