GC Thread Pool Tuning for CRIU

[RSalman]

Integrate CRIU support with new OMR GC APIs for thread pool adjustments, contract the thread pool for checkpoint and expand it for restore.

For background, see eclipse-omr/omr#6831.

• Introduced j9gc_prepare_for_checkpoint and j9gc_reinitialize_for_restore APIs to consolidate GC specific routines used for checkpoint/restore
  Report J9NLS_GC_FAILED_TO_INSTANTIATE_TASK_DISPATCHER on j9gc_reinitialize_for_restore failure
• Introduced -XX:CheckpointGCThreads= option to allow the user to tune checkpoint thread count

Depends on: eclipse-omr/omr#6831

Signed-off-by: Salman Rana salman.rana@ibm.com

[RSalman]

@tajila @amicic @dmitripivkine please have a look

[RSalman]

Following changes made in latest commit to address review comments:

• MM API:
  • Renamedj9gc_criu_checkPoint -> j9gc_prepare_for_checkpoint
  • Renamed j9gc_criu_restore -> j9gc_reinitialize_for_restore
  • Generalized to call a higher level class for checkpoint/restore, call goes through configuration now rather than directly to dispatcher
• Removed restoreGCthreadCount option
• Extended threadCleanup (thread shutdown) condition with !VM_CRIUHelpers::isJVMInSingleThreadMode(vm) to ensure non-java threads don't run cleanup code in single thread mode

[RSalman]

@tajila I'm trying to understand the failure path for restore.

We're thinking to fail if we can't startup threads on restore, something like this:

if (FALSE == vm->memoryManagerFunctions->j9gc_reinitialize_for_restore(currentThread)) {
			//FAIL PATH, return error message?
}

This will be similar to whats done with JVM startup when initing GC components and starting threads. If the dispatcher fails to startup the threads, then an error is returned and error message is printed:

gcStartupHeapManagement(J9JavaVM *javaVM)
{
...
	if (!extensions->dispatcher->startUpThreads()) {
		extensions->dispatcher->shutDownThreads();
		result = JNI_ENOMEM;
	}

	if (JNI_OK != result) {
		PORT_ACCESS_FROM_JAVAVM(javaVM);
		extensions->getGlobalCollector()->collectorShutdown(extensions);
		j9nls_printf(PORTLIB, J9NLS_ERROR, J9NLS_GC_FAILED_TO_STARTUP_GARBAGE_COLLECTOR);
		return result;
	}

[RSalman]

I suppose we can forgo failing and simply continue on with the threads in checkpoint + how many ever we were able to startup

[tajila]

//FAIL PATH, return error message?

you can add an error message similar to the others describing what went wrong and thrown a JVMRestoreException

[tajila]

I suppose we can forgo failing and simply continue on with the threads in checkpoint + how many ever we were able to startup

It may be better to fail than to restore incorrectly. If we cant restore GC threads, theres a good chance will hit the OOM somewhere else.

[amicic]

I'll let @tajila handle the final review/testing/merge

[tajila]

Jenkins test sanity xlinuxcriu jdk17

[tajila]

@RSalman

18:41:26  /home/jenkins/workspace/Build_JDK17_x86-64_linux_criu_Personal/openj9/runtime/criusupport/criusupport.cpp:654:32: error: 'J9JavaVM' {aka 'struct J9JavaVM'} has no member named 'criuJVMRestoreExceptionClass'
18:41:26    654 |    currentExceptionClass = vm->criuJVMRestoreExceptionClass;

You need to rebase your changes. It is vm->checkpointState.criuJVMRestoreExceptionClass now

[tajila]

Jenkins test sanity xlinuxcriu jdk17