Binary translation cache replacement method based on multi-dimensional priority score

Abstract

The invention provides a binary translation cache replacement method and system based on multi-dimensional priority scoring. The method comprises the following steps: statically analyzing a program to be executed to generate a control flow graph (CFG); running the program and loading the code block; judging whether the cache space is enough or not; if yes, loading the code block to a cache; if not, calculating a cache code block RVS; and selecting the code block with the lowest RVS for replacement. According to the method, the problem that a cache replacement strategy usually adopts a single-dimension decision mode is solved; the technical problems of low cache hit rate and long compiling time consumption caused by the phenomena that high-translation-cost codes are frequently replaced, inactive large-block codes occupy cache for a long time, code blocks irrelevant to a current execution path reside, and hot spots cannot be recognized and quickly switched in an instant compiling scene are solved.

Description

Technical Field

[0001] The present invention relates to the field of binary translation cache, and in particular to a binary translation cache replacement method and system based on multi-dimensional priority scoring. Background Art

[0002] With the rapid development of open-source instruction set architectures like RISC-V, instruction set simulators (ISS) and dynamic binary translation (DBT) systems have been widely used in areas such as software debugging, cross-platform compatibility support, virtualization, and embedded system development. To improve simulator execution efficiency, Just-in-Time Compilation (JIT) technology has been widely introduced. This technology dynamically translates target platform instructions into native machine code executable by the host platform during program runtime, effectively reducing the performance bottleneck of interpreted execution.

[0003] However, due to the large amount of native machine code generated during the JIT process and the limited memory resources of the host system, efficient translation cache management strategies have become a key factor affecting the performance of JIT systems. Proper cache management not only improves cache hit rates and reduces recompilation overhead, but also directly affects the overall system speed and resource utilization.

[0004] Therefore, research on more intelligent and dynamically adaptive cache replacement strategies has become an important direction for improving the performance of instruction set simulators and dynamic binary translation systems. Currently, in just-in-time compilation systems, the mainstream cache management strategies mainly include the following:

[0005] 1. LRU (Least Recently Used)

[0006] The basic principle is to record the last access time of each code block; when cache space is insufficient, the code blocks that have not been accessed for the longest time are prioritized for eviction. However, there are problems: LRU relies solely on time information and does not consider the code block's translation overhead, memory usage, or its relationship to the current execution path. In programs with frequent hotspot switching, this can easily lead to the erroneous eviction of critical code blocks with high translation costs.

[0007] 2. LFU (Least Frequently Used)

[0008] The basic principle is to count the cumulative number of times each code block is accessed; when the cache is full, the code block with the least number of accesses is eliminated. Problems exist: LFU focuses on the historical total access frequency and lacks dynamic awareness of current activity. When the program execution phase changes, code blocks with historical high frequency but currently low usage may continue to occupy the cache for a long time, making it difficult to load new hot code in a timely manner, reducing the hit rate.

[0009] 3. FIFO (First In First Out)

[0010] The basic principle is to sort code blocks into the cache in the order they entered; when space needs to be freed up, the first code block to enter the cache is always eliminated. However, the problem is that FIFO completely ignores the access frequency, execution popularity, translation cost, or call chain relationships of code blocks. This can prematurely eliminate frequently executed and important code blocks, severely degrading performance.

[0011] 4. Flush (full clear strategy)

[0012] The basic principle is that when cache space is insufficient, all cached code blocks are cleared at once, regardless of priority. Problems include: indiscriminately clearing all translation results, forcing the system to retranslate large amounts of code; and triggering large-scale just-in-time compilation during cache refilling, resulting in significant performance degradation and response delays.

[0013] The existing invention patent application document, "A Translation Cache Management Method Based on Code Heat in Dynamic Binary Translation," with publication number CN105843664A, includes the following steps: dividing the entire translation cache into two levels of cache; when a new basic block needs to be translated, searching for the code block in the hot code cache based on the address of the basic block; searching for the code block in the sub-code cache based on the address of the basic block; calculating the space required to cache the code block; clearing the sub-code cache; translating the basic block and storing the translated code block in the sub-code cache; executing the code block; counting the number of executions of the code block, and if the number of executions exceeds a threshold, caching the code block in the hot code cache; adding the basic block to a slow hash table and the result to a fast hash table. While this existing solution achieves basic execution heat optimization through a hierarchical cache management strategy for hot code and normal code, the existing replacement strategy is relatively simple, relying solely on the number of executions of a code block to determine whether it is "hot." This can easily lead to the incorrect replacement of critical code blocks in complex programs or resource-constrained environments, resulting in a decrease in cache hit rate and an increase in repeated compilation overhead.

[0014] In summary, the cache replacement strategy in the existing technology usually adopts a single-dimensional decision-making approach, which leads to technical problems such as low cache hit rate and long compilation time caused by the frequent replacement of high-translation cost code in the just-in-time compilation scenario, long-term occupation of cache by large blocks of inactive code, residence of code blocks unrelated to the current execution path, and inability to identify fast switching of hot spots. Summary of the Invention

[0015] The technical problem to be solved by the present invention is: how to solve the technical problems of low cache hit rate and long compilation time caused by the cache replacement strategy in the existing technology, which usually adopts a single-dimensional decision-making method, resulting in high translation cost code being frequently replaced, inactive large blocks of code occupying the cache for a long time, code blocks irrelevant to the current execution path residing, and inability to identify fast switching of hot spots in the just-in-time compilation scenario.

[0016] The present invention solves the above technical problems by adopting the following technical solutions: a binary translation cache replacement method based on multi-dimensional priority scoring includes:

[0017] S1. Before the target program is loaded and prepared for execution in the instruction set simulator, a static analysis of the program is performed. Disassembly or symbolic parsing techniques are used to extract the relationships between basic blocks, jump instructions, and function calls in the program, and a complete control flow graph (CFG) is constructed. This graph depicts the control paths between instructions in the program, providing basic data support for subsequent evaluation of runtime dependencies between code blocks.

[0018] S2. During the just-in-time compilation process, the time it takes for each code block to be translated and generated into executable machine code is recorded as the translation cost indicator of the code block.

[0019] S3. For each translated code block, calculate the actual cache space it occupies. This space includes the translated machine code segment and read-only data segment, comprehensively reflecting the cache resource usage of the code block and serving as an important metric for measuring storage costs in cache management.

[0020] S4. During program execution, the number of visits to each code block is counted in real time, and a time decay function is introduced to process historical visits to form a "heat value" that reflects the current activity of the code block.

[0021] S5. Based on the pre-built control flow graph and the current program counter position, determine the control flow distance between the code block to be replaced and the current execution path. Quantify the call chain relevance by calculating the jump depth or path distance between the current code block and the candidate code block.

[0022] S6. A weighted scoring model is used to calculate the retention value score (RVS) of a code block, taking into account its popularity, translation cost, cache usage cost, and relevance to the current execution path. When cache space is insufficient, the code block with the lowest score is replaced first. This maximizes cache hit rates and reduces recompilation overhead while ensuring execution efficiency, thus optimizing the performance of the just-in-time compilation system in resource-constrained environments.

[0023] In a more specific technical solution, step S1 first parses the code segment of the program to be executed before the instruction set simulator starts executing the program to generate a control flow graph of the program. The method parses the instructions in the code area by disassembly to identify jump and branch behaviors, and divides the basic blocks according to the jump boundaries. The starting address of each basic block is determined by the end address of the previous block. When constructing the control flow graph, the method maps the jump target address of each basic block to the corresponding basic block number, thereby forming a clearly structured control map. Finally, in the generated basic block structure, each block contains its start and end addresses, instruction sequence, and jump target number set, forming a static execution path relationship, which provides a basis for subsequent correlation evaluation.

[0024] In a more specific technical solution, in step S2, the method accurately evaluates the translation cost during the JIT compilation process. Whenever the compilation of the intermediate code starts, the current timestamp is recorded, and the time consumption is calculated at the end of the translation, which is used as the compilation cost of the current code block. If the current code block does not contain relocation information, its translation time consumption is directly calculated and stored in the cache, and the code segment address is returned; if there is relocation information, the method parses the relocation table and the symbol table after the translation is completed, adjusts the address reference in the code segment, ensures that the runtime data access is correct, and then calculates and records the final translation time consumption again. In order to improve the stability and real-time performance of cost statistics, the present invention introduces a smoothing factor, performs exponential weighted averaging on the JIT compilation time, and avoids misleading the score due to instantaneous fluctuations. The calculation method is shown in the formula.

[0025] C=α×C B +(1-α)×C pre

[0026] C B For the JIT compilation time of a code block, C pre is the last compilation time, and α controls the influence of new and old data.

[0027] In a more specific technical solution, in step S3, the method evaluates the actual cache space occupied by a code block. After JIT compilation is complete, the method extracts the relocation table and symbol table from the ELF file and executes address correction logic to correct references in the code segment and read-only data segment to ensure that all instructions can correctly access their required data. Based on this, the method calculates the overall size of the code block—the sum of the code segment size and the read-only data segment size—to measure the cache resource usage of the code block. The specific calculation method is shown in the formula.

[0028] S=S text +S rodata

[0029] S text is the code segment size, S rodata The data segment size.

[0030] In a more specific technical solution, in step S4, in order to accurately model the activity level of the code block, the method counts the number of accesses in real time when the code block is executed, and dynamically weights the access frequency in combination with the time decay mechanism. The present invention uses an exponential decay model to calculate the heat value of the code block, and its calculation method reflects the product relationship between the access frequency and the time factor. This model ensures that the code blocks that have been frequently accessed recently have higher heat, while historical hot spots gradually cool down due to lack of continuous access, thereby achieving effective distinction between current hot spots and historical hot spots, ensuring that the code blocks with the highest execution activity are always retained in the cache. The specific calculation method is shown in the formula.

[0031]

[0032] access_count represents the cumulative number of accesses to the code block, t current is the current timestamp, t last_access is the timestamp of the last access to the code block, and λ is the time decay coefficient.

[0033] In a more specific technical solution, in step S5, the method analyzes the contextual relevance between the candidate replacement code block and the current execution path based on the control flow graph constructed in S1. Specifically, the method calculates the call chain weight of the two based on the shortest distance between the basic block where the current PC is located and the target code block. The call chain weight is used to measure the potential importance of the code block on the current path. The shorter the path distance, the higher the possibility of it being executed again in the short term, and the larger the weight value. The calculation method of the call chain weight is shown in the formula, which ensures that the cache replacement decision is context-aware and avoids the mistaken deletion of critical code blocks that will be accessed in the short term.

[0034]

[0035] D(B current ,B target ) indicates the code block B where the current PC is located current , and candidate replacement code block B target The distance between them in the control flow graph.

[0036] In a more specific technical solution, in step S6, the method finally quantifies and integrates the parameters of the above-mentioned multiple dimensions to form a retention value score for the code block. The scoring model comprehensively considers factors such as popularity, translation cost, cache occupancy and call chain weight, and assigns adjustable weight coefficients to each parameter to adapt to the performance requirements of different operating scenarios. The scoring calculation formula is shown in the formula. When the cache space is insufficient, the method will traverse all code blocks in the cache, calculate their RVS values, and select the code block with the lowest score as the replacement candidate. During the replacement process, the method releases the cache space occupied by the candidate code block and merges adjacent free blocks when necessary to optimize space utilization. The new code block is written to the free cache area, and its metadata information is updated to complete the replacement process.

[0037] RVS=W1×H+W2×C-W3×S+W4×CW

[0038] W1, W2, W3, and W4 represent the weight parameters of each indicator.

[0039] In a more specific technical solution, the binary translation cache replacement system based on multi-dimensional priority scoring includes:

[0040] The control flow graph construction module is used to perform static analysis on the target program before the instruction set simulator loads and prepares to execute the target program. It uses disassembly and symbol parsing technology to extract the basic blocks, jump instructions, and function call relationships in the target program to construct the control flow graph (CFG).

[0041] A translation cost processing module is used to record the time from the start of translation to the generation of executable machine code for each code block during the just-in-time compilation process as the translation cost of the code block;

[0042] The cache occupancy cost processing module is used to calculate the actual space occupied by each translated code block in the cache and obtain the cache occupancy cost;

[0043] The heat value determination module is used to count the number of visits to each code block in real time during program execution, introduce a time decay function to process historical access information, and obtain the heat value of the code block;

[0044] The relevance determination module is used to determine the control flow distance between the code block to be replaced and the current execution path based on the control flow graph (CFG) and the current program counter position. The relevance determination module quantifies the call chain relevance of the code blocks by calculating the jump depth and path distance between the current code block and the candidate code blocks. The relevance determination module is connected to the control flow graph construction module.

[0045] The translation cache replacement module is used to comprehensively process the heat value, translation cost, cache occupancy cost and correlation with the current execution path of the code block, and uses a weighted scoring model to calculate the retention value RVS of the code block; when the cache space is insufficient, the code block with the lowest score is replaced first. The translation cache replacement module is connected to the translation cost processing module, cache occupancy cost processing module, heat value determination module and correlation determination module.

[0046] Compared with the prior art, the present invention has the following advantages:

[0047] 1. Multi-dimensional comprehensive decision-making to improve replacement accuracy. Compared with existing cache replacement strategies based only on access frequency or execution count, this invention introduces multiple key dimensions such as code block popularity, translation cost, cache occupancy size, and call chain context to build a dynamic priority scoring system, making cache replacement more accurate and avoiding the problem of high-value code blocks being accidentally deleted;

[0048] 2. Introducing a time decay mechanism to better identify execution hotspots. This invention uses an exponential decay model to dynamically calculate the heat of code blocks, which can reflect the current execution activity of code blocks in real time, thereby quickly responding to changes in hotspot areas during program execution. This overcomes the problem of traditional LRU and other strategies being insensitive to hotspot switching and significantly improves cache hit rates.

[0049] 3. Support context-aware cache management. By constructing a control flow graph and calculating call chain weights, the present invention can quantify the correlation between code blocks and the current execution path, prioritize code blocks with strong path correlation, and improve the runtime adaptability of cache content, thereby enhancing the execution efficiency and stability of the overall system.

[0050] 4. Strong adaptability, applicable to a variety of test programs. The scoring model in this invention allows for flexible adjustment of the weights of each dimension and can be optimized based on the resource status of the target system and program behavior characteristics;

[0051] 5. Reduce repeated translations and lower runtime overhead. Since the present invention effectively avoids the frequent replacement of high-translation-cost code blocks, it significantly reduces the number of repeated compilations during JIT runtime, thereby reducing CPU load and memory usage. It is particularly suitable for just-in-time compilation scenarios in resource-constrained environments.

[0052] 6. Significant overall performance improvement, proven to be effective. Through field measurements and comparisons, the cache management method of the present invention demonstrates superior compilation latency, cache hit rate, and execution performance compared to traditional strategies in multiple benchmark tests, verifying its technical effectiveness and practical value in real-world applications.

[0053] The present invention solves the technical problems of low cache hit rate and long compilation time caused by the cache replacement strategy in the prior art, which usually adopts a single-dimensional decision-making approach, resulting in high translation cost code being frequently replaced in the just-in-time compilation scenario, inactive large blocks of code occupying the cache for a long time, code blocks unrelated to the current execution path residing, and the inability to identify fast switching of hot spots. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 This is a schematic diagram of the basic steps of a binary translation cache replacement method based on multi-dimensional priority scoring according to embodiment 1 of the present invention;

[0055] Figure 2 This is a schematic diagram of binary translation cache replacement data flow processing based on multi-dimensional priority scoring according to embodiment 1 of the present invention;

[0056] Figure 3 This is a schematic diagram of the code block compilation time distribution of Example 1 of the present invention;

[0057] Figure 4 This is a flame graph of the nbench benchmark test program according to Example 1 of the present invention;

[0058] Figure 5 The local control flow graph of the nbench benchmark test program according to embodiment 1 of the present invention;

[0059] Figure 6 This is a schematic diagram of specific implementation steps of the binary translation cache replacement method based on multi-dimensional priority scoring according to Example 1 of the present invention in this embodiment;

[0060] Figure 7 This is a schematic diagram of the compilation time ratio between RVS and other strategies under the Numeric Sort test of Example 2 of the present invention;

[0061] Figure 8 This is a schematic diagram of the compilation time ratio of RVS and other strategies in the String Sort test of Example 2 of the present invention;

[0062] Figure 9 This is a schematic diagram of the compilation time ratio of RVS and other strategies under the Bitfield test in Example 2 of the present invention;

[0063] Figure 10This is a schematic diagram of the compilation time ratio between RVS and other strategies under the FP EMULATION test in Example 2 of the present invention;

[0064] Figure 11 This is a schematic diagram of the compilation time ratio between RVS and other strategies under the Huffman Compression test in Example 2 of the present invention;

[0065] Figure 12 This is a schematic diagram of cache miss rates for different cache management strategies under the Numeric Sort test of Example 2 of the present invention;

[0066] Figure 13 This is a schematic diagram of cache miss rates for different cache management strategies under the String Sort test of Example 2 of the present invention;

[0067] Figure 14 This is a schematic diagram of cache miss rates for different cache management strategies under the Bitfield test of Example 2 of the present invention;

[0068] Figure 15 This is a schematic diagram of cache miss rates for different cache management strategies under the Bitfield test of Example 2 of the present invention;

[0069] Figure 16 Schematic diagram of cache miss rates of different cache management strategies under the FP EMULATION test of Example 2 of the present invention;

[0070] Figure 17 This is a schematic diagram of the relative change rate of RVS performance of each strategy under the Numeric Sort test of Example 2 of the present invention;

[0071] Figure 18 This is a schematic diagram of the relative change rate of RVS performance of each strategy under the String Sort test of Example 2 of the present invention;

[0072] Figure 19 This is a schematic diagram of the relative change rate of RVS performance for each strategy under the Bitfield test of Example 2 of the present invention;

[0073] Figure 20 Schematic diagram of the relative change rate of RVS performance of each strategy under the FP EMULATION test of Example 2 of the present invention;

[0074] Figure 21 Schematic diagram of the relative change rate of RVS performance of each strategy under the Huffman Compression test of Example 2 of the present invention. DETAILED DESCRIPTION

[0075] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0076] Example 1

[0077] The binary translation cache replacement method based on multi-dimensional priority scoring provided by the present invention has been implemented in the open source RISC-V instruction set simulator Rvemu. The steps are as follows: Figure 1 As shown, the data flow is as follows Figure 2 As shown, the method includes the following steps:

[0078] S1. Before the instruction set simulator loads the target program and prepares to execute it, the system performs static analysis on the program's code segments to build a complete control flow graph.

[0079] In this embodiment, before the instruction set simulator starts to execute the program, the code segment of the program to be executed is first parsed to generate a control flow graph for the program. The method parses the instructions in the code area by disassembly to identify jump and branch behaviors, and divides the basic blocks according to the jump boundaries. The starting address of each basic block is determined by the ending address of the previous block. When constructing the control flow graph, the method maps the jump target address of each basic block to the corresponding basic block number, thereby forming a clearly structured control map. Finally, in the generated basic block structure, each block contains its start and end addresses, instruction sequence, and jump target number set, forming a static execution path relationship, which provides a basis for subsequent correlation evaluation;

[0080] S2. During the JIT compilation process, whenever the system needs to translate the target instruction into the host platform machine code, the current timestamp is recorded as the translation start time; immediately after the translation is completed, the end time is obtained and the translation cost of the code block is obtained by subtraction;

[0081] In the JIT compilation cache management process that measures the translation cost operation in this embodiment, a core indicator for measuring translation cost is the compilation time, that is, the time consumed by the JIT compiler when translating a certain code block into machine code. The compilation time directly affects the startup time and runtime performance of the program, and the compilation costs of different code blocks may vary significantly. For some simple code blocks, such as short sequential instructions, the JIT only needs to perform basic instruction conversion, and the compilation time may be extremely short; while for some complex code blocks, such as code containing potentially complex branch logic, the JIT may need to perform a lot of analysis and optimization, resulting in a significant increase in compilation time. If these code blocks with high translation costs are not given priority in the cache management strategy, they may be frequently evicted and recompiled by the JIT each time they are executed, resulting in additional computing overhead.

[0082] The compilation time of code blocks in a program is not evenly distributed, but rather exhibits significant imbalance. If you count the compilation times of multiple code blocks, you'll notice that most have short compilation times, typically in the tens of milliseconds. A small number of code blocks, primarily computationally intensive code such as complex mathematical operations and deep loop structures, take longer to compile.

