Why Don't Document Apps Just Memory-Map Their Files Back Into RAM?
A developer who built a commercial Java-based office suite in 2000 posed a question on Hacker News that cuts to the heart of how applications handle large documents. The traditional approach, parsing files like DOCX and reconstructing pointer structures in memory, is slow and wasteful. The alternative, memory-mapping the file and letting the operating system restore RAM pages from disk, should be fast. But it does not work the way you would expect, especially on the JVM.
The developer's company stored data objects in a 3D coordinate space indexed by sheet number, row number, and column number rather than using in-memory pointers. This design let them open a 50,000-page document in 8 seconds. A competing suite that parsed the same file and built an array of pointers took over 300 seconds. The 3D approach avoided the parsing bottleneck entirely by referencing data by position rather than by memory address.
The Memory-Mapping Proposal
The idea that prompted the question is straightforward. After an operating system swaps active RAM pages out to flash storage as virtual memory, it can restore them almost instantly when the process accesses them again. If a document application dumped its entire in-memory representation to disk and then mmap'd that file, the OS could page the data back in as needed. No parsing, no pointer reconstruction, just a fast restore of the previous memory state.
The tradeoff is space. Using twice the flash disk space compared to a compact file format might be acceptable if it achieves millisecond load times for complex documents. The question is whether this is technically feasible, particularly on the JVM.
Where the JVM Gets in the Way
The developer's senior engineers confirmed the concept is feasible in principle. They attempted to prove it using OpenJDK and CRaC (Coordinated Restore at Checkpoint) on Linux. CRaC is an OpenJDK feature designed for checkpoint and restore of Java application states, which is exactly what this use case requires: dump the heap to disk and restore it later.
The engineers ran into numerous problems. The developer reported that OpenJDK stated the feature can be done but probably was not tested thoroughly because the maintainers never expected it to be used this way. The JVM's garbage collector, object layout, and heap management make it difficult to decouple a complex document substrate into off-heap memory in a way that survives a checkpoint and restore cycle cleanly.
This is not a new problem. The JVM has always struggled with memory-mapped data because the garbage collector does not understand off-heap memory. It cannot track references into mmap'd regions, cannot compact them, and cannot guarantee they remain valid across a restore. CRaC adds another layer of complexity because it must serialize the entire heap state, including native memory mappings, in a way that the JVM can reconstruct faithfully.
The Broader Question About Zero-Copy Loading
The Hacker News post asks whether anyone has successfully decoupled a complex document model into off-heap memory for true zero-copy mmap load, or whether the JVM always gets in the way. The answer, based on the discussion, is that the JVM remains a significant obstacle. Off-heap memory in Java is possible through DirectByteBuffer or Unsafe.allocateMemory, but managing it requires careful manual lifecycle control. The garbage collector does not help, and checkpoint/restore tools like CRaC do not handle native memory mappings reliably.
Outside the JVM, the picture is different. C and C++ applications can mmap files directly and let the OS handle paging with minimal runtime interference. The operating system's virtual memory subsystem is designed for exactly this use case. The problem is specific to managed runtimes where the runtime's own memory management conflicts with the OS's paging strategy.
Why Document Apps Still Parse Files
The practical reality is that most document applications parse files because it is the only approach that works reliably across platforms and runtimes. DOCX files are ZIP archives containing XML. Parsing them means extracting the XML, building a DOM or SAX representation, and constructing an object model in memory. This is slow for large documents, but it is predictable and portable.
Memory-mapping a pre-built memory image would be faster, but it creates platform dependencies. A memory dump from a 64-bit Linux JVM is not portable to a 32-bit Windows JVM. The object layout changes between JVM versions. The garbage collector's behavior changes between runs. These dependencies make the approach impractical for commercial software that must work across environments.
The 3D coordinate space approach sidesteps the problem by avoiding pointers entirely. By referencing data by position rather than by memory address, the application can reconstruct the document model from the file without building an in-memory pointer graph. This is slower than mmap but faster than traditional parsing, and it works on any platform with a JVM.
What Would Need to Change
For memory-mapped document loading to work on the JVM, the runtime would need to support stable off-heap memory regions that survive checkpoint and restore cycles. The garbage collector would need to understand these regions and avoid moving or collecting them. CRaC would need to handle native memory mappings as first-class state that can be serialized and restored faithfully.
None of these capabilities exist in current OpenJDK releases. The CRaC project is still experimental, and its focus is on container startup time reduction rather than document persistence. A purpose-built solution would likely require changes to the JVM itself, which is a multi-year effort with no guarantee of acceptance.
The developer's question remains open. The 3D coordinate space approach works. Memory-mapping a document image does not work on the JVM in any practical sense today. The gap between what the OS can do with virtual memory and what the JVM lets applications do with it remains wide, and closing it would require fundamental changes to how Java manages memory.