RFR: 8319879: Stress mode to randomize incremental inlining decision

[Tobias Hartmann]

On Tue, 14 Nov 2023 07:24:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> We had quite a few C2 bugs in the past that only reproduced with a specific sequence of incremental inlining (for example, [JDK-8319764](https://bugs.openjdk.org/browse/JDK-8319764)). We should randomize the incremental inlining decision to trigger these code paths more frequently.
>> 
>> I did some testing with the flag enabled and I hit [JDK-8319764](https://bugs.openjdk.org/browse/JDK-8319764) and [JDK-8319889](https://bugs.openjdk.org/browse/JDK-8319889). I think it's still valuable to integrate this even if these bugs are not resolved yet.
>> 
>> Thanks,
>> Tobias
>
> 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?

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

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