[0083] like Figure 3 As shown, in this example, the distribution of compile time is uneven, with a few code blocks taking much longer than the average. If this isn't taken into account in JIT code cache management, and cache replacement is performed solely based on code block access frequency, code blocks with high translation costs may be frequently evicted and require recompilation during subsequent execution. This causes the JIT to repeatedly perform expensive translation work, increasing the CPU burden and reducing overall execution efficiency.

[0084] In this embodiment, the translation cost is accurately evaluated during the JIT compilation process. Whenever the compilation of the intermediate code begins, the current timestamp is recorded, and the time consumed is calculated at the end of the translation, which is used as the compilation cost of the current code block. If the current code block does not contain relocation information, its translation time is directly calculated and stored in the cache, and the code segment address is returned; if relocation information exists, the method parses the relocation table and the symbol table after the translation is completed, adjusts the address reference in the code segment, ensures that the runtime data access is correct, and then calculates and records the final translation time again. In order to improve the stability and real-time performance of cost statistics, the present invention introduces a smoothing factor, performs exponential weighted averaging on the JIT compilation time, and avoids misleading the score due to instantaneous fluctuations. The calculation method is shown in the formula.

[0085] C=α×C B +(1-α)×C pre

[0086] Where CB For the JIT compilation time of a code block, C pre is the last compilation time, and α controls the influence of new and old data;

[0087] S3. After the translation is completed and written into the cache, the system also calculates the actual space occupied by the code block in the cache;

[0088] In this embodiment, to assess the actual cache space occupied by a code block, after JIT compilation is complete, the method extracts the relocation table and symbol table from the ELF file and executes address correction logic to correct references in the code segment and read-only data segment to ensure that all instructions can correctly access their required data. Based on this, the method calculates the overall size of the code block—the sum of the code segment size and the read-only data segment size—to measure the cache resource usage of the code block. The specific calculation method is shown in the formula.

[0089] S=S text +S rodata

[0090] S text is the code segment size, S rodata The data segment size.

[0091] In this embodiment, the size of the code block directly affects its storage cost in the cache, so in the cache replacement strategy, it is reasonable to give priority to swapping out code blocks that occupy more cache space. One of the core goals of the JIT cache is to maximize the utilization efficiency of the cache, so that more code blocks that are about to be executed can reside in the cache, improve the cache hit rate, and reduce additional JIT translation and loading overhead. Compared with small blocks of code, the replacement of a large block of code can free up more cache space, so that multiple small blocks of code can be stored at the same time, thereby improving the overall storage capacity of the cache. In the case of tight cache resources, giving priority to eliminating code blocks with higher storage costs can help improve the flexibility of the cache, allowing the cache to adapt to more diverse code execution modes, and avoid the cache being occupied by certain large blocks of code for a long time, resulting in a decrease in overall utilization.

[0092] However, determining code block replacement strategies solely based on storage cost is unreasonable, as the size of a code block does not directly determine its execution value or its impact on program performance. In a JIT runtime environment, the value of a code block is primarily determined by a combination of factors, such as its access frequency, JIT translation cost, and call chain weight. Certain large code blocks may be core execution paths of a program, with extremely high access frequency and high JIT translation cost. Prioritizing replacement simply because they occupy a large amount of cache space may result in frequent removal and retranslation of these code blocks, incurring additional overhead and even impacting overall program execution efficiency. On the other hand, although some small code blocks may occupy less cache space, if they are accessed infrequently or are executed only once, even if their storage cost is low, the benefit of retaining them may be far less than retaining a slightly larger, but frequently executed code block. Therefore, using storage cost as the sole replacement criterion may result in a large number of small, low-value code blocks being stored in the cache, while large, high-value code blocks are prematurely eliminated, reducing cache effectiveness and hit rate.

[0093] Therefore, in the scenario of multi-dimensional comprehensive scoring, it is reasonable to use cache size as a key dimension in replacement decisions, but it should not be the only determining factor. Instead, it should serve as an important reference for optimizing cache utilization. A reasonable strategy should be to first evaluate the execution value of the code block, such as its access popularity, JIT translation cost, and the relevance of the call chain, to ensure that high-value code blocks are retained first. When the execution value of multiple code blocks is similar, code blocks with higher storage costs are replaced first to free up more cache space and improve overall cache storage efficiency. This method can find the best balance between cache space utilization and the importance of code blocks, so that the cache can accommodate more code to be executed without causing unnecessary performance losses due to the accidental deletion of high-value code.

[0094] S4. During program execution, the number of accesses to each code block is counted in real time, and a time decay function is introduced to process historical accesses to form a heat value reflecting the current activity of the code block;

[0095] In this embodiment, in order to accurately model the activity of a code block, the method counts the number of accesses in real time when the code block is executed, and dynamically weights the access frequency in combination with a time decay mechanism. The present invention uses an exponential decay model to calculate the heat value of a code block, and its calculation method reflects the product relationship between the access frequency and the time factor. This model ensures that code blocks that have been frequently accessed recently have higher heat, while historical hot spots gradually cool down due to lack of continuous access, thereby effectively distinguishing between current hot spots and historical hot spots, ensuring that the most active code blocks are always retained in the cache. The specific calculation method is shown in the formula.

[0096]

[0097] access_count represents the cumulative number of accesses to the code block, t current is the current timestamp, t last_access is the timestamp of the last access to the code block, and λ is the time decay coefficient;

[0098] The execution pattern of a program is not uniform, and the heat distribution of code blocks is significantly unbalanced. In a typical computing task, most of the program's running time is usually concentrated in a few core code blocks, while a large number of other code blocks are only executed a very small number of times. This phenomenon can be visually observed through a flame graph. In the flame graph of this embodiment, each rectangle represents a function or code block, and the width of the rectangle represents the CPU time consumed by the code block during the entire execution process. The flame graph of the nbench benchmark program is as follows: Figure 4 shown.

[0099] In this embodiment, cache management based on heat can more effectively adapt to the execution mode of the program. Since the hot code of a program usually changes over time. In some applications, the program may go through multiple different execution stages, and the hot code of each stage may be different. If the cache management strategy cannot dynamically adapt to these changes, then when switching between different stages, the hot code of the old stage may still be stored in the cache, while the hot code of the new stage cannot enter the cache, resulting in a decrease in the cache hit rate. The priority of the code block cannot be determined solely by static access counts, but a dynamic heat calculation model is required. Simple access counts may cause historical hot spots to occupy the cache for a long time, while the real current hot spots cannot obtain reasonable storage space. Therefore, a reasonable heat model usually needs to introduce a time decay mechanism so that the contribution of earlier accesses gradually decreases, while the contribution of recent accesses is greater.

[0100] In this embodiment, an exponential decay method is used to calculate the heat. That is, each time a code block is accessed, the heat not only increases, but also the past heat value decays at a certain rate. This ensures that the code block in the cache is not only a past hotspot, but also a currently active hotspot.

[0101] S5. Based on the pre-built control flow graph and the current program counter location, determine the control flow distance between the code block to be replaced and the current execution path. Quantify the call chain relevance by calculating the jump depth or path distance between the current code block and the candidate code block.

