Mismatched ciMethodData in replay file.

[Liu, Xin]

hi,

I get a weird replay, which was generated by 17.0.3+6-LTS. I don't see
relevant code have changed since then, so I think it is still applicable
to the tip of HotSpot.

A customer shared the replay file
with(https://github.com/corretto/corretto-17/issues/57#issuecomment-1130042063)
and I am trying to reproduce his failure. it is written from
VMError::report_and_die().

One obstacle is that weird entries of ciMethodData. eg. line
14130, It declares that there will 2 non-null oops followed(see '2'
after tag 'oops'. however, one only is recorded.

ciMethodData kotlin/coroutines/jvm/internal/ContinuationImpl <init>
(Lkotlin/coroutines/Continuation;)V 2 21538 orig 80 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 data
26 0x40007 0x402 0x70 0x4e9c 0x70005 0x4d55 0x0 0x7f6a5841c3c0 0xa3
0x7f6a5841c470 0xa4 0xc0003 0x4e9c 0x18 0x110002 0x529e 0x0 0x0 0x0 0x0
0x0 0x0 0x9 0x2 0x6 0x0 oops 2 7
com/example/ProductAttRouter$withRequestLoggingContext$1 methods 0

Another mismatched entry is at line 14203. it says there are 11
oops but only 6 are there.

Those mismatched entries leave uninitialized elements of rec->_classes
and eventually crash ciReplay::initialize(). Have you seen them before?
I can patch up hotspot to handle this mismatch, but I wonder how that
happens?

ciMethodData::dump_replay_data() iterates
_data 2 rounds. The 1st round counts them and second round dumps them.
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/ciMethodData.cpp#L728

Is that possible that the underlying data get updated on the fly? This
case is kotlin coroutine. I am not
sure whether it is same threading environment as classic Java.

thanks,
--lx