JP2007233472A - Information processor, and control method and control program of information processor - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a technique capable of attaining speeding-up in initialization processing of a program described in an intermediate code. <P>SOLUTION: The information processor having a native environment for executing a native code and a virtual machine environment for executing an intermediate code and including a storage means storing a program comprises an interpreter means for successively interpreting one or more methods constituting the program; a conversion means converting a method interpreted to be executed in activating the program, to a native code; a registration means registering the native code in association with the method; and a control means controlling to read and execute the native code, when registered, in the native environment and to execute, when the native code is not registered, the method in the virtual machine environment. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a virtual machine technique for executing a program described in intermediate code.

  Conventionally, a virtual machine technology for executing a program described by an intermediate code is known. The virtual machine environment is often realized as an interpreter that executes sequentially, but generally, the execution processing speed of a program using the interpreter is slow. Therefore, a method of converting intermediate code constituting the program into native code (hereinafter referred to as compilation) may be used. That is, the intermediate code constituting the program is converted into a data format that can be directly executed by the CPU that implements the virtual machine.

  Compiling methods include AOT (Ahead Of Time) compilation and JIT (Just In Time) compilation. In the AOT compilation, a compilation process is performed in advance before the virtual machine loads a program. In other words, it is already native code when it is loaded. On the other hand, in JIT compilation, a program is loaded with intermediate code and then compiled into native code at the time of execution. Therefore, although the operation after compilation is fast, the amount of processing required increases because compilation processing is required at the first execution.

  By the way, in the case of JIT compilation, the compiled native code is usually placed in a memory and used only when the program is executed on a virtual machine. When the execution of the program ends, the native code is discarded (hereinafter referred to as decompilation). Therefore, when the same program is operated again, it is necessary to newly compile the same part of the program.

In order to cope with this problem, Patent Document 1 proposes a technique that generates a preloaded class of compiled native code and can reuse it at the next startup of the virtual machine.
JP 2003-31658 A

  However, the compiled native code has a larger capacity than the intermediate code. Therefore, when all the native codes corresponding to the intermediate code program are stored in the memory, a huge amount of memory is required. Normally, when a memory area (also referred to as a code cache) reserved for temporary storage of compiled native code becomes full, the code cache is discarded from the code cache in order of execution frequency, for example. Then, a free memory for a newly compiled native code is secured. For this reason, native code that has already been decompiled when attempting to output the preload class cannot be included in the preload class. Therefore, the technique disclosed in Patent Document 1 has the following problems. In other words, the native code stored in the preload class is only the native code stored in the code cache when the preload class is output.

  When attempting to speed up program startup using a CPU with relatively low performance, it is desirable to compile in advance processing related to program startup (hereinafter referred to as initialization processing). However, when the initialization process is large-scale or when the code cache capacity is small, the above-described decompilation occurs.

  In particular, in a device with a small installed memory capacity, the capacity of the code cache is inevitably small, so that decompilation when using the JIT compiler is inevitable. Therefore, as a result, the intermediate code must be compiled every time the program is started, and the initialization process cannot be speeded up.

  The present invention has been made in view of the above problems, and it is an object of the present invention to provide a technique capable of realizing high-speed initialization processing of a program described in intermediate code.

  In order to solve the above problems, the information processing apparatus of the present invention has the following configuration. A native environment for executing native code configured based on a first instruction group, and a virtual machine environment for executing intermediate code configured based on a second instruction group defined independently of the first instruction group And an information processing apparatus comprising at least a storage means for storing a program composed of the intermediate code, an interpreter means for reading the program and sequentially interpreting one or more methods constituting the program, and when the program is started by the interpreter means A conversion means for converting a method interpreted to be executed into native code, a registration means for registering the native code obtained by the conversion means in association with the method in the storage means, and a method in the storage means when executing the method Whether the native code corresponding to is registered And a control unit that controls to read the native code when it is registered and execute it in the native environment, and to execute the method in the virtual machine environment when the native code is not registered. .

  ADVANTAGE OF THE INVENTION According to this invention, the technique which can implement | achieve high-speed of the initialization process of the program described by the intermediate code can be provided.

  Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the drawings. However, the constituent elements described in this embodiment are merely examples, and are not intended to limit the scope of the present invention only to them.

(First embodiment)
As a first embodiment of the information processing apparatus according to the present invention, a Java (virtual machine) virtual machine (VM) will be described below as an example. The Java (registered trademark) VM executes an application program described in Java (registered trademark) bytecode, which is an intermediate code in Java (registered trademark).

<Device configuration>
FIG. 1 is a block diagram illustrating an internal configuration of an information processing device in which a virtual machine according to the first embodiment is operating.

  The information processing device 100 includes a CPU 101 for controlling the entire device, a ROM 102 storing various control programs, and a RAM 103 used for temporary storage during program execution. A timer 104 for measuring various times, a display 105 for displaying various setting menus, a microphone 106 for inputting sound, and a speaker 107 for outputting sound are provided. In addition, various operation buttons 108, a flash ROM 109 that is a rewritable nonvolatile memory for storing various setting files, a network I / F 110 that is an interface connected to the outside of the apparatus via a network, and various data files are stored. A hard disk 111 is provided.

<Configuration and basic operation of virtual machine (VM) and application program>
FIG. 2 is a block diagram illustrating an internal configuration of the virtual machine according to the first embodiment. The virtual machine environment is realized by executing a virtual machine program that operates in a native environment.

  Reference numeral 201 denotes a VM (virtual machine), and reference numeral 220 denotes an application program (hereinafter simply referred to as an application) executed by the VM 201. Note that the application 220 includes one or more classes 231. The class 231 is described in Java (registered trademark) byte code (hereinafter simply referred to as byte code). Further, the class 231 includes methods, fields, constant pools, and other information. A method indicates an instruction of an execution unit constituting a class.

  The application 220 also stores the native code 232 that is a result of compiling the bytecode, and order information 233 that stores information about the use order and the decompile order. However, the native code 232 and the order information 233 are generated by executing an application described later, and do not exist when the application is not executed. Details will be described later.

  Further, the storage location of the application 220 may be the ROM 102 and the RAM 103 in addition to the flash ROM 109 and the hard disk 111. Alternatively, the application 120 may be read from an external device (not shown) via the network I / F 110. The memory 205 is realized as an area secured in the RAM 103 by the virtual machine.

  As described above, the application 220 stores the class 231, the native code 232, and the order information 233. However, the class 231, native code 232, and order information 233 need not all be stored in one storage medium. That is, the rectangle indicating the application 120 in the figure only conceptually indicates that the three data are associated with the same application 220.

  Therefore, the class 231, the native code 232, and the order information 233 may actually be stored in different storage media. For example, the application 220 may be configured to store the above three data as different files in the hard disk 111. Alternatively, the class 231 that generally has few changes may be stored in the ROM 102, and the native code 232 and the order information 233 that can be updated may be stored in the Flash ROM 109 that is a rewritable medium.

  The VM 201 includes a class loader 202 for loading the class 231 constituting the application program 220 from the outside. Then, an interpreter 203 for sequentially interpreting and executing the method as the execution unit in the class 231 is provided. Furthermore, a JIT (Just In Time) compiler (hereinafter simply referred to as a compiler) 204 for compiling intermediate code into CPU native code is provided.

  Further, a memory 205 for temporarily storing various data, a native code loader 210 for loading the native code 232 of the application 220 into the memory 205 and reading out the order information 233 of the application 220 to the memory 205 are provided. A native code saver 211 for storing the native code 232 stored in the memory 205 is provided. Furthermore, a decompiler 212 and other control units (hereinafter collectively referred to as VM 201) for discarding the native code 232 stored in a predetermined location of the memory 205 are provided.

  The memory 205 temporarily stores the class 206 loaded by the class loader 202. A native code 207, which is a method compiled by the compiler 204, is temporarily stored. Further, the native code 215 and the order information 216 loaded by the native code loader 210 are temporarily stored. Then, the native code 217 discarded by the decompiler 212 is temporarily stored.

  In FIG. 2, the native code 207 and the native code 215 are shown separately, but may be realized in one area in the memory 205 without distinction. Hereinafter, an area in which the native code 207 and the native code 215 are temporarily stored is referred to as a code cache 218. As described above, the native code placed in the code cache 218 is code that can be directly executed by the CPU 101.

  The decompiler 212 discards the native code in the code cache 218 from the code cache 218 under conditions described later, and stores the discarded native code as a decompiled native code 217. However, the native code 217 is stored in an area that is not directly executed by the CPU.

<Virtual machine operation (native code generation / registration) during application program execution>
FIG. 3 is an operation flowchart when an application is executed on the virtual machine according to the first embodiment. In particular, here, the operation when the application is first executed will be described. As described above, when the application 120 is operated for the first time, only the class 231 exists. Here, the generation procedure / registration procedure of the native code 232 and the order information 233 used mainly at the second and subsequent executions will be mainly described.

  In step S301, the CPU 101 starts operating the VM 201 environment based on an instruction to execute the application 220 by the operation button 108 by the user. For example, this is realized by the CPU 101 executing a VM program for realizing the VM 201 environment.

  In step S302, the VM 201 starts the application 220 designated by the user. At this time, the class loader 202 loads the class 231 into the memory 205.

  In step S303, the VM 201 determines whether the native code 232 of the application 220 can be loaded. Here, since the native code 232 of the application 220 does not exist, the process proceeds to step S304. The operation when it exists will be described later.

  In step S304, the interpreter 203 interprets and executes the byte code of the class 206 loaded in step S302. Alternatively, the CPU 101 directly executes the native code (method 207) compiled by the compiler 204. The interpreter 203 stores information (not shown) of the execution frequency (number of executions) of one or more methods constituting the class 206 in the memory 205.

  In step S305, the VM 201 determines whether the initialization of the application 220 has been completed. If initialization has not been completed, the process proceeds to step S306. If completed, the process proceeds to step S316. Note that the initialization completion of the application 220 can be determined based on whether a method call for notifying the VM 201 of the completion of initialization has been performed, or whether the first display screen of the application 220 has been displayed. it can.

  In step S306, it is checked whether the method in the class 206 loaded in step S302 needs to be compiled. If it is determined that the execution frequency is high based on the above execution frequency information, it is determined that the method needs to be compiled. Note that compiling is not necessary only when the execution frequency is high. For example, all methods that are executed before the initialization is completed may be compiled. At that time, the initialization of the application 220 for the first time requires a compile process, so more time is required. However, the initialization of the application 220 for the second and subsequent times does not run any compilation processing, and the native code is directly executed by the CPU 101, so that it takes less time. If it is determined that the compilation is necessary, the process proceeds to step S307. If it is determined that the compilation is not necessary, the process returns to step S304.

  In step S307, the VM 201 checks whether there is a free space in the code cache 218. That is, it is determined whether or not the free capacity of the code cache 218 is sufficient to store the native code 207 generated by compiling a new method. If the code cache 218 has a vacancy, the process proceeds to step S313, and if there is no vacancy, the process proceeds to step S308.

  In step S308, the VM 201 determines native code (method 207) to be decompiled. Note that the VM 201 continues to accumulate method execution frequency information after compiling, and a method with a low execution frequency becomes a decompile target.

  In step S309, the VM 201 stores the current decompile order in the decompile order 553. The order of decompilation will be described later with reference to FIG. 5, but indicates the order in which the method is decompiled, and is initialized to 0 at the start of the VM 201 (S 301).

  In step S310, the VM 201 increments the decompile order number.

  In step S311, the decompiler 212 copies the native code of the method to be decompiled to the area 117 outside the code cache 218. Here, the decompiled native code is described as being inside the memory 205, but of course, it may be stored in another location. For example, it may be stored on the hard disk 111.

  In step S312, the decompiler 212 discards the decompile target method from the code cache 218. Thereafter, the process returns to step S307, and the above steps (S307 to S312) are repeated until the code cache 218 has enough space.

  In the above steps (S307 to S312), the decompilation order is not duplicated and added to the method. For that purpose, the increment process of step S310 may not be performed. By configuring in this way, it becomes easy to collectively decompile methods to which the same decompile order is added later.

  In step S 313, the compiler 204 compiles the byte code of the method that needs to be compiled to generate a native code, and stores it in the code cache 218. If symbol information is necessary to generate the relocatable native code 232 later, symbol information and reference information from the native code are generated and stored here, and a part of the memory 205 (not shown) or other information is stored. It may be stored in a storage medium.

  In step S314, the VM 201 stores the current use order in the use order 552. The order of use will be described later with reference to FIG. 5. This indicates the order in which the native code of the method is used (executed), and is initialized to 0 when the VM 201 starts (S301).

  In step S315, the VM 201 increments the number of the current usage order. Thereafter, the process returns to step S304.

  In step S316, the native code saver 211 registers the order information 216 generated based on the use order 552, the decompile order 553, and the like as the order information 233. More specifically, first, the native code saver 211 scans the method information 551 for each method stored in the memory 205, sorts the method information 551 from the youngest in the usage order 552, and creates new order information 216 in the memory 205.

  In step S 317, the native code saver 211 reads the native code from the code cache 218 and registers it as the native code 232. The symbol information may be read from the memory 205 and stored together as a relocatable code.

  In step S 318, the decompiled native code 217 is additionally stored in the native code 232.

  In the above procedure, the order information 216 and native code are registered when it is determined that the initialization is completed. However, the timing of the registration process may be arbitrarily determined as necessary. For example, since it takes time until a specific process, if it is desired to speed up the process by executing native code, the process may be stored when the timing is reached.

<Data structure>
FIG. 4 is a diagram for explaining the relationship between the native code and the order information and the internal structure (structure). The data format related to the native code and order information is common outside and inside the VM 201. However, the value of pointer data etc. changes.

  The order information 401 includes a method number 402 indicating the number of methods included in the order information 401. Further, each method includes a use order 403, a decompilation order 404, a method name pointer 405, a code pointer 406, and a code length 407. The data that exists for each method exists for the number indicated by the method number 402. Further, the method name 413 that is text data indicating the name of the method is continued by the number indicated by the method number 402. The method name 413 is variable length data. The end of the data is represented by a null character.

  In the method name pointer 405 of the method 0, a pointer indicating the head of the method name 0 413 is stored. This value varies depending on the storage location of the order information 401. For example, when the order information 401 exists as a file on the hard disk 111, the method name pointer 405 stores an offset from the beginning of the method name 0 413 at the beginning of the file. When the order information 401 exists in the memory 205, the method name pointer 405 stores the head address of the method name 0 413. When the native code loader 210 reads the order information 233 and stores it in the memory 205 as the order information 216, the method name pointer 405 is rewritten as described above.

  The native code 451 is a native code corresponding to each method. Incidentally, the native code stored here may be relocatable or not relocatable. Note that being relocatable means that it can be rearranged at a position on the memory.

  When the compiler 204 converts bytecode into native code, or when the native code loader 210 loads the native code 232, the native code 451 is placed in the code cache 218. However, the native code 451 is a non-relocatable code that has been address-resolved to enable direct execution by the CPU 101. On the other hand, the native code 232 registered by the native code saver 211 is a relocatable code so that it can be placed at any address in the code cache 218.

  When the order information 401 and the native code 451 are both placed as files on the hard disk 111, the method pointer 0 of the method code 0 452 in the native code 451 stores the offset from the beginning of the file. The code length 407 of method 0 stores the byte length of method code 0. The same applies to other methods.

  On the other hand, when both the order information 401 and the native code 451 are placed in the memory 205, the start address of the method code 0 452 in the native code 451 is stored in the code pointer 406 of the method 0. The code length 407 of method 0 stores the byte length of method code 0.

  Incidentally, the length of the method code 452 may change depending on whether the native code 451 is placed as a file on the hard disk 111 or in the memory 205. For example, since symbol information is included in the case of relocatable native code, it is longer than in the case of non-relocatable code. In this case, when the native code 451 is read into the memory 205, the value stored in the code length 407 is updated based on the change of the method code 452 itself. That is, when the address resolution is completed, the symbol information becomes unnecessary and is removed, and the code length is shortened.

  The order information 401 stored in the memory 205 is represented by the methods 0, 1,. . . Are arranged in ascending order of the usage order 403 in advance. The data from the use order 403 to the code length 407 prepared for each method has a fixed length size. In this way, an operation for selecting a method in ascending order of the usage order 403 can be performed at high speed.

  FIG. 5 is a diagram for explaining the data internal structure (structure) of decompile order information, decompile method information, and method information. Both show the structure of data temporarily stored in the memory 205.

  The decompile order information 501 is data arranged in ascending order of the decompile order, and each piece of data includes a decompile order 502 and a decompile method pointer 503. In the decompile order 502, the value of the decompile order 404 is stored. When the native code loader 210 reads the order information 233, the order information 401 is stored in the memory 105, and all methods included in the order information 401 are scanned to check the decompilation order 404. We will line up from. Note that the decompile order 404 may overlap, that is, there may be a plurality of methods having the same decompile order 404. The decompile method pointer 503 stores the start address of the decompile method information 531 that stores information about a method having the value stored in the decompile order 502 as the decompile order.

  The method number 532 of the decompile method information 531 stores the number of methods having the same decompile order. The method pointer 533 for the number of methods follows. The method pointer 533 stores the start address of the method information 551 for the corresponding method.

  The method information 551 stores information about each method, and a lot of data is brought from the order information 401. The method information 551 stores a usage order 552 for storing the usage order when the method is actually executed, and a decompilation order 553 for storing the decompilation order when the method is actually executed. In addition, a method name pointer 554 that stores a method name pointer 405 for the method is stored. In addition, a code pointer 555 storing a code pointer 406 for the method is stored. Furthermore, a code length 556 that stores the code length 407 for the method is stored. Then, a decompiled code pointer 557 for storing a pointer to the native code in the decompiled native code 217 is stored. Further, a loaded usage order 558 storing the usage order 403 for the method and a loaded decompilation order 559 storing the decompilation order 404 for the method are stored.

  In FIG. 5, data that overlaps with the order information 401 is also placed in the method information 551 in order to easily show what information about each method is. But it doesn't have to be duplicated. Of course, since it is information about the same method, both may be linked so that duplicate data is held in only one of them.

