JDK-8029091 : Bug in calculation of code cache sweeping interval
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-11-25
  • Updated: 2014-07-29
  • Resolved: 2014-01-15
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 8 JDK 9
8u20 b01Fixed 9Fixed
Description
The calculation of wait_until_next_sweep in NMethodSweeper::possibly_sweep() {} has a signed to unsigned conversion bug. The calculation was done as follows:

double wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - time_since_last_sweep  -      CodeCache::reverse_free_ratio();

Since the type of ReservedCodeCacheSize (uintx) has a higher rank than time_since_last_sleep (int) and time_since_last_sweep can be larger than (ReservedCodeCacheSize / (16 * M))  there is an underflow. Consequently, wait_until_next_sweep is assigned a high value, which disables the intended periodic code cache sweeps. The current version will run the sweeper only if the code cache is full or the accumulated size of all nmethods that changed 
their state size the last sweep is larger than 1% of the ReservedCodeCacheSize.
Comments
This bug can cause serious performance regressions with small code cache sizes. The attached graph shows more than 10X for a ReservedCodecCacheSize of 2m. More details on the graph: - x-axis: benchmark - y-axis: Relative performance FACTOR. The graph compares the execution time of specjvm98 benchmarks with (new version) and without the proposed fix (old version) . A number < 0 on the y-axis means that the original version is faster than the new version. A value of 0 on the y-axis means that both versions are equally fast. A value > 1 on the y-axis means that the new version is faster than the old version. The data is obtained from a 32-bit client VM (linux). The presented results are the arithmetic average over 20 runs.
06-12-2013
Release team: On second thought this doesn't seem like a showstopper for JDK 8 so we're deferring this to 8u20.
03-12-2013
Release team: What are the risks involved in this?
03-12-2013
In its current version, the intended periodic code cache sweeps are disabled due to an integer underflow as described above. The periodic code cache sweeps remove unused code from the code cache. ILW=MMH Impact=Medium: There are some applications that have high code cache demands and suffer from a serious performance degradation of compilation is disabled (e.g., 8020151) Likelyhood: Medium: There are some applications that have high code cache demands (e.g., WebLogic) Workaround: High: With the current code in place, there is no way to enable periodic code cache sweeps.
26-11-2013
This changeset introduces the problem
25-11-2013