Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add error check for checkpointGCThreads #18617

Closed

Conversation

kangyining
Copy link
Contributor

Add error check in gcParseXXArguments() for -XX:CheckpointGCThread=
to make sure it cannot be larger than the existing gcthreads value.

Signed off by: [email protected]

Add error check in gcParseXXArguments() for -XX:CheckpointGCThread=
to make sure it cannot be larger than the existing gcthreads value.

Signed off by: [email protected]
@tajila
Copy link
Contributor

tajila commented Dec 13, 2023

The docs mention, https://eclipse.dev/openj9/docs/xxcheckpointgcthread/

If you have not specified the GC thread count in the -Xgcthreads option or if the thread count is less than the
 checkpoint GC threads, then the VM determines the default thread count (as explained in the [-Xgcthreads](https://eclipse.dev/openj9/docs/xgcthreads/#explanation) 
topic) at restore. If the default thread count is greater than the checkpoint thread count, then the VM 
increases the thread count to the default thread count.

If the default thread count is lesser than the checkpoint thread count, then the thread count 
at restore time is same as the checkpoint thread count.

Do you know where this is done?

@tajila
Copy link
Contributor

tajila commented Dec 13, 2023

Also, this behaviour needs a warning message

If the <number> is greater than the number of GC threads at startup, the VM ignores this option.

@@ -1439,6 +1439,10 @@ gcParseXXArguments(J9JavaVM *vm)
j9nls_printf(PORTLIB, J9NLS_ERROR, J9NLS_GC_OPTIONS_VALUE_MUST_BE_ABOVE, "-XX:CheckpointGCThreads=", (UDATA)0);
goto _error;
}
if (extensions->checkpointGCthreadCount > extensions->gcThreadCount) {
j9nls_printf(PORTLIB, J9NLS_ERROR, J9NLS_GC_OPTIONS_MUST_BE_NO_GREATER_THAN, "-XX:CheckpointGCThreads=", VMOPT_XGCTHREADS);
goto _error;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The JVM shouldn't fail, but a warning message should be printed indicating that the option wasn't respected.

@tajila tajila requested a review from amicic December 13, 2023 21:26
@amicic
Copy link
Contributor

amicic commented Dec 14, 2023

At the moment this change is incomplete/incorrect since it's trying to address only the case when both CheckpointGCThread and Xgcthreads option are specified. There are other scenarios where one option is specified and the other is not, and for some of those the checks need to be on other places in code, if we want to issue an warning message.

For example, if gcthreads is not specified, the count is determined at a later point, after the parsing is done. And if CheckpointGCThread is specified, the current check will actually detect that CheckpointGCThread > gcthreads, but only because gcthreads is still 0.

If I understand correctly, how we currently deal with CheckpointGCThread > gcthreads scerario, is that we just silently adjust CheckpointGCThread to be equal to gcthreads. Simply, we do not do any gcthread pool contraction during prepare-for-checkpoint stage, and leave the gcthread pool intact.

Perhaps a simpler approach is just to issue a warning/informational message during that prepare-for-checkpoint stage if we contracted (and to what count) the gcthread pool? We can consider it to be a message be a part of VGC or just a general stderr one....

The is different from the attempted approach to detect/warn about this inequality during startup phase of checkpoint run. Perhpas still a valid approach, but more slightly more complex since more spots in the code have to be covered....

@kangyining
Copy link
Contributor Author

close this as a new one to warn has been created

@kangyining kangyining closed this Jan 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants