KR20110081720A - Compilation method for embedded system using precompilation during execution - Google Patents

Abstract

The present invention is a Java compilation method for an embedded system using In client Ahead-Of-Time Compiling (In c-AOTC), and more specifically, (1) while executing a Java application, the method Checking whether it is a hot spot method; (2) if it is determined in step (1) that the method is not a hotspot method, performing the method with an interpreter, and then returning to step (1) to perform the next method; (3) if it is determined in step (1) that it is a hotspot method, checking whether the machine code for the method is stored in a client-preceding compiler (c-AOTC) file; (4) if it is determined that the data is stored in step (3), after loading and relocating the corresponding machine code to perform the method, returning to step (1) to perform the next method; (5) If it is confirmed that it is not stored in step (3), after converting the bytecode of the method into machine code using a Just-In-Time Compiler (JITC), the code cache Checking whether) is full; (6) if it is determined in step (5) that the code cache is not full, storing the converted machine code in the code cache and returning to step (1) to perform the next method; And (7) if it is determined in step (5) that the code cache is full, select any method stored in the code cache to store the machine code in the client-preceding compiler (c-AOTC) file and cache the code. And after the deletion, store the converted machine code in the code cache and return to step (1) to perform the next method.
According to the Java compilation method for the embedded system proposed in the present invention, a machine converted by using a timely compiler (JITC) for a hotspot method in which a machine code is not stored in a client-preferred compiler (c-AOTC) file. If you run out of code cache when you store your code in the code cache, select any method in the code cache to store the machine code in a client-preceding compiler (c-AOTC) file, delete it from the code cache, and then delete the code cache. By configuring the machine code to be stored in a separate space, it is possible to solve the problem of insufficient code cache when using a timely compiler (JITC).

Description

Compilation method for embedded system using precompilation during execution {omitted}

The present invention relates to a Java compilation method, and more particularly, to a Java compilation method for an embedded system using preceding compilation during execution.

Many modern embedded systems are choosing Java as their software platform. For example, mobile phones, digital TVs, home networks, Blu-ray Discs, telematics, etc. use Java as an embedded software platform. The reasons why embedded systems choose Java are: First, by using virtual machines, the CPU, OS, and hardware foundations provide a consistent execution environment on a variety of embedded platforms. Second is the security advantage. In other words, the Java platform is less likely to crash the entire system due to viruses or hacked Java code. Finally, software content development is facilitated by language features (garbage collectors, exception handling) that provide a sufficiently mature and rich API and enhance program stability.

Java also provides an independent platform environment. Therefore, developers do not need to develop for various platforms. The advantage of an independent platform environment is obtained by using the Java Virtual Machine (JVM). In the JVM, bytecode is executed, which is an intermediate code compiled by Java. Bytecode is a stack-based instruction executed by the interpreter as it is translated into instructions. Therefore, it is possible to execute one bytecode by implementing only Java interpreter on various platforms. However, post-translational execution through software is slower than performing directly in hardware, so bytecodes such as Just-In-Time Compiler (JITC) or Ahead-Of-Time Compiler (AOTC) Must be accelerated using a compilation technique that translates to. Using JITC in embedded systems translates the bytecode into machine code at runtime on the target machine. On the other hand, AOTC translates the machine code into the machine code and saves the translated code in the target machine for use in execution.

Therefore, JITC has time and memory overhead used by the conversion process during execution time. AOTC can be more useful in embedded systems because it can eliminate the overhead incurred by JITC. AOTC can also generate better machine code by using powerful optimization methods throughout the program. In fact, Java AOTC is already being used as a commercial mobile phone software platform.

However, embedded systems such as DTV and mobile phones can download and use the program. In this case, the AOTC is difficult to use and must be performed by an interpreter. Using a slow interpreter means a drop in overall performance. Therefore, it is a good way to use JITC together not only for AOTC but also for quickly downloading and using programs. The most fundamental problem with using JITC in embedded systems is the conversion overhead of JITC. We must remove this overhead to get better performance.

