RFR: 8254108: ciReplay: Support incremental inlining [v2]

[Christian Hagedorn]

On Tue, 16 Nov 2021 22:06:12 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update comments, should_delay and parsing inline_late, fix test if run with -XX:+AlwaysIncrementalInline
>
> src/hotspot/share/ci/ciReplay.cpp line 775:
> 
>> 773:               // Pending exception?
>> 774:               break;
>> 775:             }
> 
> I don't see how a pending exception is possible here, given the check at L763, and parse_int() doesn't throw any.
> What do you think about not calling parse_int() if _version < 2, that way there is no error to ignore?

I think that's a better idea to not parse it at all now that we have version numbers available.

> src/hotspot/share/opto/bytecodeInfo.cpp line 609:
> 
>> 607:     InlineTree* callee_tree = build_inline_tree_for_callee(callee_method, jvms, caller_bci);
>> 608:     if (should_delay || AlwaysIncrementalInline) {
>> 609:       callee_tree->set_late_inline();
> 
> It took me a while to figure out why this is needed: for replay.  It bothers me a little that AlwaysIncrementalInline is check here and again in the caller.  If the replay file sets should_delay to false, then we shouldn't let AlwaysIncrementalInline to force it to true, right?  So I'm wondering if it would be better to pre-set should_delay to true in the caller if AlwaysIncrementalInline is true.

I've added a comment to make it more clear. So, this code is only to record the late inlining decision to later dump it to the replay file. I think initializing `should_delay = AlwaysIncrementalInline` is a good idea. `should_delay` can only become true but not false anymore during normal compilation. 

But I think we need to leave `|| AlwaysIncrementalInline` in here https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/doCall.cpp#L192 in case someone wants to replay compile with that flag even though the replay file recorded a different late inlining decision.

I also fixed the test if run with `-XX:+AlwaysIncrementalInline`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6413