JDK-8254110 : support replay during normal execution
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 16
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2020-10-07
  • Updated: 2022-11-30
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.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8262912 - ciReplay: replay does not simulate unresolved classes
Blocks :  
JDK-8273919 - Improve compiler replay
Description
A useful feature might be to support replay compilation during normal program execution, i.e. use the information from the replay file once the compilation of the corresponding method is triggered

The fix for JDK-8297389 removed the MethodData_lock from process_ciMethodData because that method is currently only executed by one thread. If multiple threads are going to execute it, we need to use atomic operations or re-introduce the lock.
Comments
Things to keep in mind when implementing this enhancement, taken from the review of JDK-8262912: Dean Long: There's a memory leak with the global mirror jobjects that will need to be fixed for JDK-8254110. One way to do this might be to prune your replay white list as klasses are added to _ci_metadata. That would mean moving your white list check until we check for existing klasses in _ci_metadata. Also, you could reduce the number of JNI global refs needed by putting the mirror objects in an array, then storing the array in a single JNI global ref, or adding it to what gets scanned by CompileTask::metadata_do or ciEnv::metadata_do, but I think that can wait until JDK-8254110 too.
15-10-2021
[~dlong] Yes, we experienced with these different options a bit while working on the "Profile Caching" idea (we also published a paper [1] back then) which is basically a prototype implementation of this. [1] http://cr.openjdk.java.net/~thartmann/papers/2017-ManLang-Profile_Caching.pdf
14-09-2021
[~thartmann] The target method will probably be recompiled more than once. I assume we would record each in a separate file, and then at replay time do one of the following: 1) replay only the last recorded compile 2) replay all the recorded compiles in recorded order, ignoring compilation level 3) replay according to compilation level, in recorded order 4) make the user choose and we could either replay the compiles eagerly or when triggered normally. I am guessing that if the miscompiled method produces a crash, then the last recorded compile will usually be to blame, and the problem may not show up on the first execution of the method, so replaying eagerly (like crash replay does) might not give the desired result.
11-09-2021
[~dlong] the goal of this feature would be to help with debugging extremely intermittent crashes in compiled code or wrong execution bugs. For example, when a C2 compiled method produces a wrong result, a replay compilation file for that method could be generated via -XX:CompileCommand=dump while running the intermittent reproducer for a long time on a server machine. Using that replay file during normal execution would then allow to reproduce and debug the issue reliably.
05-08-2021
[~thartmann], this sounds similar to the InlineDataFile compile command. Is it related?
05-08-2021