[0102] In this embodiment, when the system detects that the cache space is insufficient, the system calculates its call chain relevance through the control flow graph; specifically, according to the control flow graph constructed in S1, the context relevance between the candidate replacement code block and the current execution path is analyzed. Specifically, the method calculates the call chain weight of the two based on the shortest distance between the basic block where the current PC is located and the target code block. The call chain weight is used to measure the potential importance of the code block on the current path. The shorter the path distance, the higher the possibility of it being executed again in the short term, and the larger the weight value. The calculation method of the call chain weight is shown in the formula, which ensures that the cache replacement decision is context-aware and avoids the mistaken deletion of critical code blocks that will be accessed in the short term.

[0103]

[0104] Among them, D(B current ,B target ) indicates the code block B where the current PC is located current , and candidate replacement code block B target The distance between them in the control flow graph;

[0105] In this embodiment, the cache replacement strategy is optimized by analyzing the control flow graph and evaluating the correlation between code blocks according to the closeness of the code blocks in the program execution path.

[0106] In the JIT compiler's cache management, call chain relevance is a key factor in determining the retention value of a code block. Unlike traditional metrics such as access popularity and cache size, call chain relevance focuses on the close proximity of code blocks within the program's execution path. Specifically, it examines the control flow relationship between the currently executing code block and other code blocks in the cache. By analyzing the control flow graph to more accurately assess the relevance between code blocks, cache replacement strategies are optimized to ensure that code blocks in the cache are always in the state most beneficial to the current execution path, maximizing cache hit rates, reducing unnecessary JIT translation overhead, and improving program execution efficiency.

[0107] The key step in call chain relevance is to statically analyze the code segments in the ELF file, extract the program's jump instructions, and construct a control flow graph based on these jump relationships. The core function of the control flow graph is to divide the program into multiple basic blocks. Each basic block consists of a series of instructions that are executed consecutively and is connected to other basic blocks through jump instructions to form a complete execution path. On this basis, by parsing the target addresses of jump instructions and mapping the control relationships between basic blocks, we can construct a complete execution path and quantify the likelihood that certain code blocks will be accessed in the future. For example, if a code block is a direct successor to the current execution path, its retention value in the cache should be higher. Conversely, code blocks that are farther away from the current execution path and less likely to be executed in the near future can be selected as priority replacement candidates to free up cache space for more valuable code blocks.

[0108] like Figure 5 As shown in Figure 1, the local control flow graph of the nbench test program is shown, where different basic blocks are connected by jump instructions to form the execution path of the program.

[0109] In the cache replacement strategy, call chain affinity is primarily reflected in the replacement priority of code blocks. When the JIT detects insufficient cache space and needs to load a new code block, it not only considers the size and popularity of the code block but also incorporates control flow information to determine which code blocks are more likely to be executed in the future. When a new code block is loaded into the cache, its affinity with the code blocks in the cache is determined based on the position of its program counter in the control flow graph. If certain code blocks are located far from the currently executed code block in the control flow and are less likely to appear in the future execution path, these code blocks should be given a higher replacement priority. In contrast, code blocks that are closely connected to the current execution path and are likely to be executed in the near future should be retained first to reduce future cache misses. This strategy ensures that the code blocks stored in the cache are always the most valuable to the current execution path, avoiding performance degradation caused by accidentally deleting critical code blocks.

[0110] S6. A weighted scoring model is used to calculate the retention value score (RVS) of a code block, taking into account its popularity, translation cost, cache usage cost, and relevance to the current execution path. When cache space is insufficient, the code block with the lowest score is replaced first. This maximizes cache hit rates and reduces recompilation overhead while ensuring execution efficiency, thus optimizing the performance of the just-in-time compilation system in resource-constrained environments.

[0111] In this embodiment, the parameters of the above-mentioned multiple dimensions are quantified and integrated to form a retention value score (RVS) of the code block. The scoring model comprehensively considers factors such as popularity, translation cost, cache occupancy and call chain weight, and assigns adjustable weight coefficients to each parameter to adapt to the performance requirements of different operating scenarios. The scoring calculation formula is shown in the formula. When the cache space is insufficient, the method will traverse all code blocks in the cache, calculate their RVS values, and select the code block with the lowest score as the replacement candidate. During the replacement process, the method releases the cache space occupied by the candidate code block and merges adjacent free blocks when necessary to optimize space utilization. The new code block is written to the free cache area, and its metadata information is updated to complete the replacement process.

[0112] RVS=W1×H+W2×C-W3×S+W4×CW

[0113] Among them, W1, W2, W3, and W4 represent the weight parameters of each indicator.

[0114] like Figure 6 As shown, in this embodiment, the binary translation cache replacement method based on multi-dimensional priority scoring further includes the following specific implementation steps:

[0115] S1', static analysis of the program to be executed to generate a control flow graph CFG;

[0116] S2', the program runs and loads the code block;

[0117] S3', determine whether the cache space is sufficient;

[0118] S4', if yes, then load the code block into the cache;

[0119] S5', if not, calculate the cache code block RVS;

[0120] S6', select the code block with the lowest RVS for replacement.

[0121] In this embodiment, the system weights and integrates the above four dimensions: code block popularity, translation cost, cache space occupied, and call chain relevance, and calculates the retention value score of each code block. The code block with the lowest score is selected as the replacement target. If the space to be released is large, the system can select multiple continuous or non-continuous code blocks with low scores for replacement, and merge adjacent free blocks after the replacement is completed to optimize cache space utilization. After the new code block is written to the free area, the system updates its metadata information and refreshes the instruction cache to ensure that the new code block can be executed correctly.

[0122] Example 2

[0123] To verify the effectiveness of the method of the present invention, in this embodiment, the system selects the nbench benchmark test set to compare the present invention and the traditional cache replacement strategy from the compilation time (see Figures 7 to 11 ), cache miss rate (see Figures 12 to 16 ), performance improvement (see Figures 17 to 21 ) were used for comparative experiments in three aspects. The test environment covers multiple typical task scenarios, including integer sorting, floating-point simulation, and Huffman compression.

[0124] Evaluating the effectiveness of cache replacement strategies is crucial when optimizing JIT code cache management. To verify the practical impact of the proposed code block retention value scoring method, this example conducts experimental analysis based on three metrics: compilation time, cache miss rate, and overall performance improvement. These metrics measure cache management efficiency, JIT runtime overhead, and ultimately the impact on program execution speed, enabling a comprehensive assessment of the strategy's application value in a RISC-V instruction set simulator.

[0125] During JIT compilation, the choice of cache replacement strategy directly affects the number of times a code block is repeatedly translated, thus affecting overall compilation time. To verify the effectiveness of code block retention value scoring in reducing compilation overhead, we compared the compilation time ratio of the RVS strategy to the traditional cache replacement strategy at different cache sizes. A ratio less than 1 indicates that the RVS strategy is superior, meaning compilation time is reduced; a ratio greater than 1 indicates that the RVS strategy is relatively inferior.

