JDK-8254108 : ciReplay: Support incremental inlining
Type:Enhancement
Component:hotspot
Sub-Component:compiler
Affected Version:16,17,18
Priority:P4
Status:Resolved
Resolution:Fixed
Submitted:2020-10-07
Updated:2023-08-31
Resolved:2021-11-23
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.
[~dlong] the problem is that the replay compilation file does not keep track of how a method was inlined (i.e., "normal" or incremental). Let's assume method foo was *incrementally* inlined into method bar during the failing compilation, the replay compilation file will simply force normal, "early" inlining of m and that can lead to completely different IR shapes during parsing. At least that's what I thought I was observing a while ago, when an issue only reproduced with replay compilation with -XX:+AlwaysIncrementalInline. But maybe I've missed something.
The "different C2 flags due to ergonomics" problem is unrelated to this. It could be solved by recording the flag settings in the replay file.
05-08-2021
[~thartmann], could you please add details here? Incremental Inlining seems to be the default and I don't see replay turning it off.
However, a good question is what should replay do if run with conflicting flags? Bail out like AOT did, or overwrite the flag settings?
Either say, it seems like replay would need to record relevant flags into the replay file.