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. This can't work reliably if a method is inlined
differently at the same level like in this example.

Instead, the ReplayDataFile should contain the complete inlining tree such that recompilation can reproduce the faulting compilation more accurately.

[1] https://github.com/openjdk/jdk17u-dev/blob/852c26c0/src/hotspot/share/ci/ciReplay.cpp#L992