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

[Lindenmaier, Goetz]

Hi Nils, 

Do I understand correctly that after this fix I should also push 
"8244278: Excessive code cache flushes and sweeps" ?
https://bugs.openjdk.java.net/browse/JDK-8244278

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On Behalf
> Of Nils Eliasson
> Sent: Friday, October 9, 2020 4:35 PM
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR: 8254185: Fix Code cache sweeper heuristics for JDK 11
> 
> 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