Client Ahead-Of-Time Compiler (c-AOTC) can be used to eliminate JITC's conversion time overhead and memory overhead in embedded systems. Unlike traditional AOTC (server-AOTC) that is executed in server, c-AOTC executes AOTC using JITC's translation module which is already used. The machine code of the method converted by JITC is stored in the form of a file in the file system of the storage space. If this method is used again in a later run, the machine code in the file is read and used as is, without translating the bytecode. This eliminates the JITC overhead and can be done in machine code to reduce execution time. Many JITCs use an adaptive compilation technique that first executes with the interpreter and then JITC to compile only the frequently used methods. Therefore, when using adaptive JITC, the JITC conversion overhead and interpreter overhead can be eliminated together.

However, since the memory of the embedded system is always limited, there is not enough code cache to store the generated machine code. As a result, some method machine code is deleted for the newly JITC method machine code. Should be. This causes a problem that JITC overhead occurs when this method is executed again.

The present invention has been proposed to solve the above problems of the conventionally proposed methods, using a timely compiler (JITC) for a hotspot method for which no machine code is stored in a client-preferred compiler (c-AOTC) file. If you run out of code cache when you store the converted machine code in the code cache, select any method in the code cache to store the machine code in a client-precedence compiler (c-AOTC) file and delete it from the code cache. Its purpose is to provide a Java compilation method for embedded systems that can solve the problem of code cache shortages when using a timely compiler (JITC) by configuring it to store translated machine code in the deleted space of the code cache. It is done.

A Java compilation method for an embedded system according to a feature of the present invention for achieving the above object, Java for embedded system using the pre-compile (In client Ahead-Of-Time Compiling; In c-AOTC) As a compilation method,

(1) checking whether the method is a hot spot method while executing a Java application;

(2) if it is determined in step (1) that the method is not a hotspot method, performing the method with an interpreter, and then returning to step (1) to perform the next method;

(3) if it is determined in step (1) that it is a hotspot method, checking whether the machine code for the method is stored in a client-preceding compiler (c-AOTC) file;

(4) if it is determined that the data is stored in step (3), after loading and relocating the corresponding machine code to perform the method, returning to step (1) to perform the next method;

(5) If it is confirmed that it is not stored in step (3), after converting the bytecode of the method into machine code using a Just-In-Time Compiler (JITC), the code cache Checking whether) is full;

(6) if it is determined in step (5) that the code cache is not full, storing the converted machine code in the code cache and returning to step (1) to perform the next method; And

(7) If it is found in step (5) that the code cache is full, select any method stored in the code cache to store the corresponding machine code in the client-preceding compiler (c-AOTC) file and in the code cache. After the deletion, storing the converted machine code in the code cache and returning to step (1) to perform the next method.

Preferably,

When the conversion is completed for all methods included in one class by performing the steps (1) to (7), go to the next class and perform the steps (1) to (7), wherein the client- A precompiler (c-AOTC) file can be created, one for each class.

Preferably, in step (7),

The selected method may be the first stored method among the methods stored in the code cache.

Preferably, in step (7),

The selected method may be a method having the least number of calls among methods stored in the code cache.

More preferably,

The method may further include counting and storing the number of invocations each time the method is called.

According to the Java compilation method for the embedded system proposed in the present invention, a machine converted by using a timely compiler (JITC) for a hotspot method in which a machine code is not stored in a client-preferred compiler (c-AOTC) file. If you run out of code cache when you store your code in the code cache, select any method in the code cache to store the machine code in a client-preceding compiler (c-AOTC) file, delete it from the code cache, and then delete the code cache. By configuring the machine code to be stored in a separate space, it is possible to solve the problem of lack of code cache when using a timely compiler (JITC).

1 is a flow chart showing the configuration of a Java compilation method for an embedded system according to an embodiment of the present invention.
FIG. 2 is a diagram showing a comparison between performance values obtained using a method compiled using JITC and performance values obtained using a Java compilation method according to an embodiment of the present invention with respect to a benchmark crpyto. FIG.
3 is a diagram showing a comparison of performance values obtained using a method compiled using JITC and performance values obtained using a Java compilation method according to an embodiment of the present invention with respect to benchmark png.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a flowchart illustrating a configuration of a Java compilation method for an embedded system according to an embodiment of the present invention. As shown in FIG. 1, in the Java compilation method for an embedded system according to an embodiment of the present disclosure, in the process of starting, executing, and terminating a Java application, checking whether the method is a hotspot method (S100). If it is determined in step S100 that the method is not a hotspot method, after performing the corresponding method with an interpreter, the method returns to step S100 to perform the next method (S200). Check whether the machine code is stored in the client-priority compiler (c-AOTC) file (S300), if it is determined that the stored in step S300, after performing the loading and relocation of the corresponding machine code, step Return to S100 to perform the next method (S400), if it is determined that it is not stored in step S300, timely compile After converting the byte code of the method into machine code using JITC, and checking whether the code cache is a pool (S500, S550), if it is determined in step S550 that the code cache is not a pool, the conversion Storing the stored machine code in the code cache and returning to step S100 to perform the next method (S600), and if it is determined in step S500 that the code cache is a pool, select any method stored in the code cache to select the corresponding machine code. After storing in a client-preceding compiler (c-AOTC) file and deleting from the code cache, the converted machine code may be stored in the code cache and the process may return to step S100 to perform the next method (S700). .