[0126] like Figure 7 As shown in the figure, the compilation time ratio of RVS and other strategies under the Numeric Sort test is displayed. From the experimental data, it can be seen that in small cache scenarios (such as 2K-3K), due to the severe limitation of cache space and the high replacement frequency, the multi-dimensional scoring mechanism of the RVS strategy is difficult to fully play its role, especially compared with the Flush strategy, the compilation time advantage is not significant. In small and medium cache scenarios (such as 4K-5K), the RVS strategy performs best, showing a significant compilation time optimization effect. In large cache scenarios (such as 6K and above), due to the relatively abundant cache space, the replacement frequency is greatly reduced, and the optimization effect of the RVS strategy is weakened.

[0127] like Figure 8Figure 2 shows the compilation time ratios of RVS and other strategies in the String Sort test. The compilation time of the RVS strategy is much lower than that of other strategies when the cache size is smaller (32K-40KB), especially for FIFO and LRU, where the ratios are close to zero. This indicates that RVS can effectively reduce JIT compilation overhead and improve cache utilization. However, when the cache size reaches 44KB or larger, the compilation time of the FIFO and LRU strategies gradually decreases, and the ratio with RVS is close to 1. This indicates that the replacement efficiency of traditional strategies improves in large caches, making the compilation time of all strategies more consistent.

[0128] like Figure 9 Figure 2 shows the compilation time ratio of RVS and other strategies under the Bitfield test. When the cache is smaller (2K-4K), the compilation time of the RVS strategy is much lower than that of other strategies, especially when the cache is 3K and 4K, the ratio is close to zero, indicating that the strategy can effectively reduce JIT compilation overhead and improve cache utilization. However, when the cache reaches 5K and above, the ratio of FIFO and LRU rises rapidly, and exceeds 1 at 6K, indicating that when the cache is larger, the compilation efficiency of these traditional strategies is improved, and the performance is consistent with or even slightly better than that of RVS. This is because in the case of a large cache, the cache hit rate is improved, which makes the impact of the replacement strategy relatively weakened, resulting in a narrowing of the compilation time gap between different strategies.

[0129] like Figure 10 The figure below shows the compile time ratio between RVS and other strategies under the FP EMULATION test. The RVS strategy has significantly lower compile time than other strategies when using smaller caches (40KB-52KB). As cache sizes increase (56KB and above), the ratio between FIFO and LRU gradually increases, approaching 1 for 60KB and 64KB caches.

[0130] like Figure 11 The figure below shows the compile time ratios of RVS and other strategies under the Huffman Compression test. Overall, the RVS strategy demonstrates a significant advantage when the cache size is small (13K-16KB), with compile times significantly lower than Flush, FIFO, and LRU. This is especially true when the cache size is between 13K-14KB, where the compile time ratio of RVS to FIFO and LRU approaches zero, indicating that it significantly reduces JIT compilation overhead. As the cache size increases, the compile time ratios of other strategies gradually increase, and the advantage of RVS decreases.

[0131] Experimental results show that the RVS strategy demonstrates significant advantages in small cache scenarios, with its multi-dimensional scoring mechanism effectively reducing JIT compilation overhead. However, as cache size increases, the frequency of replacements decreases, and the efficiency of the traditional strategy improves, narrowing the gap in compilation time with RVS, with performance approaching or even slightly surpassing it. This demonstrates that the RVS strategy is most effective in small cache scenarios with high replacement frequency, fully leveraging its optimization capabilities to reduce duplicate translation and compilation overhead.

[0132] The cache miss rate is a key metric for measuring the quality of caching strategies and directly impacts program execution efficiency during JIT execution. This experiment compares the cache miss rates of the RVS, LRU, FIFO, and Flush strategies at different cache sizes, analyzes the applicability of each strategy under different workloads, and evaluates the cache utilization efficiency of RVS in a JIT environment.

[0133] like Figure 12 Figure 2 shows the cache miss rates of different cache management strategies under the Numeric Sort test. It can be seen that the RVS strategy has the lowest miss rate and performs best at all cache sizes, especially at 4K and above, where its miss rate drops to almost zero. The Flush strategy has a lower miss rate overall and is close to RVS at 4K and above, indicating that it works better with larger caches, but is still slightly inferior to RVS with small caches. The FIFO strategy experiences a significant miss rate spike at a 3K cache, much higher than other strategies, and gradually recovers with larger caches. The LRU strategy performs better than FIFO, but still has a higher miss rate between 3K and 4K.

[0134] exist Figure 13 The cache miss rates of different cache management strategies under the String Sort test are shown. The cache miss rates of different cache management strategies gradually decrease as the cache size increases, among which the RVS strategy always maintains the lowest cache miss rate. The Flush strategy is close to RVS at 40KB and above, but is still slightly inferior at smaller caches. The FIFO strategy has the highest cache miss rate at 32KB and 36KB, far exceeding other strategies, indicating that its replacement mechanism at small caches leads to poor cache utilization. However, as the cache increases to 40KB and above, its miss rate drops rapidly, indicating that larger caches can alleviate its data replacement problem. The LRU strategy performs better than FIFO at small caches, but is still significantly higher than Flush and RVS. At 44KB and above, its miss rate also approaches zero, close to other strategies.

[0135] like Figure 14Figure 2 shows the cache miss rates for different cache management strategies under the Bitfield test. It can be seen that the RVS strategy consistently maintains the lowest cache miss rate, far outperforming other strategies. Both Flush and FIFO have miss rates close to 0.1 for a 2KB cache, but their miss rates decrease rapidly as the cache size increases. At 3KB, FIFO outperforms Flush, and the two gradually converge at 4KB and above, ultimately approaching zero at 5KB and above. The LRU strategy outperforms both Flush and FIFO, with a relatively steady downward trend without significant fluctuations.

[0136] like Figure 15 Figure 2 shows the cache miss rates of different cache management strategies under the FP EMULATION test. The cache miss rates of different cache management strategies decrease as the cache size increases, especially between 40KB and 44KB, where the miss rates of each strategy decrease rapidly. The RVS strategy maintains the lowest cache miss rate throughout the entire process, especially at 48KB and above, where its miss rate is almost close to zero, demonstrating extremely high cache management efficiency. The miss rates of Flush, FIFO, and LRU are relatively high when the cache is 40KB, with LRU being higher than FIFO and Flush. However, after 44KB, the miss rates of all strategies converge rapidly, and there is almost no significant difference above 52KB.

[0137] like Figure 16 Figure 2 shows the cache miss rates of different cache management strategies under the FP EMULATION test. The RVS strategy consistently maintains the lowest cache miss rate, far lower than other strategies at all cache sizes, and performs best. FIFO has the highest miss rate at 13KB, far exceeding other strategies, but it drops rapidly at 14KB, narrowing the gap with other strategies. LRU has a high miss rate at 13KB and 14KB, and experiences a downward inflection point at 15KB before gradually stabilizing. The Flush strategy performs relatively steadily, but experiences a slight increase at 15KB before falling back.