<Virtual machine operation during execution of application program (execution by reading native code)>
FIG. 6 is an operation flowchart when an application is executed on the virtual machine according to the first embodiment. In the second and subsequent application executions, the native code 232 and the order information 233 are stored and registered in addition to the class 231. Here, mainly the execution of an application using the native code 232 and the order information 233 will be mainly described. Here, the procedure after it is determined in step S303 described above that the native code 232 can be loaded will be described.

  In step S <b> 601, the native code loader 210 reads the order information 233 and stores it in the memory 205 as the order information 216. As shown in FIG. 4, the order information 401 is sorted in advance in ascending order of use order, but is not sorted in ascending order of decompile order. Usually, since there is no relationship between the use order and the decompilation order, if the use order is sorted by the key, they are not arranged in the order of the decompilation order. However, in this case, it is difficult to scan the method from the youngest decompile order. Therefore, the native code loader 210 analyzes the read order information 401 and generates data of decompile order information 601 and data of decompile method information 631 sorted in ascending order of the decompile order. In addition, data of method information 651 that is information about each method is also generated. At this time, the value of the use order 403 is stored in the loaded use order 558. The decompile order 404 is stored in the loaded decompile order 559.

  Note that the sort process is for speeding up the method search process to be performed later, regardless of the order of use or the order of decompilation, and is not an essential process. Therefore, if it is desired to avoid the time required for the sorting process itself or to reduce the consumption memory, the sorting process may not be performed.

  In step S602, the native code loader 210 loads the native code 232 from the younger use order 403 until the code cache 218 becomes full. The code pointer 406 stores an offset in the native code 232 of the target method, and the code length 407 stores the length of the target method in the native code 232. Therefore, individual method data in the native code 232 can be accessed. At the time of loading, the native code loader 210 performs address resolution processing and converts it into a format that can be directly executed by the CPU 101. Further, the code pointer 406 and the code length 407 are updated so as to conform to the method code 452 in the code cache 218.

  In step S603, the VM 201 executes the code of the application 220.

  In step S604, the VM 201 checks whether the initialization of the application 120 has been completed. The case where the initialization is completed will be described later with reference to FIG. If initialization has not been completed, the process proceeds to step S605.

  In step S605, the VM 201 determines whether the next code execution is a method call and the native code of the method should be executed. In the case of Yes, it progresses to step S606, and in No, it returns to step S603.

  In step S606, the VM 201 checks whether the native code of the method exists in the code cache 218. If it exists in the code cache 218, the process proceeds to step S607, and if not, the process proceeds to step S611.

  In step S607, it is checked whether the method is a native code that has already been executed once. If the method has been executed, the process returns to step S603. If the method has not been executed, the process proceeds to step S608.

  In step S608, the VM 201 stores the current use order number in the use order 552.

  In step S609, the VM 201 increments the current use order number.

  In step S610, the use order deviation evaluation point 702 is updated. The use order deviation evaluation point 702 is data indicating a deviation state between the use order 552 stored in step S608 and the loaded use order 558. Specifically, the deviation state is evaluated and scored for each method and added to the entire VM 201. For example, the absolute value of the difference between the usage order 552 and the loaded usage order 558 may be used as the point of the method. Then, the update process is performed by adding the point to the current use order deviation evaluation point.

  FIG. 7 shows an example of data other than the data shown in FIG. These pieces of data exist for each VM 201, and include, for example, the number of newly compiled methods 701, use order deviation evaluation points 702, and decompile order deviation evaluation points 703.

  In step S611, the VM 201 checks whether the native code of the method exists in the native code 232 that is the registration destination. This is determined by examining the order information 401. If the required method is in the order information 401, the native code is in the native code 232. When it exists, it progresses to step S612, and when it does not exist, it progresses to step S616.

  In step S612, the VM 201 determines whether there is sufficient free space in the code cache 218. If there is a vacancy, the process proceeds to step S613. Otherwise, the process proceeds to step S620.

  In step S613, the VM 201 determines whether to load another native code whose use order is young. It should be noted that the information serving as a criterion for determination is set in advance when the VM 201 is activated or designated by another method. For example, when the application 220 to be started is the same every time and the command options and the configuration of the application 220 are the same, it is often possible that the order of the methods executed by the VM 201 does not change. In such a case, the usage order of the methods is the same, so that loading the method at a time reduces the number of times and the time for accessing the storage destination, rather than loading the method native codes one by one. In particular, I / O access to the Flash ROM 109, the network I / F 110, the hard disk 111, and the like is a process that takes a very long time, so it is better to reduce the number of times as much as possible. For that reason, it is useful to set that other native code with a lower usage order should also be loaded. If it is determined that another code should be loaded, the process proceeds to step S615, and if it is determined not to be loaded, the process proceeds to step S614.

  In step S614, the VM 201 loads the native code corresponding to the method specified in step S605. Thereafter, the process returns to step S608.

  In step S615, the methods that have not yet been loaded in the order information 401 are loaded into the code cache 218 in order from the lowest use order 403. Of course, the loading of the native code searched from the younger use order 403 is limited to the capacity of the code cache 218. Thereafter, the process returns to step S608.

  In step S620, the VM 201 determines whether the decompile order 404 is included in the order information 301. If the decompile order 404 exists, the process proceeds to step S621, and if not, the process proceeds to step S629. In the procedure shown in FIG. 3, the decompilation order is saved, but it is not necessary to save it. In that case, the presence of step S620 enables operation even if the decompile order is not saved.

  In step S621, the VM 201 selects the native code in the code cache 218 from the younger one in the decompile order 404. The decompile order information 601, decompile method information 631, and method information 651 described above are used for the process of selecting from the younger one. If there are a plurality of methods having the same decompile order, a plurality of native codes are selected.

  In step S622, the VM 201 determines whether or not the execution frequency of the selected native code is lower than a frequency specified in advance. When it is low, the process proceeds to step S823, and when it is high, the process proceeds to step S830. If a plurality of native codes are selected in step S621, the determination is made for each.

  In step S623, the VM 201 stores the current decompile order number in the decompile order 553.

  In step S624, the VM 201 increments the current decompile order number.

  In step S625, the decompiler 212 copies the native code of the decompile target method to the area 117 outside the code cache 218.

  In step S626, the decompiler 212 discards the decompile target method from the code cache 218.

  In step S627, the VM 201 updates the decompilation order evaluation point 703. The decompile order deviation evaluation point 703 is evaluated in the same manner as the use order deviation evaluation point described above, and the point is updated.

  In step S628, the VM 201 confirms whether there is sufficient space in the code cache 218. If there is sufficient space, the process returns to step S613, and if not, the process returns to step S620.

  In step S629, the VM 201 refers to the execution frequency information of the decompile order 404 and determines a decompile target method. Thereafter, a decompilation process starting from the above-described step S623 is performed on the native code.

  However, with regard to the update processing of the decompilation order deviation evaluation point in step S627, in the case of this sequence, the loaded decompilation order 559 does not exist. Therefore, the absolute value of the difference between the decompile order 553 and the loaded decompile order 559 cannot be taken. Therefore, as a process in this case, for example, the decompilation order deviation evaluation point 703 is set to the maximum value. By doing so, the decompilation order is always saved later. If the decompilation order does not need to be stored, the decompilation order deviation evaluation point 703 may not be changed.

  In step S630, the decompilation order deviation evaluation point 703 is updated. In this case, since the actual decompilation is not performed, a valid value is not set in the decompilation order 553. Therefore, an operation that takes the absolute value of the difference between the decompile order 553 and the loaded decompile order 559 cannot be performed. However, decompile order 404 (ie, loaded decompile order 559) shows a young value. Nevertheless, the fact that it should not be decompiled indicates that the decompile order has changed.

  Therefore, here, for example, the decompile order deviation evaluation point 703 is updated by adding a value obtained by subtracting the value of the decompile order 559 loaded from a certain constant value. In this way, the smaller the decompile order native code, the larger the decompile order evaluation point 703 can be added.

  In step S 616, the compiler 204 compiles the byte code of the method that needs to be compiled to generate native code, and stores it in the code cache 218.

  In step S617, the VM 201 stores the current use order number in the use order 552.

  In step S618, the VM 201 increments the current use order number.

  In step S631, the VM 201 updates the use order deviation evaluation point 702. Here, since a new method needs to be compiled, there is no usage order 558 loaded for this method. Therefore, the absolute value of the difference between the usage order 552 and the loaded usage order 558 cannot be taken. Therefore, a method of setting the use order deviation evaluation point to the maximum value as in the above-described processing for the decompilation order deviation evaluation point 703 is conceivable.

  In step S619, the number of newly compiled methods 701 is incremented. Thereafter, the process returns to step S603.