In step S100, it is checked whether a specific method is a hot spot method while executing a Java application. Here, the hotspot method refers to a method having an important effect on compilation overhead because of a large execution time among methods.

In step S100, if it is determined that the method is not a hotspot method, after performing the corresponding method with an interpreter, the method returns to step S100 to perform the next method (S200), and if it is determined that the method is a hotspot method, the machine code for the method Check whether is stored in the client-priority compiler (c-AOTC) file (S300). In other words, if the target method is not a hotspot method, the interpreter executes the method as usual. If it is a hotspot method, it first checks whether the machine code of the method is stored in the c-AOTC file.

In step S300, when it is confirmed that the machine code of the method is stored, after loading and rearranging the corresponding machine code, the process returns to step S100 to perform the next method (S400). If it is determined that it is not stored, the time code compiler (JITC) is used to convert the bytecode of the method into machine code (S500), and then check whether the code cache is full (S550). That is, if the machine code for the target method is already converted and stored in the c-AOTC file, the machine code is loaded and relocated. If the machine code is not stored in the c-AOTC file, the JICT is used. To convert it. In addition, after the conversion, in order to check whether the converted machine code can be stored in the code cache, it is checked whether the code cache is full. Relocation in step S400 is an operation of modifying the address value used in the machine code to match the current execution situation when reusing the machine code stored in the file by c-AOTC. To reuse the stored machine code as it is, every time the program is run, JITC must be able to generate the same machine code for the same method. In reality, however, when the program is run, the data and the location of the code are inevitably different from each other. As a result, if the previously generated code is used as it is, the memory address in the code points to completely different data. It may cause malfunction. To avoid this, the process of modifying memory address values for data and code is called relocation.

In step S550, if it is determined that the code cache is not a pool, the converted machine code is stored in the code cache and the process returns to step S100 to perform the next method (S600). Select any saved method to save the machine code in a client-preceding compiler (c-AOTC) file and delete it from the code cache, then save the converted machine code in the code cache and return to step S100 to perform the next method. It becomes (S700). More specifically, if the current code cache is not a pool, the newly converted machine code using JITC for the target method is stored in the code cache in step S500. If the current code cache is a pool, the converted machine code is stored. To do this, we create a new space in the code cache. To do this, select any one or more of the methods stored in the code cache and delete the machine code, but before you delete it, save the machine code in a client-preferred compiler (c-AOTC) file for later use. . As such, instead of simply deleting the selected method from the code cache, the machine code is stored in a client-preceding compiler (c-AOTC) file, so that if the method is subsequently executed, the client-preferred compiler (c-AOTC) The machine code stored in the file can be loaded and reused.

In step S700, the process of selecting the machine code to delete from the cache code is important. To this end, the present invention restricts the following two methods. Of course, the two methods are merely examples and are not limited thereto.

First, you can select the method stored first among the methods stored in the code cache. This is a kind of FIFO (First In First Out) method. The present method is to select the machine code stored first by remembering the order in which the machine code is generated, which is the simplest heuristic, but can be used under the assumption that the machine code generated the longest is unlikely to be currently executed.

As another method, one of the methods stored in the code cache may be selected the least number of times. This approach is based on the determination that methods that are frequently performed during the execution of a program will continue to be called and used frequently. This decision in the Java VM is also a premise used when selecting hotspot methods that are targeted by JITC. When the method is selected using this method, a process of counting and storing the number of invocations each time the method is called is additionally required.

When the conversion is completed for all methods included in one class by performing steps S100 to S700, the process moves to the next class and performs steps S100 to S700 for the included methods. In this case, it is preferable to generate a client-preceding compiler (c-AOTC) file separately for each class.

When comparing the Java compilation method according to the present invention implemented in the step S100 to S700 with the existing method as follows. In the past, when the code cache ran out when JITC was run, two choices were available. The first choice is to no longer perform JITC. In this case, after giving up the JITC, the selected hotspot method is executed only by the interpreter for the entire execution of the program, thus losing the opportunity to obtain the performance improvement with the JITC. The second option is to select one of the methods that has already been JITCed to remove the corresponding machine code from the code cache. In this case, you can no longer run the machine code for the method that has already been selected as a hotspot. This is followed by the overhead of translating the method back to JITC. In contrast, according to the method proposed in the present invention, all the disadvantages of the above two methods selected by the JITC when the code cache is insufficient disappear. In other words, all methods selected as hotspot methods can be translated into JITC, and there is no need to translate them back into JITC to reuse machine code that has been removed due to lack of code cache.

Next, an experimental result of evaluating the performance of the Java compilation method for the embedded system using the precompilation (In c-AOTC) proposed in the present invention will be described.

The experiment was performed on the JITC implemented in SUN Microsystems' CVM RI version build 1.01_fcs-std-b12. The implemented JITC has passed most of the stability checks and follows the JVM specification. The machine used in the experiment is a MIPS-based SoC with a clock speed of 300MHz. It uses 16KB for I-cache, 16KB for D-cache, and 128MB for main memory. I installed a 40GB hard disk to store c-AOTC files. The operating system uses built-in Linux (kernel v2.4.18). The benchmark used crypto and png among EEMBC. For the performance measurement, each benchmark was run 10 times, and five of them were selected to obtain the average value. We took this approach because there is some variation in the results of the benchmark. This variation is caused by the use of embedded systems and seems to be more sensitive than typical PC or server environments. Running the benchmark ten times means running the CVM itself ten times from the beginning. This is because running the benchmark program only 10 times on the once executed CVM can distort the impact of Inc-AOTC. Before each benchmark was run, all stored c-AOTC files were removed to better measure the impact of In c-AOTC. When each benchmark was executed using JITC, we experimented by measuring the amount of machine code generated and adjusting the amount of code cache given to the benchmark to create a situation where the code cache was insufficient. crypto generates 138KB of machine code, and png generates 45KB of machine code.

We evaluated performance by limiting the code cache that the benchmark can use to 100%, 90%, 75%, and 50% for each benchmark. The performance of the benchmark was measured directly on time, not on the score of the benchmark.

JITC's performance is comparable to benchmark performance when the code cache is 100%. If the code cache is limited, JITC compiles the method to JITC as long as the code cache allows, but if the code cache runs out, it will not compile even if it is later selected as a hotspot method.

Table 1 shows a comparison of performance values obtained using a method compiled using JITC and performance values obtained using a Java compilation method according to an embodiment of the present invention with respect to benchmark crpyto. In Table 1, JITC is a performance value using JITC with the above-mentioned code cache limited, and the remaining FIFOs and LFUs using each heuristic in the method (In c-AOTC) according to the present invention with the code cache limited. It is a performance value (FIFO indicates how to select the first stored method in the code cache, and LFU indicates how to select the least number of methods stored in the code cache).

Heuristic Code cache 50% 75% 90% JITC 23887 13788 8745 FIFO 15774 12316 9905 LFU 14322 11220 9366

2 is a graph showing the performance ratio value by dividing the value of Table 1 by 8559 ms, which is the time of 100% JITC. Therefore, the value '1' in FIG. 2 is a case where the JITC has a code cache of 100%. Comparing the performance in Figure 2, it can be clearly seen that as the code cache is reduced, the performance degradation of the conventional method, JITC is the biggest. The performance of the method proposed by the present invention (In c-AOTC) is that the performance of JITC is 100% combined with the file I / O overhead of the machine code generated in the method. Therefore, it can be concluded that, when the code cache is small, the overhead of File I / O occurring in the method proposed by the present invention (In c-AOTC) is smaller than the loss lost by not using JITC in the method. In addition, it can be seen from FIG. 2 that the performance difference is severely shown among the heuristics used in the method (In c-AOTC) proposed by the present invention.

