JVM Memory Page Locking for Virtual Server Sharing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The conflict between hypervisor memory sharing and Java Virtual Machine (JVM) memory management leads to forced un-sharing of memory areas, particularly when the JVM uses large-pages to optimize performance, resulting in inefficiencies in memory allocation and sharing between virtual servers.
Innovation Solution
A system and method for locking memory areas in a JVM, where the JVM uses a first large page during startup and signals to write-protect it once the application server has completed its initialization, allowing new code to be written into a new page, ensuring the original page remains shareable between virtual servers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Speed
If the JVM uses large-pages to optimize performance during startup, then execution speed is improved, but memory sharing between virtual servers deteriorates due to forced un-sharing when code is re-optimized
Solution Approach 1:
The patent segments the code memory into multiple large pages, allowing the JVM to lock specific pages during startup for performance optimization while leaving other pages unlockable for sharing. This segmentation enables selective locking of only the necessary code portions, preserving memory sharing capability for other areas.
Solution Approach 2:
The patent implements dynamic memory management by allowing the JVM to transition memory pages between locked and unlocked states based on runtime conditions. During startup, pages are locked for performance; after optimization completion, pages can be unlocked to enable sharing, creating a dynamic adaptation to different operational phases.
2Productivity
If the JVM re-optimizes code after startup, then code performance is improved, but memory sharing is lost due to forced un-sharing
Solution Approach 1:
The patent divides code memory into multiple segments or pages, allowing selective locking of only those pages containing actively optimized code. This enables the JVM to perform re-optimization on specific segments without affecting the shareability of other code segments, maintaining memory sharing stability while improving productivity.
Solution Approach 2:
The patent applies different memory management qualities to different regions of code memory. Hot code paths that require frequent optimization are locked for high productivity, while cold code paths or already-optimized sections remain unlocked for sharing, creating local quality differentiation that resolves the contradiction.
3Stability of the object's composition
If the JVM locks memory pages to prevent modification, then memory integrity is improved, but memory flexibility deteriorates due to inability to allocate new code
Solution Approach 1:
The patent segments memory into locked and unlocked regions, allowing the JVM to maintain integrity of locked pages while preserving flexibility in unlocked pages for new code allocation. This segmentation enables simultaneous existence of stable and flexible memory regions within the same address space.
Solution Approach 2:
The patent introduces an additional dimension to memory management by implementing a multi-page structure with different lock states. Instead of a single monolithic memory block, the system uses multiple pages that can independently transition between locked and unlocked states, adding dimensional complexity that resolves the binary contradiction between integrity and flexibility.
Data Source
AI summary
A system and method for locking memory areas in a Java Virtual Machines (JVM) to facilitate sharing between virtual servers. In accordance with an embodiment, the system comprises a computing/virtual execution environment, which includes one or more physical computers, computer systems, server computers, or similar computing devices, a hypervisor, and a virtual machine or JVM. The JVM allows one or more application images to be run on the computer, wherein the application images can include application server instances. The application server uses a first large page in memory during its startup process, and is configured so that it signals to the JVM when the application server has completed its startup and has potentially pre-optimized important code. When the JVM receives this signal, it internally write-protects or locks the page used for application server code memory, so that any new JITed code or re-optimized code is subsequently written into a new large page. The original page will therefore be undisturbed and will always be shareable between the virtual servers running within the hypervisor.