<Virtual machine operation after application program execution (update of native code)>
By the way, the method required for the initialization operation of the application changes due to a change of parameters or the like. In other words, different native codes may be required for the same application. In the following, the operation of the virtual machine in such a case, in particular, the native code update operation will be described.

  FIG. 8 is an operation flowchart when an application is executed on the virtual machine according to the first embodiment. As in the case of FIG. 6, in the second and subsequent application executions, the native code 232 and the order information 233 are stored and registered in addition to the class 231. Here, the procedure after it is determined in step S604 described above that the initialization of the application 220 has been completed will be described. That is, the following operation is an operation executed at a timing after the application 220 is activated.

In step S801, the VM 201 determines whether or not the decompilation order evaluation point 703 has exceeded a predetermined value. If exceeded, the process proceeds to step S802, and if not exceeded, the process proceeds to step S803.

In step S <b> 802, the VM 201 updates the decompile order 404 of the order information 401 in the memory 205 with the value of the decompile order 553 for the method for which the decompile order 553 is set.

  In step S803, the VM 201 determines whether or not the use order deviation evaluation point 702 has exceeded a predetermined value. If exceeded, the process proceeds to step S804, and if not exceeded, the process proceeds to step S805.

  In step S804, the VM 201 updates the use order 403 of the order information 401 in the memory 205 with the value of the use order 552 for the method for which the use order 552 is set.

  In step S805, the VM 201 determines whether or not the number of newly compiled methods 701 exceeds a predetermined number. If exceeded, the process proceeds to step S806, and if not exceeded, the process proceeds to step S807.

  In step S806, the VM 201 creates order information 401 for the newly compiled method.

  In step S807, the VM 201 scans the method information 551. Whether or not the number of methods for which the order of use 552 is not set, that is, the number of methods that have been loaded but not used, even though the loaded use order 558 is set, exceeds a predetermined number Determine whether. If exceeded, the process proceeds to step S808, and if not exceeded, the process proceeds to step S809.

  In step S808, the VM 201 deletes the order information 401 regarding the corresponding method. Also, the VM 201 stores what method has the order information 401 deleted.

  In step S809, the VM 201 determines whether or not the code pointer 406 of the order information 401 remains at the file offset and the number of methods that have not been converted into addresses has exceeded a predetermined number. That is, it is determined whether or not the number of methods from which the order information 401 has been read but the native code has not been read from the native code 232 exceeds a predetermined number. If exceeded, the process proceeds to step S810, and if not exceeded, the process proceeds to step S811. If it is not possible to distinguish whether the code pointer 406 is a file offset or an address, information indicating whether or not the native code has been loaded may be added for each method of the order information 401, and the determination may be made accordingly.

  In step S810, the VM 201 deletes the native code 132. In this case, the native code 132 is completely replaced.

  In step S811, the VM 201 determines whether or not the answer is YES in any of step S801, step S803, step S805, step S807, and step S809. That is, it is determined whether saving of either the order information 401 or the native code is necessary. If it is determined that storage is not necessary, the process ends.

  In step S812, the VM 201 determines whether it is Y in step S805 or step S809, that is, whether it is necessary to save the native code. If it is determined that the native code needs to be stored, the process proceeds to step S813. If it is determined that the native code needs not be stored, the process proceeds to step S815.

  In step S813, the VM 201 generates a set of native codes to be saved. Note that the native code to be saved is stored in the code cache 218 or the decompiled native code 217. By this step, the non-relocatable native code becomes a relocatable native code. Further, it is preferable to arrange each method in a continuous area like the native code 451. That is to say, this arrangement facilitates storage, which will be described later.

  In step S814, the VM 201 sets information regarding each method in the order information 401. Here, the code pointer 406 and the code length 407 are updated in accordance with the saving as the native code 232. The method name pointer 405 is also updated when the order information 401 is saved.

  In step S <b> 815, the VM 201 sorts the data part for each method of the order information 401 by the value of the use order 403.

  In step S816, the native code saver 211 stores the order information 401 as the order information 233.

  In step S817, the VM 201 determines whether it is necessary to save all native code. Specifically, when the storage destination native code 232 is deleted in step S810, it is determined that all storage is necessary. If all storage is necessary, the process proceeds to step S818. If all storage is not necessary, the process proceeds to step S819.

  In step S818, the native code saver 211 stores all the native code in the native code 232, and the process ends.

  In step S819, the VM 201 determines whether it is necessary to add a native code. Specifically, if new method order information 401 is generated in step S806, it is determined that addition is necessary. If necessary, the process proceeds to step S820; otherwise, the process proceeds to step S821.

  In step S 820, the native code saver 211 adds the native code of the method that created the order information 401 in step S 806 to the native code 232.

  In step S821, the VM 201 determines whether it is necessary to delete the native code. Specifically, if there is a method from which the order information 401 is deleted in step S808, it is determined that deletion is necessary. If necessary, the process proceeds to step S822, and if not necessary, the process ends.

  In step S822, the VM 201 deletes the native code for the deletion target method stored in step S808 from the native code 232. Then exit.

  As described above, according to the information processing apparatus of the first embodiment, it is possible to complete initialization of a program written in byte code more quickly. Further, by performing update processing according to the use state of the native code at the time of initialization after the initialization of the application 220 is completed, it is possible to store the more efficient native code 232.

  In other words, even if the code cache size is small and decompilation is unavoidable during initialization, the decompiled code can be reused and the next program startup can be accelerated. Become. Therefore, it can be used not only for devices having a relatively large memory resource, such as PCs, copiers, and multifunction devices, but also for consumer devices with little memory, such as personal printers and digital cameras. In particular, in consumer equipment, in order to reduce manufacturing costs, a central processing unit having a minimum performance is used, and a high-speed technique such as the present invention is effective.

  Also, when the compiled code stored in the external storage device is loaded into the code cache and the program is executed, efficient loading is possible by referring to the order of use and loading the code, which contributes to speeding up.

