JDK-8253118 : Avoid unnecessary deopts when OSR nmethods of the same level are present.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-09-14
  • Updated: 2021-01-04
  • Resolved: 2020-10-02
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 16
11.0.10-oracleFixed 16 b19Fixed
Related Reports
Relates :  
Description
The tiered policy will erroneously attempt to switch to an OSR nmethod of the same level (level 2 and level 3 are affected) from a normal nmethod. This is especially problematic when running with -XX:TieredStopAtLevel={2 or 3}.
Comments
11u is not affected by this unnecessary deopts problem. "[GR-15425] Ensure not compilable OSR at level 4 falls back to level 1." makes sense in general, but seems to be more relevant for Graal and was introduced by JDK-8225019, too. I don't see such problems with the current 11u code.
10-11-2020

Hi Igor, is this introduced by "[GR-15425] Ensure not compilable OSR at level 4 falls back to level 1." ? That change is in 11.0.7-oracle and jdk. It came in with "JDK-8225019: Update JVMCI". I am wondering because we did not downport 8225019 to open 11u, so we might not need this follow up here.
15-10-2020

Changeset: b9505df3 Author: Igor Veresov <iveresov@openjdk.org> Date: 2020-10-02 02:22:56 +0000 URL: https://git.openjdk.java.net/jdk/commit/b9505df3
02-10-2020