Concurrent Memory Loading (CML)
Concurrent Memory Loading (CML) is a feature of the SA version of the Warp engine that allows application code to begin executing during the restore process while some portions of memory are still being loaded. This can significantly reduce the perceived startup time by allowing the application to perform useful work while memory restoration completes in the background.
Enabling Concurrent Memory Loading
You can enable CML with the following JVM option on restore. More options are available, see Warp Engine Options available in Subscriber Availability (SA) Builds.
-XX:CRaCEngineOptions=concurrent=true
What is Concurrent Memory Loading
CML is an umbrella term for all configurations where application code executes while some memory regions have not yet been fully restored. This includes various implementation strategies, such as on-demand loading and other concurrent restoration approaches. The key characteristic is that the application becomes active before the complete memory state has been loaded.
Comparison with Direct Mapping
With the default configuration CRaC does not "read" the data from an image into memory but rather maps parts of the image. The operating system then backs the memory from the image file when this memory is first accessed. While this is not fully transparent, the application usually does not distinguish how the memory was set up, and this "lazy-loading" optimization allows an order of magnitude faster startup.
The Warp engine decides automatically if it can optimize the memory loading as this is not possible in all cases (e.g. when the image content is compressed, when the memory is shared, etc.). Notable cases are the Z Garbage Collector (ZGC) in Zulu and C4 Garbage Collector in Zing. These effectively disable direct mapping on the Java heap. CML implements the "lazy-loading" in userspace, rather than delegating that to the operating system.
Direct mapping can be disabled with -XX:CRaCImageOptions=direct_map=false, see CRaC Command-Line Options and System Properties.
Important Restrictions
When restoring with CML enabled, applications must not perform the following actions in native code:
-
Changing the SIGSEGV Handler: Applications must not replace or override the SIGSEGV signal handler. CML relies on this handler to manage memory access during the restoration process.
NoteThis is typically not a concern for most applications, since the JVM registers its own SIGSEGV handler. If your application needs to install custom signal handlers in native code, they should be registered as chained handlers through libjsigrather than replacing the existing handler. -
Blocking SIGSEGV: Applications must not block the SIGSEGV signal through any of the following mechanisms:
-
Explicit blocking via
pthread_sigmaskorsigprocmask. -
Blocking the signal in mask used when registering the handler for another signal.
-
Consequence: Violating these restrictions will result in undefined behavior, which may manifest as sudden process crashes. Scope: These restrictions apply only to native code included in the application. Pure Java code is not affected by these limitations.
Memory Mapping Operations
Recent improvements to CML have relaxed earlier restrictions around memory mapping operations. The implementation now intercepts calls to libc memory management functions like mmap, mremap, and others.
When these functions are called during the CML restoration process, their execution is automatically delayed until it is safe to proceed. This allows applications and the JVM to remap or unmap memory regions without interfering with the concurrent loading process.
Best Practices
-
Pure Java applications: CML should work transparently without requiring special considerations.
-
Applications with native code: Review any native components that interact with signal handlers or perform signal masking to ensure compliance with the restrictions above.
-
Troubleshooting: If you experience unexpected crashes during restore with CML enabled, verify that native code components are not interfering with SIGSEGV handling.