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

[Tobias Hartmann]

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
>