[crac] RFR: Use special class for exception aggregates [v5]

[Radim Vansa]

On Wed, 7 Jun 2023 11:01:05 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Radim Vansa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'crac' into code_cleanup
>>  - Remove the .Combined, always use the main exception as aggregate
>>  - Merge branch 'crac' into code_cleanup
>>  - Handle .Combined in Core
>>  - Use Combiner exception class for aggregate-only exceptions
>>  - Minor code cleanup and improvements
>
> src/java.base/share/classes/jdk/crac/Core.java line 147:
> 
>> 145:                 if (messages.length == 0) {
>> 146:                     checkpointException.addSuppressed(new RuntimeException("Native checkpoint failed"));
>> 147:                 }
> 
> codes.length == messages.length, and they are used to communicate native descriptors problems (handled in translateJVMExceptions). So a problem should be reported based on the retCode below, if that is not reported already (?)

When the checkpoint does not fail in JVM code (checking open FDs) but the engine returns non-zero status, the retCode is `JVM_CHECKPOINT_ERROR` but the messages are empty. In this case the exception would look just like CheckpointException without any explanation nor stack trace, and the user would be rather clueless.
We could add to this message a hint to check out `dump4.log`, but I am not entirely sure about this as it breaks encapsulation of CR engine (alternative implementations... though we might make CRIU use 'standardized' location) and it might not exist at all, e.g. when the CRIU binary is not present.

-------------

PR Review Comment: https://git.openjdk.org/crac/pull/64#discussion_r1221418669