Polishing

Author: sbrannen

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

@@ -1,34 +1,34 @@
 [[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.
+The Spring Framework integrates with checkpoint/restore as implemented by https://github.com/CRaC/docs[Project CRaC] in order to allow implementing systems capable of reducing 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 (version `1.4.0` and above are supported).
-* Specifying the required `java` command line parameters like `-XX:CRaCCheckpointTo=PATH` or `-XX:CRaCRestoreFrom=PATH`.
+* The presence of the https://github.com/CRaC/org.crac[`org.crac:crac`] library (version `1.4.0` and above are supported) in the classpath.
+* 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.
+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.
+Conceptually, checkpoint and restore align with the xref:core/beans/factory-nature.adoc#beans-factory-lifecycle-processor[Spring `Lifecycle` contract] for individual beans.
 
-== On demand checkpoint/restore of a running application
+== 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.
+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 beans to reopen resources when relevant. For libraries that do not depend on Spring, custom checkpoint/restore 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.context.checkpoint=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 the lifecycle has not started and
+When the `-Dspring.context.checkpoint=onRefresh` JVM system property is set, a checkpoint is created automatically at
+startup during the `LifecycleProcessor.onRefresh` phase. After this phase has completed, all non-lazy initialized singletons have been instantiated, and
+`InitializingBean#afterPropertiesSet` callbacks have been invoked; but the lifecycle has not started, and the 
 `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.
+NOTE: Automatic 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 it does not allow to have a fully warmed-up JVM.

framework-docs/modules/ROOT/pages/integration/class-data-sharing.adoc

@@ -2,7 +2,7 @@
 = Class Data Sharing
 
 Class Data Sharing (CDS) is a https://docs.oracle.com/en/java/javase/17/vm/class-data-sharing.html[JVM feature]
-that can help reduce the startup time and memory footprints of Java applications.
+that can help reduce the startup time and memory footprint of Java applications.
 
 To use this feature, a CDS archive should be created for the particular classpath of the
 application. The Spring Framework provides a hook-point to ease the creation of the
@@ -12,15 +12,16 @@ archive. Once the archive is available, users should opt in to use it via a JVM
 
 A CDS archive for an application can be created when the application exits. The Spring
 Framework provides a mode of operation where the process can exit automatically once the
-`ApplicationContext` has refreshed. In this mode, all non-lazy initialized singletons are
-instantiated, `InitializingBean#afterPropertiesSet` callbacks have been invoked, but the
-lifecycle has not started and `ContextRefreshedEvent` has not been published.
+`ApplicationContext` has refreshed. In this mode, all non-lazy initialized singletons
+have been instantiated, and `InitializingBean#afterPropertiesSet` callbacks have been
+invoked; but the lifecycle has not started, and the `ContextRefreshedEvent` has not yet
+been published.
 
 To create the archive, two additional JVM flags must be specified:
 
 * `-XX:ArchiveClassesAtExit=app-cds.jsa`: creates the CDS archive on exit
-* `-Dspring.context.exit=onRefresh`: starts and then immediately exit your Spring
-  application as described above.
+* `-Dspring.context.exit=onRefresh`: starts and then immediately exits your Spring
+  application as described above
 
 To create a CDS archive, your JDK must have a base image. If you add the flags above to
 your startup script, you may get a warning that looks like this: