RFR: 8319879: Stress mode to randomize incremental inlining decision

[Jatin Bhateja]

On Tue, 14 Nov 2023 09:25:21 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> src/hotspot/share/opto/doCall.cpp line 188:
>> 
>>> 186:     if (!call_does_dispatch) {
>>> 187:       InlineTree* ilt = InlineTree::find_subtree_from_root(this->ilt(), jvms->caller(), jvms->method());
>>> 188:       bool should_delay = AlwaysIncrementalInline || (StressIncrementalInlining && (C->random() % 2) == 0);
>> 
>> Any specific reason to keep vector, string , boxing call generators out of scope, I understand that lazy intrinsification gives constants and opportunity to seep in the graph and enable meeting closed world compilation constraints, but this is a stress testing option,  an eager failed intrinsification will take the control flow to [line# 214](https://github.com/openjdk/jdk/pull/16597/files#diff-3193ffb06a457828099ec450d72afd32942635de23191d70ec3bf3f349ca45feL214) , but only if we randomize creating LateInlineCallGenerators for these APIs.
>
> What do you mean by keeping them out of scope? String, boxing and vector methods will be late inlined if the respective `should_delay_*_inlining` method returns true. Otherwise, the stress option might still trigger late inlining randomly. Isn't that exactly what we want? Or do you suggest to check `should_delay` first?

Exactly, should_delay_vector_inlining is not affected by newly added option.  Yes, should_delay check should be earlier if we intend to randomize inlining decisions for vector , boxing methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16597#discussion_r1392788334