JDK-8292561 : Make "ReplayCompiles" a diagnostic product switch
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 20
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-08-17
  • Updated: 2023-08-23
  • Resolved: 2022-08-21
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 20
20 b12Fixed
Related Reports
Relates :  
JDK-8314838 - 3 compiler tests ignore vm flags
Relates :  
JDK-8308657 - ReplayInline is not availabe in production build
Relates :  
JDK-8302004 - InlineTree should consult replay file in release build
Description
See https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2022-August/057988.html

It would help to have ReplayCompiles available in release builds:

- to experiment what its effect is on a VM that was actually shipped to customers, without using a debug VM and switching tens of asserts off.
E.g., in the case of https://bugs.openjdk.org/browse/JDK-8291665, how steep and how quickly RSS raises, and whether the raise limits itself or is infinite.
- to see whether a certain build of a shipped VM is actually affected by a certain bug.
Comments
yes, there's another section in InlineTree::should_inline(). let's use JDK-8302004 to track this.
07-02-2023
[~xliu] You are right. I think there was confusion with -XX:CompileCommand=option,Benchmark::test,DumpInline functionality which is available only in not product. But ciReplay::should_inline() and other methods checks both C->replay_inline_data() and data from normal replay file. So you are correct - this code should not be under #ifndef PRODUCT. We need to check other places in opto/ files too. File related bug. We can first fix it in JDK 21 and then backport into 20 Update release.
07-02-2023
hi, @stuefe @vnkozlov This feature is very helpful. Today, I stumbled into the following code snippet in 'InlineTree::should_not_inline'. It uses InlineTree(ILT) from the replay file rather than computing in runtime. With the guard '#ifndef PRODUCT', can we still "replay" the exactly same ILT from the replay file in Release Builds? Did we overlook it in code review? #ifndef PRODUCT int inline_depth = inline_level() + 1; if (ciReplay::should_inline(C->replay_inline_data(), callee_method, caller_bci, inline_depth, should_delay)) { if (should_delay) { set_msg("force (incremental) inline by ciReplay"); } else { set_msg("force inline by ciReplay"); } return false; } if (ciReplay::should_not_inline(C->replay_inline_data(), callee_method, caller_bci, inline_depth)) { set_msg("disallowed by ciReplay"); return true; } if (ciReplay::should_not_inline(callee_method)) { set_msg("disallowed by ciReplay"); return true; } #endif
05-02-2023
Changeset: f9004fe4 Author: Thomas Stuefe <stuefe@openjdk.org> Date: 2022-08-21 06:59:20 +0000 URL: https://git.openjdk.org/jdk/commit/f9004fe4438c30eb639e3c36e6531c306b836e36
21-08-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/9935 Date: 2022-08-19 06:53:08 +0000
19-08-2022
A bit more complex than I thought. - Making this a product switch will segfault a release VM because of https://bugs.openjdk.org/browse/JDK-8292590. That can be worked around by omitting to set DebuggerErgo for release builds - Tests are a bit tricky. Just enabling the ciReplay tests for release does not work. These test rely on -XX:CiCrashAt... which is not available in release builds. This could potentially be rewritten once we have malloc limits for NMT (https://bugs.openjdk.org/browse/JDK-8291878) which would allow us to artificially induce crashes in compiler threads by severely limiting the compile arena from growing.
18-08-2022