Shared Code Cache for JVM Memory Efficiency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In Java implementations, multiple JVM instances do not share physical memory, leading to redundant storage of common compiled methods, which wastes memory, especially in devices with limited physical memory like personal digital assistants and cellular phones.
Innovation Solution
A mechanism where common components are compiled and stored in a mappable data structure, allowing subsequent JVM instances to map their virtual memory space to this shared physical memory location, eliminating the need for recompilation and reducing memory usage.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If each JVM instance manages its own code cache independently, then each JVM can execute methods efficiently, but physical memory is wasted due to redundant storage of common compiled methods
Solution Approach 1:
The patent merges the code cache functionality across multiple JVM instances by introducing a shared code cache structure. Instead of each JVM maintaining its own independent code cache, the system combines them into a single shared code cache that all JVM instances can access. This eliminates redundant storage of common compiled methods while preserving the ability of each JVM to execute methods efficiently through the shared resource.
Solution Approach 2:
The shared code cache structure serves multiple functions simultaneously: it stores compiled methods for multiple different JVM instances, provides memory efficiency by eliminating redundancy, and maintains compatibility with the Java virtual machine architecture. This universal structure allows any JVM instance to access the code cache without requiring separate private caches for each instance.
2Quantity of substance
If cloning is used to enable JVM instances to share physical memory, then memory sharing is achieved, but the system becomes dependent on specific operating systems and incurs significant compilation time
Solution Approach 1:
The patent introduces a shared code cache structure as an intermediary mechanism that enables memory sharing without relying on operating system-specific cloning operations. This intermediary structure acts as a universal bridge that allows different JVM instances to share physical memory through a common data structure rather than through OS-level fork operations, thereby achieving cross-platform compatibility.
Solution Approach 2:
Instead of using OS-level cloning to create JVM instances that share memory, the patent employs a different copying approach where JVM instances are created independently but all instances map to a shared code cache structure. This allows the system to avoid the operating system dependency inherent in cloning while still achieving the desired memory sharing behavior through virtual memory mapping.
3Quantity of substance
If cloning is used to share physical memory among JVM instances, then memory redundancy is reduced, but compilation time increases significantly for the master JVM
Solution Approach 1:
The patent implements preliminary action by pre-compiling common methods and storing them in the shared code cache structure before JVM instances are fully initialized. This allows the master JVM to compile common methods once and make them available to subsequent JVM instances without requiring each instance to perform the full compilation process, thereby reducing overall compilation time while maintaining memory efficiency.
Solution Approach 2:
The patent applies partial action by having the master JVM compile only the common methods that will be shared across all JVM instances, rather than compiling everything for each individual JVM. This selective compilation approach reduces the total compilation workload and time while still providing comprehensive method coverage through the shared code cache structure.
Data Source
AI summary
A mechanism is disclosed for enabling multiple processes to share the same portion of physical memory. The first time an instance of a process is executed, a list of common components is compiled. The compiled code is then written into a newly created mappable data structure, which is stored into persistent storage. The next time an instance of that process is executed, the mappable data structure is mapped into a portion of the process instance's virtual memory space. This enables the process instance to invoke the compiled code for the common components. Multiple instances of the process may have their virtual memory spaces mapped to the same mappable data structure in this way. Thereafter, it is up to the operating system to load the contents of the mappable data structure into a portion of physical memory, and to ensure that all of the process instances share that physical memory portion.