[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