Question regarding ReplayCompiles and multiple inlining

[Tobias Hartmann]

Thanks, Volker. Do you have a reproducer that you could share in the bug report?

Best regards,
Tobias


On 26.06.23 17:05, Volker Simonis wrote:
> Thanks for the confirmation of the problem.
> 
> I've created "8310899:cProvide more accurate inlining information in
> ReplayDataFile" [1].
> 
> [1] https://bugs.openjdk.org/browse/JDK-8310899
> 
> On Fri, Jun 23, 2023 at 10:28 PM <dean.long at oracle.com> wrote:
>>
>> I think we need to file one.
>>
>> dl
>>
>> On 6/23/23 12:26 AM, Tobias Hartmann wrote:
>>> Should we file an RFE for this or is this already tracked?
>>>
>>> Thanks,
>>> Tobias
>>>
>>> On 22.06.23 08:35, dean.long at oracle.com wrote:
>>>> I noticed this problem before too.  Unfortunately I can't think of a workaround.  It seems like the
>>>> right fix is to change the replay file format to record more information.
>>>>
>>>> dl
>>>>
>>>> On 6/19/23 5:07 AM, Volker Simonis wrote:
>>>>> Hi,
>>>>>
>>>>> I try to reproduce a compiler issue with a ReplayDataFile but
>>>>> unfortunately I can't reproduce the crash.
>>>>>
>>>>> I hacked the VM to print out the the inlining tree just before the
>>>>> crashes and realized that the original inlining differes from the
>>>>> inlining done by ReplayCompiles.
>>>>>
>>>>> In my specific case I have the following inlining pattern during the
>>>>> crash (`foo::f1()` gets inlined twice into `foo::f0() `):
>>>>>       .
>>>>>       .
>>>>>     @ 57    foo::f0()    inline (hot)
>>>>>       @ 48    foo::f1()    inline (hot)
>>>>>         @ 2    bar::f2()    inline (hot)
>>>>>           .
>>>>>           .
>>>>>       @ 48    foo::f1()    inline (hot)
>>>>>         @ 2    bar::f2()   NodeCountInliningCutoff
>>>>>
>>>>> In the ReplayDataFile (in the `inline` part of the `compile` line)
>>>>> both, `foo::f1()` and `bar::f2()` are recorded only once (because they
>>>>> have the same  bci, name/signature and inlining depth).
>>>>>
>>>>> When running the replay, I get the following inlining pattern:
>>>>>       .
>>>>>       .
>>>>>     @ 57    foo::f0()    force inline by ciReplay
>>>>>       @ 48    foo::f1()    force inline by ciReplay
>>>>>         @ 2    bar::f2()    force inline by ciReplay
>>>>>           .
>>>>>           .
>>>>>       @ 48    foo::f1()    force inline by ciReplay
>>>>>         @ 2    bar::f2()    force inline by ciReplay
>>>>>
>>>>> This is clearly different because in the replay we inline `bar::f2()`
>>>>> a second time (while in the original run it was skipped due to
>>>>> NodeCountInliningCutoff).
>>>>>
>>>>>   From looking at `find_ciInlineRecord()` [1], it looks like the replay
>>>>> file only records the bci, inlining depth and method name/signature
>>>>> for an inlinee? How is this supposed to work if a method is inlined
>>>>> differently at the same level like in this example?
>>>>>
>>>>> Notice that I'm currently working with JDK 17 (because my problem
>>>>> doesn't reproduce with HEAD) but it seems the relevant code hasn't
>>>>> changed much in this area since JDK 17.
>>>>>
>>>>> Please let me know if this is a known problem and if there's any way
>>>>> to workaround it?
>>>>>
>>>>> Thank you and best regards,
>>>>> Volker
>>>>>
>>>>> [1] https://urldefense.com/v3/__https://github.com/openjdk/jdk17u-dev/blob/852c26c0/src/hotspot/share/ci/ciReplay.cpp*L992__;Iw!!ACWV5N9M2RV99hQ!MGIABONonnI2VqUCozMO-Yc9QZsz68ExBXIoxLS0QJ3pyI_nt2cm-PbE-M-d1mYyoLfC3KVzspXCwpSR6vWltPVUJAAm$