On-demand Dynamic Script Code Loading for Memory Reduction
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Dynamic scripting languages typically consume more memory due to the inclusion of unnecessary code and debugging information, which can lead to memory overflow issues in embedded systems, and existing solutions like code restructuring or stripping debug information are labor-intensive, complex, or impractical.
Innovation Solution
An on-demand loading system that uses a code loader and an on-demand loader to remove categories of program code and debug information, replacing placeholders with full code or debug information only when needed, utilizing a compiled tree structure to reduce memory usage without requiring additional precompilation steps.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If all debugging information is stored in compiled bytecode by default, then debugging capability is improved, but memory usage increases significantly
Solution Approach 1:
The patent extracts debugging information from the compiled bytecode and stores it separately in the source code files. When debugging is needed, the information is loaded on-demand from the original source files rather than being permanently embedded in the bytecode, thereby reducing the memory footprint of the compiled application while preserving full debugging capability.
Solution Approach 2:
The patent performs preliminary compilation of source code to bytecode, stripping out debugging information during the compilation process. The source code files are preserved separately on disk, allowing debugging information to be retrieved later without having been embedded in the bytecode, thus preparing the system for low-memory operation while maintaining debugging potential.
2Quantity of substance
If debug information is stripped from bytecode using precompilation, then memory usage is reduced, but runtime error reporting capability is lost
Solution Approach 1:
The compilation process preliminarily processes source code into bytecode, removing debugging information from the bytecode output. However, the original source code files are preserved on the file system, enabling on-demand retrieval of debugging information when runtime errors occur, thus maintaining error reporting capability without increasing bytecode memory usage.
Solution Approach 2:
The patent introduces an intermediary mechanism (the source code file system) that bridges the gap between stripped bytecode and debugging information needs. When runtime errors occur, the system mediates by loading debugging information from the original source files rather than having it embedded in the bytecode, thus restoring error reporting capability without permanent memory overhead.
3Quantity of substance
If source code is stored instead of precompiled bytecode, then memory usage is reduced in compressed form, but execution speed decreases
Solution Approach 1:
The patent segments the application into two forms: compressed source code for storage and compiled bytecode for execution. The system uses bytecode when available for fast execution, and only falls back to interpreting compressed source code when necessary, thus achieving both memory efficiency and execution speed through segmented resource usage.
Solution Approach 2:
The patent changes the parameter of code representation from uncompressed source code to compressed source code, reducing the memory footprint significantly. The compression algorithm transforms the code into a compact format that can be stored efficiently while still being interpretable, thus improving memory usage without completely sacrificing execution capability.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A computer-implemented method and system for reducing the amount of memory space required to store applications written in dynamic scripting languages loads a program module into memory and removes a category of program code, such as debug information or function definitions, from the program module. The method and system also receives a request for debug information, or a function call or query, and determines whether or not the corresponding program code is in memory. If not, then the location in storage is identified where the program module is stored, and another copy containing the corresponding program code is loaded into memory. The corresponding program code is located and copied into the program module in memory, and a response is provided to the request.