[0138] Experimental results show that the RVS strategy exhibits significant advantages when the cache is small, effectively reducing the cache miss rate. As the cache size increases, the cache miss rates of various strategies gradually converge, but the RVS strategy reaches a stable state more quickly, indicating that it is more efficient in optimizing cache utilization. This feature is particularly important for JIT execution in small cache environments, especially in the resource-constrained RISC-V simulator environment. RVS can provide a more optimized cache management solution than traditional FIFO, LRU, and Flush strategies.

[0139] The improvement in overall performance is an important indicator for measuring the effectiveness of cache management strategies. Since the overhead of JIT compilation is closely related to the cache replacement strategy, in order to more intuitively evaluate the performance advantage of RVS over traditional strategies, this experiment uses the relative rate of change as a measurement standard, that is, by calculating (performance score of other strategies - RVS score) / RVS score to reflect the performance change trend of different strategies relative to RVS. This indicator can effectively demonstrate the impact of RVS on overall performance under different cache configurations. The experiment will cover multiple benchmark tasks to verify the applicability of RVS under different workloads and analyze its performance under different cache sizes, so as to evaluate its optimization effect in JIT cache management.

[0140] like Figure 17 The figure shows the relative change rate of each strategy for RVS performance under the Numeric Sort test. As can be seen from the figure, in the case of a 2KB cache, the performance of FIFO and LRU is close to that of RVS, or even slightly better than RVS. As the cache size increases, the relative change rate of FIFO and LRU gradually decreases, and the performance gap with RVS gradually widens. At 6KB, the relative change rate of FIFO and LRU rebounds, indicating that the performance gap between the strategies has narrowed after the cache size increases. The relative change rate of the Flush strategy is generally stable, but the performance is also lower than RVS. Overall, the optimization effect of RVS in small and medium-sized cache environments is particularly significant, and it can provide more stable and efficient performance improvements in JIT cache management.

[0141] like Figure 18 The figure shows the relative change rate of each strategy with respect to RVS performance under the String Sort test. As can be seen from the figure, at cache sizes of 32KB and 36KB, the relative change rates of Flush, FIFO, and LRU are all negative, and their performance is lower than that of RVS. The relative change rates of FIFO and LRU are close to -95%, indicating that at these cache sizes, the performance of traditional strategies is far lower than that of RVS, which may result in a large amount of JIT recompilation overhead. As the cache size increases further, the relative change rates of Flush, FIFO, and LRU gradually approach 0. In particular, in the case of cache sizes of 48KB and above, the relative change rates of all strategies are close to 0, indicating that in larger cache environments, the performance gap between the strategies has significantly narrowed, and the advantage of RVS has weakened.

[0142] like Figure 19The figure shows the relative change rate of each strategy with respect to RVS performance under the Bitfield test. As can be seen from the figure, at cache sizes of 2KB to 4KB, the performance of the traditional strategy is much lower than that of RVS. At a cache size of 5KB, the relative change rate of Flush is still negative, but has improved compared to before, while the relative change rate of FIFO is close to 0, or even slightly positive, indicating that at this cache size, the performance of FIFO is close to or even slightly better than RVS. The relative change rate of LRU is also close to 0, indicating that its performance is comparable to that of RVS. At cache sizes of 6KB and above, the traditional strategy is slightly better than RVS.

[0143] like Figure 20 The figure shows the relative change rate of each strategy with respect to RVS performance under the FP EMULATION test. As can be seen from the figure, as the cache size increases, the relative change rate of each strategy gradually increases, and the performance is getting closer to that of RVS. At cache sizes of 40KB to 48KB, the relative change rates of Flush, FIFO, and LRU are all negative, and their performance is significantly lower than that of RVS. Specifically, at a 40KB cache, the relative change rates of Flush, FIFO, and LRU are close to -80%. At cache sizes of 52KB to 56KB, the performance of FIFO and LRU gradually approaches that of RVS, while Flush is still slightly behind. Above 60KB cache, the relative change rates of all strategies are close to 0, indicating that the performance gap has basically disappeared and the optimization advantage of RVS is gradually weakening.

[0144] like Figure 21 The figure shows the relative performance change of each strategy relative to RVS under the Huffman Compression test. The figure shows that as cache size increases, the relative performance change of each strategy shows a clear upward trend, approaching and even slightly surpassing RVS in some cases. In the 13KB-15KB stage, the relative performance change of Flush approaches -100%, indicating that its performance is far lower than RVS. The relative performance change rates of FIFO and LRU are also negative, but the loss is smaller. At 16KB cache, the relative performance change rates of FIFO and LRU are close to 0, indicating that their performance is comparable to or slightly better than RVS, while the relative performance change rate of Flush remains low. At 17KB cache, Flush performance improves significantly, approaching RVS, and the relative performance change rates of FIFO and LRU remain relatively stable. In cache environments of 18KB and above, the relative performance change rates of all strategies remain stable near 0, and in some cases, they even show positive values.

[0145] In summary, the RVS strategy significantly outperforms traditional FIFO, LRU, and Flush strategies in small cache environments, achieving significant overall performance improvements. Relative rate of change data indicates that it significantly reduces performance loss compared to other strategies, primarily due to its more effective retention of high-value code blocks. As the cache size increases, the performance of each strategy converges, and the relative advantage of RVS decreases. This is because when the cache is large enough, code blocks are replaced less frequently, reducing the impact of replacement strategies on overall performance. Overall, RVS effectively reduces JIT performance losses in small cache environments, making it a preferred solution for JIT code cache management in resource-constrained environments.

[0146] In summary, the beneficial effects achieved by the present invention include:

[0147] 1. Multi-dimensional comprehensive decision-making to improve replacement accuracy. Compared with existing cache replacement strategies based only on access frequency or execution count, this invention introduces multiple key dimensions such as code block popularity, translation cost, cache occupancy size, and call chain context to build a dynamic priority scoring system, making cache replacement more accurate and avoiding the problem of high-value code blocks being accidentally deleted;

[0148] 2. Introducing a time decay mechanism to better identify execution hotspots. This invention uses an exponential decay model to dynamically calculate the heat of code blocks, which can reflect the current execution activity of code blocks in real time, thereby quickly responding to changes in hotspot areas during program execution. This overcomes the problem of traditional LRU and other strategies being insensitive to hotspot switching and significantly improves cache hit rates.

[0149] 3. Support context-aware cache management. By constructing a control flow graph and calculating call chain weights, the present invention can quantify the correlation between code blocks and the current execution path, prioritize code blocks with strong path correlation, and improve the runtime adaptability of cache content, thereby enhancing the execution efficiency and stability of the overall system.

[0150] 4. Strong adaptability, applicable to a variety of test programs. The scoring model in this invention allows for flexible adjustment of the weights of each dimension and can be optimized based on the resource status of the target system and program behavior characteristics;

[0151] 5. Reduce repeated translations and lower runtime overhead. Since the present invention effectively avoids the frequent replacement of high-translation-cost code blocks, it significantly reduces the number of repeated compilations during JIT runtime, thereby reducing CPU load and memory usage. It is particularly suitable for just-in-time compilation scenarios in resource-constrained environments.

