Investigate not falling back to mimicInterpreterFrameShape in extended HCR

[gacholio]

https://github.com/eclipse/openj9/blob/master/runtime/compiler/control/HookedByTheJit.cpp#L3018

When jitClassesRedefined is called with an empty list, the JIT falls back to mimicInterpreterFrameShape.

I can't recall or think of any reason for this.

[gacholio]

@fjeremic @cathyzhyi @andrewcraik @DanHeidinga

[gacholio]

I also find this distressing:

https://github.com/eclipse/openj9/blob/master/runtime/compiler/control/J9Options.cpp#L2367

[fjeremic]

I also find this distressing:

/runtime/compiler/control/J9Options.cpp@master#L2367

Tracked down the original author of this from the internal repo before we open sourced. It's in SHA 6511ab44c047f4381f50900adba4af79ffefc6ee. Author was @cathyzhyi with the following message:

Force TR_MimicInterpreterFrameShape for fsd for relocatable methods

AOT compilation doesn't support full speed debug yet and still use
mimic interpreter frame shape. TR_MimicInterpreterFrameShape is set
on AOTCmdLineOptions so that this limitation only applies to
relocatable methods in AOT runs.

[gacholio]

OK great, just wanted to make sure we weren't paying that penalty in more common cases.

[DanHeidinga]

For the original question, jitClassesRedefined has an early bailout with the following condition:

https://github.com/eclipse/openj9/blob/ef3a31de6cbb8667d89c1a35be84e81cc7bf032f/runtime/compiler/control/HookedByTheJit.cpp#L2828

which would prevent hitting the case which forces mimicInterpreterFrameShape but I can't find any code that sets TR_EnableHCR (though I would have expected it to the be the default).

@fjeremic @andrewcraik @cathyzhyi Thoughts?

[gacholio]

EnableHCR is only true for fast HCR, afaik, not FSD.

[andrewcraik]

+1 to @gacholio see the enablement logic in the J9 options processing:
https://github.com/eclipse/openj9/blob/ef3a31de6cbb8667d89c1a35be84e81cc7bf032f/runtime/compiler/control/J9Options.cpp#L2308

The TR_EnableHCR triggers the generation of HCR guards in the JIT code etc (eg fastHCR) which is not needed during FSD since an OSR will occur when necessary is my understanding.

[cathyzhyi]

https://github.com/eclipse/openj9/blob/ba36fc7f5c165a01ef928e82250f237980cfbf71/runtime/compiler/control/HookedByTheJit.cpp#L3018-L3019

Had an offline chat with @gacholio , the problem is that the condition (classCount == 0 || classList == NULL) is true for both extended HCR and data break point (field watch in this case). Not falling back to mimic interpreter frame shape would break extended HCR.

[gacholio]

I can't think of any reason this should break extended HCR. The test you showed me yesterday looked like a CHTable issue (not properly detecting override and going infinitely recursive).

[gacholio]

As we don't have time to figure out the extended HCR behaviour, we'll just add a new call for data breakpoints to flush the compilation queue.

I'll leave this open to investigate removing mimic in the future.