Introduce JVM checkpoint/restore support documentation

Closes spring-projectsgh-30647

framework-docs/modules/ROOT/nav.adoc

@@ -415,6 +415,7 @@
 *** xref:integration/cache/plug.adoc[]
 *** xref:integration/cache/specific-config.adoc[]
 ** xref:integration/observability.adoc[]
+** xref:integration/checkpoint-restore.adoc[]
 ** xref:integration/appendix.adoc[]
 * xref:languages.adoc[]
 ** xref:languages/kotlin.adoc[]

framework-docs/modules/ROOT/pages/integration/checkpoint-restore.adoc

@@ -0,0 +1,31 @@
+[[checkpoint-restore]]
+= JVM Checkpoint Restore
+
+The Spring Framework integrates with checkpoint/restore as implemented by https://github.com/CRaC/docs[Project CRaC] in order to allow implementing systems capable to reduce the startup and warmup times of Spring-based Java applications with the JVM.
+
+Using this feature requires:
+
+* A checkpoint/restore enabled JVM (Linux only for now).
+* The presence in the classpath of the https://github.com/CRaC/org.crac[`org.crac:crac`] library.
+* Specifying the required `java` command line parameters like `-XX:CRaCCheckpointTo=PATH` or `-XX:CRaCRestoreFrom=PATH`.
+
+WARNING: The files generated in the path specified by `-XX:CRaCCheckpointTo=PATH` when a checkpoint is requested contain a representation of the memory of the running JVM, which may contain secrets and other sensitive data. Using this feature should be done with the assumption that any value "seen" by the JVM, such as configuration properties coming from the environment, will be stored in those CRaC files. As a consequence, the security implications of where and how those files are generated, stored and accessed should be carefully assessed.
+
+Conceptually, checkpoint and restore match with xref:core/beans/factory-nature.adoc#beans-factory-lifecycle-processor[Spring `Lifecycle` contract] for individual beans.
+
+== On demand checkpoint/restore of a running application
+
+A checkpoint can be created on demand, for example using a command like `jcmd application.jar JDK.checkpoint`. Before the creation of the checkpoint, Spring Framework
+stops all the running beans, giving them a chance to close resources if needed by implementing `Lifecycle.stop`. After restore, the same beans are restarted, with `Lifecycle.start` allowing to reopen resources when relevant. For libraries not depending on Spring, checkpoint/restore custom integration can be provided by implementing `org.crac.Resource` and registering the related instance.
+
+WARNING: Leveraging checkpoint/restore of a running application typically requires additional lifecycle management to gracefully stop and start using resources like files or sockets and stop active threads.
+
+NOTE: If the checkpoint is created on a warmed-up JVM, the restored JVM will be equally warmed-up, allowing potentially peak performance immediately. This method typically requires access to remote services, and thus requires some level of platform integration.
+
+== Automatic checkpoint/restore at startup
+
+When the `-Dspring.checkpoint.restore=onRefresh` Java system property is set, a checkpoint is created automatically during the startup at `LifecycleProcessor.onRefresh` level. At this phase, all non-lazy initialized singletons are instantiated, `InitializingBean.afterPropertiesSet` callbacks have been invoked, but not `Lifecycle.start` ones and `ContextRefreshedEvent` has not yet been published.
+
+WARNING: As mentioned above, and especially in use cases where the CRaC files are shipped as part of a deployable artifact (a container image for example), operate with the assumption that any sensitive data "seen" by the JVM ends up in the CRaC files, and assess carefully the related security implications.
+
+NOTE: Here checkpoint/restore is a way to "fast-forward" the startup of the application to a phase where the application context is about to start, but does not allow to have a fully warmed-up JVM.