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

Nils Eliasson nils.eliasson at oracle.com
Fri Oct 9 14:34:47 UTC 2020


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



More information about the jdk-updates-dev mailing list