Question regarding ReplayCompiles and multiple inlining

dean.long at oracle.com dean.long at oracle.com
Fri Jun 23 20:27:56 UTC 2023


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://github.com/openjdk/jdk17u-dev/blob/852c26c0/src/hotspot/share/ci/ciReplay.cpp#L992


More information about the hotspot-compiler-dev mailing list