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

[Anton Kozlov]

On Wed, 7 Jun 2023 11:27:30 GMT, Radim Vansa <duke at openjdk.org> wrote:

>> 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.

Oh, I see. The problem is CHECKPOINT_ERROR serves too many purposes: native descriptor failure, native checkpoint failure, and even native restore failure. I'm fine with this code, but please move this if to translateJVMExceptions with a FIXME comment.

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

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