Dynamic Class Preloading in Virtual Machines
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional classloading methods in virtual machine environments, such as Java Virtual Machine (JVM), are slow due to the need to look up and read class files, create VM internal data structures, and perform constant pool resolution each time a class is loaded, which negatively impacts performance, especially on resource-constrained systems like embedded or mobile devices.
Innovation Solution
A dynamic class preloading method that preloads classes from class file containers into memory, creating runtime data structures without full linking and resolution, and stores them in persistent modules, allowing for faster loading by completing linking and resolution only when requested, and using pre-generated persistent modules if available.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If classes are loaded conventionally (on-demand with full linking and resolution), then security checks and format verification are performed, but class loading time is excessive and performance is degraded
Solution Approach 1:
The patent applies preliminary action by performing class file reading, format verification, and security checks in advance during application startup, before the classes are actually needed for execution. This allows the heavy validation work to be completed beforehand, so that when classes are loaded on-demand, the time-consuming verification steps have already been performed, thus reducing class loading time while maintaining security and reliability
Solution Approach 2:
The patent segments the class loading process into distinct phases: (1) preliminary phase where class files are scanned and verified during startup, (2) persistent storage phase where verified class data is saved to persistent modules, and (3) on-demand loading phase where pre-verified class data is quickly loaded and linked. This segmentation allows different parts of the process to be optimized independently, improving overall performance
2Use of energy by moving object
If constant pool resolution is performed lazily (on first reference), then memory usage is optimized, but resolution speed becomes a bottleneck during class execution
Solution Approach 1:
The patent applies preliminary action by performing constant pool resolution in advance during the preliminary class verification phase, before the class is executed. All constant pool entries are resolved and validated beforehand, so that during actual class execution, the constant pool is already prepared and ready for rapid access, eliminating the bottleneck of on-demand resolution while maintaining memory efficiency
3Speed
If classes are preloaded completely (with full linking and resolution), then class loading speed is improved, but memory consumption increases significantly
Solution Approach 1:
The patent applies partial action by performing only the necessary preliminary steps (reading class files, format verification, security checks, and constant pool resolution) without completing the full linking and resolution process during preloading. The linking and resolution are completed partially during startup verification and then finalized on-demand when classes are actually loaded for execution. This approach improves loading speed while avoiding the excessive memory consumption that would result from complete preloading of all classes with full linking
4Adaptability or versatility
If class files are read from class file containers (JAR files) during execution, then flexibility is maintained, but I/O operations become a performance bottleneck on resource-constrained systems
Solution Approach 1:
The patent applies preliminary action by reading and verifying class files from class file containers during application startup, before execution begins. The class data is validated, formatted, and prepared in advance, then stored in persistent modules. During actual execution, classes are loaded from these persistent modules rather than being read from the original class file containers, thus maintaining flexibility while eliminating the I/O bottleneck that would occur if all class files were read during execution
Data Source
AI summary
A class preloading mechanism that dynamically preloads classes at runtime in a virtual machine (VM) environment. Data structures representing preloaded classes may be stored in a persistent module corresponding to a classloader. A persistent module can be directly mapped or copied into a memory region at runtime so that the classes may not have to be loaded from the class file container. The preloaded classes are not fully linked and resolved. When a classloader receives a class request, the classloader looks up the preloaded class in the memory region and completes linking and resolution of the class. Persistent modules may be pre-generated and, for example, installed with an application. Alternatively, a persistent module for a class file container may be generated at runtime by preloading classes from the class file container into a memory region and storing data structures representing the classes as a persistent module.