CRIU: Remove CRIU debug interpreter

[tajila]

The CRIU interpreter was added here, #17245, to do

1. Enable support for hooks (needed for xtrace and xdump)
2. Allow one to avoid using the debug interpreter at starup

Now that we have the ability to transition to the debug interpreter on restore, we no longer need the criu interpreter. Instead we can start with the standard interpreter, and transition to the debug interpreter if needed.

Steps

1. Add a new field in J9CRIUCheckpointState called debugInterpreterRequested
2. The hooks for criuRestoreInitializeTrace and criuRestoreInitializeDump set the debugInterpreterRequested to true
3. In checkTransitionToDebugInterpreter check if debugInterpreterRequested is set then attempt to transition to the debug interpreter.
4. Add a new restore hook (similar to the ones above) and take the code in checkTransitionToDebugInterpreter that looks for the VMOPT_XXDEBUGINTERPRETER and move it to that function. It should set the debugInterpreterRequested if debug interpreter is there.
5. Move checkTransitionToDebugInterpreter to after runInternalJVMRestoreHooks

[singh264]

It seems like the next step is to complete the steps for removing the CRIU interpreter with the implementation that was started at singh264@b35f2b7.

[ThanHenderson]

@tajila Just to clarify, in addition to the steps mentioned in the issue description, I am assuming the higher-level goal is to also remove all code associated with criuBytecodeLoop*.

[ThanHenderson]

We have a -XX:+DebugOnRestore option and an -XX:+DebugInterpreter option.

Currently, transitionToDebugInterpreter is guarded by isDebugOnRestoreEnabled(currentThread). With the new field (I've just added a flag to vm->checkpointState.flags instead), I've added a isTransitionToDebugInterpreterRequested(currentThread) that returns true if -XX:+DebugInterpreter had been set (or if -XTrace or -Xdump was specified).

My question is: what is the relationship now between -XX:+DebugOnRestore and -XX:+DebugInterpreter?

i.e. for the new guard condition, do we have an || relationship:
isDebugOnRestoreEnabled(currentThread) || isTransitionToDebugInterpreterRequested(currentThread)

An && relationship:
isDebugOnRestoreEnabled(currentThread) && isTransitionToDebugInterpreterRequested(currentThread)

Or no relationship:
isTransitionToDebugInterpreterRequested(currentThread)

[babsingh]

@ThanHenderson For 0.48, this issue will need to be resolved by the end of this week. What's the current state of this issue? Based on this issue's impact, do we need it to be fixed in 0.48 or can it be pushed to 0.49?

[ThanHenderson]

Based on my current understanding of the issue, I have a patch ready. Just waiting on some input on my comments above (#19835 (comment) and #19835 (comment)) to clarify some things.

[tajila]

My question is: what is the relationship now between -XX:+DebugOnRestore and -XX:+DebugInterpreter?

• DebugOnRestore enables the ability for a user to request debugging capabilities on restore even if it wasnt requested at startup. These capabilities often require the debug interpreter
• DebugInterpreter (when specified on restore or startup) requests the use of the debuginterpreter as opposed to the non-debug version.

[tajila]

Or no relationship: isTransitionToDebugInterpreterRequested(currentThread)

EDIT: DebugOnRestore doesnt cause us to transition to debug interpreter, but it is a require capability that enables us to transition under the presence of jit frames.

[tajila]

Depending on the timing of when #19754 is merged either you or @JasonFengJ9 will need to request that checkpointState->debugInterpreterRequested is set if debug capabilites required the debug interpreter are requested on restore. Jason's PR will likely be merged first.