Table 2 shows the number of times of storing and loading the machine code generated by each heuristic in the method proposed by the present invention (In c-AOTC) for the benchmark crypto. In the benchmark crypto, there are 39 methods that are translated into machine code by JITC, and a "save" value of "39" means that all methods in the code cache are stored in the c-AOTC file. As the code cache decreases in Table 2, the number of times of storing and loading increases greatly, and the performance decreases in FIG. 2 in proportion to the File I / O. In addition, LFU has less storage than FIFO, which means that the amount of machine code stored in a file is less, which means less file system.

Heuristic Code cache 50% 75% 90% Save loading Save loading Save loading FIFO 39 488 39 169 29 14 LFU 17 396 8 175 4 47

Table 3 is a table comparing benchmark values with those obtained using a method compiled using JITC and a performance value obtained using a Java compilation method according to an embodiment of the present invention. In addition, FIG. 3 is a graph showing performance ratio values by dividing the values of Table 3 by 8269 ms, which is the time of 100% JITC. As for benchmark png, the performance of JITC is greatest as the code cache decreases, as in benchmark crypto, and the method proposed by the present invention (FIFO, LFU) outperforms JITC using a limited code cache. can confirm.

Heuristic Code cache 50% 75% 90% JITC 21717 11733 7573 FIFO 13247 9706 7737 LFU 11677 9975 8769

Table 4 shows the number of times of storing and loading the machine code generated for each heuristic in the method (In c-AOTC) proposed by the present invention for the benchmark png. In the benchmark png, there are 16 methods that are translated into machine code by JITC. In Table 4, as the number of code caches decreases, the number of times of storing and loading increases greatly, and the performance decreases in FIG. 3 in proportion to the file I / O. It can also be clearly seen that the amount of machine code to store is less in the LFU method than in the FIFO method.

Heuristic Code cache 50% 75% 90% Save loading Save loading Save loading FIFO 16 504 16 150 7 4 LFU 6 354 4 193 3 97

The present invention described above may be variously modified or applied by those skilled in the art, and the scope of the technical idea according to the present invention should be defined by the following claims.

S100: Step of checking if the method is a hotspot method
S200: step of performing the method with the interpreter
S300: Step to check if the machine code for the method is stored in the c-AOTC file
S400: steps performed by loading and relocating the machine code
S500: converting the byte code of the method into machine code using JITC
S550: Checking whether the code cache is a pool
S600: storing the converted machine code in a code cache
S700: selecting any method stored in the code cache, storing the corresponding machine code in the c-AOTC file, deleting it from the code cache, and storing the converted machine code in the code cache

Claims (5)

As a Java compilation method for embedded system using In client Ahead-Of-Time Compiling (In c-AOTC),

(1) checking whether the method is a hot spot method while executing a Java application;
(2) if it is determined in step (1) that the method is not a hotspot method, performing the method with an interpreter, and then returning to step (1) to perform the next method;
(3) if it is determined in step (1) that it is a hotspot method, checking whether the machine code for the method is stored in a client-preceding compiler (c-AOTC) file;
(4) if it is determined that the data is stored in step (3), after loading and relocating the corresponding machine code to perform the method, returning to step (1) to perform the next method;
(5) If it is confirmed that it is not stored in step (3), after converting the bytecode of the method into machine code using a Just-In-Time Compiler (JITC), the code cache Checking whether) is full;
(6) if it is determined in step (5) that the code cache is not full, storing the converted machine code in the code cache and returning to step (1) to perform the next method; And
(7) If the code cache is found to be full in step (5), select any method stored in the code cache to store the machine code in the client-preceding compiler (c-AOTC) file and in the code cache. After deleting, storing the converted machine code in the code cache and returning to step (1) to perform the next method

Java compilation method for an embedded system comprising a.
The method of claim 1,
When the conversion is completed for all methods included in one class by performing the steps (1) to (7), go to the next class and perform the steps (1) to (7), wherein the client- Precompiler (c-AOTC) files are generated separately for each class, Java compilation method for an embedded system.
The method of claim 1, wherein in step (7),
The selected method is Java compilation method for an embedded system, characterized in that the first stored method of the method stored in the code cache.
The method of claim 1, wherein in step (7),
The selected method is a Java compilation method for an embedded system, characterized in that the method is the least number of methods stored in the code cache.
The method of claim 4, wherein
And counting and storing the number of invocations each time the method is called.

Images