JDK-8211129 : compiler/whitebox/ForceNMethodSweepTest.java fails after JDK-8132849
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-09-25
  • Updated: 2021-09-24
  • Resolved: 2018-10-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12
11.0.8-oracleFixed 12 b14Fixed
Related Reports
Duplicate :  
JDK-8211141 - jdk/jfr/event/compiler/TestCodeSweeperStats.java fails with Error: Value not atLeast1, field='sweepCount'
Relates :  
JDK-8215555 - TieredCompilation C2 threads can excessively block handshakes
Relates :  
JDK-8132849 - Increased stop time in cleanup phase because of single-threaded walk of thread stacks in NMethodSweeper::mark_active_nmethods()
Sub Tasks
JDK-8211134 :  
problem list compiler/whitebox/ForceNMethodSweepTest.java - Resolved
Description
Failure message:

on exception 'sweep after deoptimization should decrease usage: expected that 1477504 < 1477504':
Comments
Hi, we are interested in backporting this fix to 11u, as it might affect nmethod hotness for -XX:+UseCodeCacheFlushing. Could anyone clarify the dependencies of this change? Should we backport JDK-8132849 and JDK-8215555 together with this change?
24-11-2020
Fix request (11u) -- Don't downport for now, was backed out from 11.0.8-oracle.
28-04-2020
URL: http://hg.openjdk.java.net/jdk/jdk/rev/c5b97602cd4b User: rkennke Date: 2018-10-01 18:24:09 +0000
01-10-2018
Yup. I knew your fix was out for review. I was just surprised that TestCodeSweeperStats.java wasn't ProblemListed at the same time that ForceNMethodSweepTest.java was...
01-10-2018
Thanks, Dan. This here should fix it: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-September/030720.html It's reviewed and currently waiting for jdk/submit to go green.
01-10-2018
This bug also affects the following test: jdk/jfr/event/compiler/TestCodeSweeperStats.java Here are the logs for my jdk-12+13 Linux-X64 sightings: $ unzip -l jdk-12+13_linux.8211129.zip Archive: jdk-12+13_linux.8211129.zip Length Date Time Name --------- ---------- ----- ---- 20037 09-27-2018 22:08 jdk-12+13_1/TestCodeSweeperStats.jtr.fastdebug 19946 09-27-2018 23:22 jdk-12+13_1/TestCodeSweeperStats.jtr.release 28170 09-27-2018 19:12 jdk-12+13_1/TestCodeSweeperStats.jtr.slowdebug 28131 09-28-2018 23:35 jdk-12+13_2/TestCodeSweeperStats.jtr.fastdebug 27970 09-29-2018 00:49 jdk-12+13_2/TestCodeSweeperStats.jtr.release 28140 09-28-2018 20:39 jdk-12+13_2/TestCodeSweeperStats.jtr.slowdebug 28159 09-30-2018 01:19 jdk-12+13_3/TestCodeSweeperStats.jtr.fastdebug 27969 09-30-2018 02:34 jdk-12+13_3/TestCodeSweeperStats.jtr.release 28139 09-29-2018 22:22 jdk-12+13_3/TestCodeSweeperStats.jtr.slowdebug --------- ------- 236661 9 files Here are the logs for my jdk-12+13 Solaris-X64 sightings: $ unzip -l jdk-12+13_solx64.8211129.zip Archive: jdk-12+13_solx64.8211129.zip Length Date Time Name --------- ---------- ----- ---- 20072 09-28-2018 00:02 jdk-12+13_1/TestCodeSweeperStats.jtr.fastdebug 19981 09-28-2018 01:26 jdk-12+13_1/TestCodeSweeperStats.jtr.release 28221 09-27-2018 20:47 jdk-12+13_1/TestCodeSweeperStats.jtr.slowdebug 28183 09-28-2018 23:19 jdk-12+13_2/TestCodeSweeperStats.jtr.fastdebug 28025 09-29-2018 00:38 jdk-12+13_2/TestCodeSweeperStats.jtr.release 28193 09-28-2018 20:06 jdk-12+13_2/TestCodeSweeperStats.jtr.slowdebug 28211 09-29-2018 22:32 jdk-12+13_3/TestCodeSweeperStats.jtr.fastdebug 28056 09-29-2018 23:53 jdk-12+13_3/TestCodeSweeperStats.jtr.release 28191 09-29-2018 19:19 jdk-12+13_3/TestCodeSweeperStats.jtr.slowdebug --------- ------- 237133 9 files
01-10-2018
Moving this to hotspot/compiler and removing "[Testbug]". ILW = Code cache sweeping is not triggered, affects several tests, no workaround = MMH = P3
26-09-2018
The reason for the failure is here: double free_percent = 1 / CodeCache::reverse_free_ratio(CodeBlobType::MethodNonProfiled) * 100; if (free_percent <= StartAggressiveSweepingAt) { do_stack_scanning(); } If it doesn't meet the threshold, it wouldn't do stack-scanning (i.e. nmethod-marking) and thus doesn't find nmethods to actually sweep. Before the change this wouldn't be a problem, because it would *always* scan stacks in safepoint-cleanup-phase, and thus find nmethods to sweep after deopt. A quick fix would be: if (free_percent <= StartAggressiveSweepingAt || _force_sweep) { .. } But I wonder if we need better heuristics for kicking off sweeps?
25-09-2018
Assigned for triage
25-09-2018