(Second Embodiment)
In the second embodiment, by managing the native code 232 and the order information 233 for each application 220, it is possible to efficiently manage native codes for a plurality of applications. The apparatus configuration and the operation of the virtual machine 201 at the time of execution for each application are the same as those in the first embodiment, and thus detailed description thereof is omitted.

<Configuration of virtual machine (VM) and application program>
FIG. 9 is a conceptual diagram of a software hierarchical structure when a plurality of applications are executed. In FIG. 9, an application management manager 901 operates on the VM 201, and a plurality of applications 220a to 220c are managed and executed by the application management manager 901.

  FIG. 10 is a block diagram illustrating an internal configuration of the virtual machine according to the second embodiment. The virtual machine environment is realized by executing a virtual machine program that operates in a native environment. In order to avoid complication of the figure, some arrows are deleted in FIG. 10 compared to FIG. Below, the part added with respect to FIG. 2 is demonstrated.

  The application management manager 901 includes an installer 1001, an uninstaller 1002, an execution start instruction unit 1003, a stop instruction unit 1004, and an initialization completion notification unit 1005. The installer 1001 has a function of installing (registering) one or more applications 220. The uninstaller 1002 has a function of uninstalling (deregistering) the installed application 220. The execution start instruction unit 1003 has a function of specifying the application 220 and instructing the start of execution. The stop instruction unit 1004 has a function of specifying the application 220 being executed and instructing the stop. Further, the initialization completion notification unit 1005 has a function of notifying the VM 201 of the completion of initialization of the application 220.

  On the other hand, the VM 201 includes a native code deletion unit 1021, an order information deletion unit 1022, a memory order information deletion unit 1023, and an initialization end detection unit 1024 in addition to the units illustrated in FIG. The native code deletion unit 1021 has a function of deleting the native code 232. The order information deletion unit 1022 has a function of deleting the order information 233. The memory order information deleting unit 1023 has a function of deleting order information for each method in the order information 216. The initialization completion detection unit 1024 has a function of detecting completion of initialization of the application 220.

