Question regarding ReplayCompiles and multiple inlining

Volker Simonis volker.simonis at gmail.com
Mon Jun 26 15:05:52 UTC 2023


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


More information about the hotspot-compiler-dev mailing list