Snapsafety of core library classes
Anton Kozlov
akozlov at azul.com
Mon May 23 20:11:29 UTC 2022
Hi,
On 5/19/22 15:09, Volker Simonis wrote:
> I wonder if anybody has thought about how snapsafety for the core
> library classes should be implemented in CRaC? By "snapsafety" I mean
> correct and secure operation after restoring a JVM process which was
> previously checkpointed and possibly cloned.
First of all, thanks for the start of the interesting discussion. I just
skimmed through Dan's answer and I will need some time to think properly
about that.
I think "snapsafety" needs a more precise definition. For correctness,
we know problems when a field of a java object to be interpreted as an
external resource id: a pointer packed as long, an fd as int, a String
that is a key in a network DB. Problems arise with the interpretation,
and only if interpretation involves some objects that are outside of the
current java instance. A java object itself (as a data type and
associate methods) is always correct after the restore, since its bit
representation of primitives and object refs are not changed, and
associated methods are the same. Clones of an object do not interfere,
so all of them should be correct.
For the security of the operation, SecureRandom vs Random is a great
example. One is secure and the other is not, and the difference is very
domain-specific, rather some universal predicate for an instance of
j.l.Object.
I assume you are looking some mean for java programmer to ensure some
properties of their programs w.r.t. checkpoint and restore? or regarding
an implementation of java with CRaC, to avoid or report using java
classes that were not changed for CRaC, although they should?
> If we make
> snapsafety an explicit feature, we tell users that the corresponding
> classes will behave correctly on snapshot and restore events.
The fact a class implements the interface does not necessarily imply
something useful. The implementation of the methods can be empty or
buggy. Although JDK classes can ensure something strict, we'd need
some way to check implementation of the interface for user classes.
Thanks,
Anton
More information about the crac-dev
mailing list