<Installation (registration) and management of application>
FIG. 11 is an operation flowchart when an application is executed on the virtual machine according to the second embodiment. Here, it is assumed that three applications 220a, 220b, and 220c are stored in the ROM 102 and registered in the application management manager 901 by the installer 1001 in advance. Note that the registration operation by the installer 1001 may be performed independently of the activation of the application, but may be configured such that the registration operation is automatically performed when an execution instruction is given for a certain application for the first time.

  In step S1101, the CPU 101 starts the operation of the VM 201 environment based on an instruction to execute the application 220 by the operation button 108 by the user. For example, this is realized by the CPU 101 executing a VM program for realizing the VM 201 environment.

  In step S1102, the VM 201 starts the application management manager 901.

  In step S1103, the execution start instruction unit 1003 selects and starts the application 220 designated by the user from the already installed applications 220a to 220c. In the following description, it is assumed that the application 220a is selected.

  In step S1104, the VM 201 starts executing the application 220a. Specifically, the operation described with reference to FIGS. 3 and 6 is performed in the first embodiment. That is, the native code 232 and the order information 233 of the application 220a are loaded and read, the order information 401 is updated, and the like. In step S1105, it is determined whether initialization of the application 220a has been completed. If not completed, the initialization operation is continued. If completed, the process advances to step S1106. The completion of initialization is realized by, for example, notification to the VM 201 by the initialization completion notification unit 1005 or detection of initialization completion by the initialization completion detection unit 1024.

  In step S1106, the VM 201 stores the native code 232 and the order information 233 of the application 220a.

  In step S1107, the VM 201 determines whether there is sufficient space in the code cache 218. If there is a vacancy, the process proceeds to step S1114; otherwise, the process proceeds to step S1108. This step has a different meaning from the step described in the first embodiment (for example, S307). That is, here, it is determined whether or not there is sufficient free space in the code cache 218 necessary for starting other applications (220b, c).

  In step S <b> 1108, the VM 201 determines an execution frequency criterion for determining that the object is to be decompiled. The determination method may be configured to accept input from the user, or may be determined using an initial parameter (not shown) designated in advance.

  In step S <b> 1109, the VM 201 determines whether there is a method that is included in only the class 231 of the application 220 a and has an execution frequency lower than the above-described execution frequency among the plurality of applications 220. If there is no low one, the process proceeds to step S1110, and if there is a low one, the process proceeds to step S1112.

  In step S1110, the VM 201 determines whether there is a method that is used in common among a plurality of applications 220 (hereinafter referred to as a common method) and that has an execution frequency lower than the above-described execution frequency. If there is no low one, the process proceeds to step S1111. If there is a low one, the process proceeds to step S1112. By dividing step S1110 from step S1109, it is possible to lower the priority of decompilation of the common method compared to the method specific to the application 220a.

  In step S <b> 1111, the VM 201 increases the execution frequency criterion for determining that the object is to be decompiled. Thereafter, the process returns to step S1109. By repeating steps S1109 to S1111, a method to be decompiled is determined in step S1109 or step S1110.

  In step S1112, the decompiler 212 decompiles the native code of the method selected as the decompile target. This is the same processing as the decompilation described in the first embodiment. However, the decompiled native code is not copied to the area 217. This is because the native code necessary for the next activation is already stored in step S1106, so no copy is necessary.

  In step S1113, the memory order information deletion unit 1023 deletes the order information 216 of the decompiled method. Then, the process returns to step S1107.

  In step S1114, the VM 201 initializes the order information (usage order 552 and decompile order 553) of the method and common method of the application 120a. This is to prevent old order information from remaining when the application 120a-c to be started next is executed.

  In step S1115, the execution start instruction unit 1003 selects and starts the second application 220 designated by the user from the already installed applications 220a to 220c. Then, for the second application (for example, 220b), the process returns to step S1103 and the same processing is performed.

<Uninstall (delete registration)>
FIG. 12 is an operation flowchart when the application is uninstalled on the virtual machine according to the second embodiment. Here, it is assumed that three applications 220a, 220b, and 220c are stored in the ROM 102 and registered in the application management manager 901 by the installer 1001 in advance.

  In step S1201, the CPU 101 starts operation of the VM 201 environment based on an instruction to execute the application 220 by the operation button 108 by the user. For example, this is realized by the CPU 101 executing a VM program for realizing the VM 201 environment.

  In step S1202, the VM 201 starts the application management manager 901.

  In step S1203, the uninstaller 1002 starts uninstalling an application (for example, 220c) designated by the user, for example. Specifically, the application 220c is made in a state where it cannot be started immediately, such as deleting a shortcut.

  In step S1204, the native code deletion unit 1021 deletes the native code 232c corresponding to the application 220c.

  In step S1205, the order information deletion unit 1022 deletes the order information 233c corresponding to the application 220c.

  Through the above steps, the application 220c is returned to the non-installed state. Note that the native code deletion unit 1021 and the order information deletion unit 1022 may be operated according to an instruction from the stop instruction unit 1004. In this case, only the native code 232c and the order information 233c are deleted, and shortcuts and the like can be left without being deleted.

<Save native code corresponding to common methods>
As described above, when there are a plurality of applications 220, there may be a method (common method) common to two or more applications. In particular, as described in the first embodiment, in the case of a method corresponding to the initialization process, the probability that a common method exists is high.

  In this case, for example, it is assumed that a common method exists in the native code 232a of the application 220a and the native code 232b of the application 220b. In this case, when the initialization of the application 220a is completed, when the initialization of the application 220b is started, it is inefficient to further load the native code 232b corresponding to the common method. In addition, the efficiency with respect to the storage area will be poor.

  Therefore, when there is a common method, it is desirable to register the native codes corresponding to the method as one. And it is good to comprise so that only the position (pointer) of a common code may be stored in the code field corresponding to each application.

  FIG. 13 is a diagram for explaining the storage format of the native code corresponding to the common method.

  Reference numeral 1301 denotes the internal structure of the native code 232a of the application 220a. Reference numeral 1321 denotes the internal structure of the native code 232b of the application 220b. The native code 1302 corresponding to the method specific to the application 220a is directly stored in the native code 232a. The native code 1322 corresponding to a method specific to the application 220b is directly stored in the native code 232b.

  On the other hand, the native code 1352 corresponding to the common method of the application 220a and the application 220b is stored inside the common native code 1351. Only a pointer to the native code 1352 is stored in the native code 232a and the native code 232b.

  The common native code 1351 is stored in a location accessible from the VM 201. However, it is not necessary to place the application 220a-related native code 1301 and the application 220b-related native code 1321 in the same place.

  As described above, according to the information processing apparatus of the second embodiment, in addition to the advantages described in the first embodiment, it is possible to use the code cache more efficiently when operating a plurality of applications. As a result, it also contributes to speeding up initialization.

  Further, by storing native code in a common area for methods common to a plurality of applications, it is possible to store more native code with less storage capacity.

