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

[Nils Eliasson]

Thank you Tobias!

// Nils


On 2020-10-12 14:29, 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
>>