CRIU: Debugging restored images

[tajila]

Users will need to be able to debug restored images using CRIU. There are two ways of handling this:

Dynamic enablement of debug capabilities: With this approach we will dynamically enable debugging capabilities for a restored image upon user request. This approach has the following challenges:

• we will need to fixup a bunch of method (all non-large stack) send targets to use J9_BCLOOP_SEND_TARGET_ZEROING
• we will need to load a jvmtiagent (that wasn't loaded before) so lots of hooks would be unhooked in the original vm
  • these hooks would need to be registered
  • any TI mechanism that relies on the JVMTI_PHASE_PRIMORDIAL or JVMTI_PHASE_START phase may not work at all
  • any TI mechanism that relies on the ClassFileLoadHook may not work either if class was loaded before checkpoint
• we may need to recompile a bunch of java methods

Static enablement of debug capabilites: With this approach the user requests debug capabilities prior to image build time. This means that we can start the JVM with debug capabilites built-in. At restore time a debugger can be attached to the JVM process. This approach has the following drawbacks:

• Performance with debug capabilities will be worse than the non-debug enabled images

[tajila]

@gacholio @DanHeidinga any other thoughts on this?

[DanHeidinga]

• we will need to fixup a bunch of method (all non-large stack) send targets to use J9_BCLOOP_SEND_TARGET_ZEROING

We'll also need to switch from the the regular stack mapper (which does forward flow analysis for live ranges) to the debug stack mapper (which does liveness more conservatively so it matches the debuggers expectations).

These two coupled together may mean that we have "garbage" (non zero) stack slots that suddenly appear live. This may be fixable (without having looked at the code) if we do a stack walk and zero all oslots identified by the debugger mapper that aren't also identified by the regular stack mapper.

We can probably handle this as a global exclusive action when restoring the image in debug mode

[DanHeidinga]

@tajila This looks like a good starting point on the different approaches. To really flesh out all the details though, we'll need to make a table that shows the different actions taken in the debug scenario vs the non-debug scenarios so we can figure out what the differences are.

If we can also add the jvmti capabilities supported by each of the different rows in the table, that would be an ideal data source.

Having it clearly specified that way may help us determine the set of capabilities to support in debug mode on restore (if we feel we don't need to support all of them), and may expose opportunities for other debug improvements (ie: late enablement of capabilities)

[gacholio]

I doubt this will work without significant effort. Also, any JIT code will need to be discarded because debug mode (FSD) code generation is completely different from the normal.