[0152] 6. Significant overall performance improvement, proven to be effective. Through field measurements and comparisons, the cache management method of the present invention demonstrates superior compilation latency, cache hit rate, and execution performance compared to traditional strategies in multiple benchmark tests, verifying its technical effectiveness and practical value in real-world applications.

[0153] The present invention solves the technical problems of low cache hit rate and long compilation time caused by the cache replacement strategy in the prior art, which usually adopts a single-dimensional decision-making approach, resulting in high translation cost code being frequently replaced in the just-in-time compilation scenario, inactive large blocks of code occupying the cache for a long time, code blocks unrelated to the current execution path residing, and the inability to identify fast switching of hot spots.

[0154] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A binary translation cache replacement method based on multi-dimensional priority scoring, characterized in that: The method comprises: S1. Before the instruction set simulator loads and prepares to execute the target program, static analysis is performed on the target program; basic blocks, jump instructions, and function call relationships in the target program are extracted using disassembly and symbol parsing techniques to construct a control flow graph (CFG); S2. During the just-in-time compilation process, the time from the start of translation to the generation of executable machine code for each code block is recorded as the translation cost of the code block; S3. Calculate the actual cache space occupied by each translated code block to obtain the cache occupancy cost. S4. During program execution, count the number of accesses to each code block in real time, introduce a time decay function to process historical access information, and obtain the heat value of the code block; S5. Based on the control flow graph CFG and the current position of the program counter, determine the control flow distance between the code block to be replaced and the current execution path; quantify the call chain relevance of the code block by calculating the jump depth and path distance between the current code block and the candidate code block; S6. Comprehensively process the heat value, translation cost, cache occupancy cost, and correlation with the current execution path of the code block, and use a weighted scoring model to calculate the retention value RVS of the code block; when cache space is insufficient, give priority to replacing the code block with the lowest score.

2. The binary translation cache replacement method based on multi-dimensional priority scoring according to claim 1, characterized in that: In S1, before the instruction set simulator starts to execute the target program, the code segment of the target program is parsed to generate a control flow graph of the program; The instructions in the code segment are parsed in a disassembly manner to identify jump behaviors and branch behaviors, and basic blocks are obtained according to jump boundaries; Determine the starting address of the current basic block based on the ending address of the previous basic block; When constructing the control flow graph CFG, the jump target address of each basic block is mapped to the corresponding basic block number to form the control flow graph CFG.

3. The binary translation cache replacement method based on multi-dimensional priority scoring according to claim 2, characterized in that: The structure of the basic block includes: a start and end address, an instruction sequence, and a jump target number set. A static execution path relationship is formed according to the structure of the basic block for correlation evaluation.

4. The binary translation cache replacement method based on multi-dimensional priority scoring according to claim 1, characterized in that: In S2, whenever the compilation of the intermediate code starts, the current timestamp is recorded, and when the translation is finished, the translation time is calculated and used as the compilation cost of the current code block; Among them, it is determined whether the current code block contains relocation information; If not, the translation time of the code block is calculated and stored in the cache, and the code segment address is returned; If so, the relocation table and symbol table are parsed after the translation is completed, and the address references in the code segment are adjusted; Calculate and record the translation time; A smoothing factor is introduced to perform exponentially weighted averaging on the JIT compilation time using the following logic: C=α×C B +(1-a)×C pre Where C B For the JIT compilation time of a code block, C pre is the last compilation time, and α controls the influence of new and old data.

5. The binary translation cache replacement method based on multi-dimensional priority scoring according to claim 1, characterized in that: In S3, the actual occupied space includes: the translated code segment and the read-only data segment.

6. The binary translation cache replacement method based on multi-dimensional priority scoring according to claim 1, characterized in that: In S3, after JIT compilation is completed, the relocation table and symbol table are extracted from the ELF file, and the address correction logic is executed to correct the references in the code segment and the read-only data segment. The overall size of the code block is calculated using the following logic to measure the degree of cache resource occupation by the code block: S=S text +S rodata Where S text is the code segment size, S rodata The data segment size.

7. The binary translation cache replacement method based on multi-dimensional priority scoring according to claim 1, characterized in that: In S4, to accurately model the activity level of a code block, the number of accesses to the code block is counted in real time during the execution of the code block. The access frequency is dynamically weighted using a time decay mechanism, and the heat value of the code block is calculated using the following logic: Where access_count represents the cumulative number of accesses to the code block, t current is the current timestamp, t last_access is the timestamp of the last access to the code block, and λ is the time decay coefficient.

8. The binary translation cache replacement method based on multi-dimensional priority scoring according to claim 1, characterized in that: In S5, the contextual relevance between the candidate replacement code blocks and the current execution path is analyzed based on the control flow graph CFG. The call chain weights of the basic block and the target code block are calculated based on the shortest distance between the basic block where the current PC is located and the target code block using the following logic: Where, D(B current ,B target ) indicates the code block B where the current PC is located current , and candidate replacement code block B target The distance between them in the control flow graph; The call chain weight is used to measure the potential importance of the code block on the current path. The call chain weight is calculated as shown in the formula.

9. The binary translation cache replacement method based on multi-dimensional priority scoring according to claim 1, characterized in that: In S6, the following logic is used to obtain the retention value score RVS of the code block: RVS=W1×H+W2×C-W3×S+W4×CW Wherein, W1, W2, W3, and W4 represent the weight parameters of the heat value, the translation cost, the cache occupancy cost, and the association with the current execution path, respectively.

10. A binary translation cache replacement system based on multi-dimensional priority scoring, characterized in that: The system comprises: A control flow graph construction module is used to perform static analysis on the target program before the instruction set simulator loads and prepares to execute the target program; using disassembly and symbol parsing technology, it extracts the basic blocks, jump instructions and function call relationships in the target program to construct a control flow graph CFG; A translation cost processing module, used for recording the time from the start of translation to the generation of executable machine code for each code block during the just-in-time compilation process as the translation cost of the code block; The cache occupancy cost processing module is used to calculate the actual space occupied by each translated code block in the cache and obtain the cache occupancy cost; A heat value determination module is used to count the number of accesses to each code block in real time during program execution, introduce a time decay function to process historical access information, and obtain the heat value of the code block; a relevance determination module, configured to determine the control flow distance between the code block to be replaced and the current execution path based on the control flow graph (CFG) and the current position of the program counter; and to quantify the call chain relevance of the code block by calculating the jump depth and path distance between the current code block and the candidate code block. The relevance determination module is connected to the control flow graph construction module; The translation cache replacement module is used to comprehensively process the heat value, translation cost, cache occupancy cost and correlation with the current execution path of the code block, and calculate the retention value RVS of the code block using a weighted scoring model; when cache space is insufficient, the code block with the lowest score is replaced first. The translation cache replacement module is connected to the translation cost processing module, the cache occupancy cost processing module, the heat value determination module and the correlation determination module.

Images