(Other embodiments)
The present invention can also be achieved by supplying a program that realizes the functions of the above-described embodiments directly or remotely to a system or apparatus, and the system or apparatus reads and executes the supplied program code. The Accordingly, the program code itself installed in the computer in order to realize the functional processing of the present invention by the computer is also included in the technical scope of the present invention.

  Examples of the recording medium for supplying the program include a floppy (registered trademark) disk, a hard disk, an optical disk (CD, DVD), a magneto-optical disk, an MO, a magnetic tape, and a nonvolatile semiconductor memory.

  In addition to the functions of the above-described embodiments being realized by the computer executing the read program, the OS running on the computer based on the instruction of the program is a part of the actual processing. Alternatively, the functions of the above-described embodiment can be realized by performing all of them and performing the processing.

  Furthermore, after the program read from the recording medium is written in a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer, the function expansion board or The CPU or the like provided in the function expansion unit performs part or all of the actual processing, and the functions of the above-described embodiments are realized by the processing.

It is a block diagram which shows the internal structure of the information processing apparatus with which the virtual machine which concerns on 1st Embodiment is operating. It is a block diagram which shows the internal structure of the virtual machine which concerns on 1st Embodiment. It is an operation | movement flowchart at the time of executing an application on the virtual machine which concerns on 1st Embodiment (1st time). It is a figure explaining the relationship between a native code and order information, and an internal structure (structure). It is a figure explaining the data internal structure (structure) of decompile order information, decompile method information, and method information. It is an operation | movement flowchart at the time of executing an application on the virtual machine which concerns on 1st Embodiment (after the 2nd). An example of data other than the data shown in FIG. 2 placed on the memory 205 is shown. It is an operation | movement flowchart at the time of executing an application on the virtual machine which concerns on 1st Embodiment (after completion of initialization). It is a conceptual diagram of the software hierarchical structure at the time of performing a some application. It is a block diagram which shows the internal structure of the virtual machine which concerns on 2nd Embodiment. It is an operation | movement flowchart at the time of executing an application on the virtual machine which concerns on 2nd Embodiment. It is an operation | movement flowchart at the time of uninstalling an application on the virtual machine which concerns on 2nd Embodiment. It is a figure explaining the preservation | save format of the native code corresponding to a common method.

Claims (8)

A native environment for executing native code configured based on a first instruction group; and a virtual machine environment for executing intermediate code configured based on a second instruction group defined independently of the first instruction group; An information processing apparatus comprising storage means for storing a program composed of at least the intermediate code,
Interpreter means for reading the program and sequentially interpreting one or more methods constituting the program;
Conversion means for converting the method interpreted by the interpreter means to be executed when the program is started into native code;
A registration unit that registers the native code obtained by the conversion unit in the storage unit in association with the method;
When executing the method, check whether the native code corresponding to the method is registered in the storage means, if the native code is registered, read the native code and execute it in the native environment, Control means for controlling execution of the method in a virtual machine environment when native code is not registered;
An information processing apparatus comprising:   2. The update apparatus according to claim 1, further comprising an update unit configured to update a native code corresponding to each method registered in the storage unit based on the number of execution times of one or more methods constituting the program. Information processing device.   The information processing apparatus according to claim 1, wherein the native code registered in the storage unit is a relocatable native code that has not been address-resolved.   The information processing apparatus according to any one of claims 1 to 3, wherein the registration unit registers the reading order information of the one or more native codes in the storage unit together with the one or more native codes. apparatus. Management means for managing registration of the native code corresponding to one or more programs in the storage means;
The information processing apparatus according to any one of claims 1 to 4, wherein the management unit deletes the native code together when the application is removed from the registration management target.   The information processing apparatus according to claim 5, wherein the management unit registers and manages a native code corresponding to a method common to the one or more programs in a common area provided in the storage unit. A native environment for executing native code configured based on a first instruction group; and a virtual machine environment for executing intermediate code configured based on a second instruction group defined independently of the first instruction group; A method of controlling an information processing apparatus comprising storage means for storing a program composed of at least the intermediate code,
An interpreter step of reading the program and sequentially interpreting one or more methods constituting the program;
A conversion step of converting a method interpreted by the interpreter step to be executed when the program is started into a native code;
A registration step of registering the native code obtained by the conversion step in the storage means in association with the method;
When executing the method, it is confirmed whether or not the native code corresponding to the method is registered in the storage means. If the native code is registered, the native code is executed in the native environment, A control process for controlling the method to be executed in a virtual machine environment when the code is not registered;
A control method comprising: A native environment for executing native code configured based on a first instruction group; and a virtual machine environment for executing intermediate code configured based on a second instruction group defined independently of the first instruction group; A control program for an information processing device comprising storage means for storing at least a program composed of the intermediate code,
Program code for reading the program and executing an interpreter step for sequentially interpreting one or more methods constituting the program;
A program code for executing a conversion step of converting a method interpreted by the interpreter step to be executed when the program is started into a native code;
Program code for executing a registration step of registering the native code obtained by the conversion step in the storage means in association with the method;
When executing the method, it is confirmed whether or not the native code corresponding to the method is registered in the storage means. If the native code is registered, the native code is executed in the native environment, A program code for executing a control process for controlling the method to be executed in a virtual machine environment when the code is not registered;
A control program comprising:

Images