Method and system for optimizing Java card virtual machine
By converting the CAP format file of Java application into an optimized CAP file format and directly executing machine code and byte code on the Java card, the problem of inefficient operation of existing Java card virtual machines is solved, and a significant improvement in execution efficiency is achieved.
Patent Information
- Application Number
- CN202510073598.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-15
- Publication Date
- 2025-05-13
AI Technical Summary
The implementation of the interpreter of the existing Java card virtual machine results in inefficient operation, making it difficult to implement optimization technologies such as JIT or AOT on smart card hardware with limited resources.
The CAP format file of Java application is converted into an optimized CAP file format composed of machine code and bytecode through an off-card virtual machine, and downloaded to the Java card. The virtual machine in the card directly recognizes and performs the optimized machine code and bytecode.
It significantly improves the running efficiency of Java applications and improves the user's experience when using the card.
Smart Images

Figure CN119987942A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to a method and system for optimizing a Java card virtual machine. Background Art
[0002] The JAVA smart card virtual machine specification defines a Java-compatible virtual machine for smart cards. The JAVA smart card virtual machine is a virtual machine model used to support bytecode execution to implement the features of the Java language on the smart card platform.
[0003] The Java card virtual machine (JCVM) is the core component of the Java card. It consists of two parts: the card internal part and the card external part. The card external part is the Java card conversion tool, which generates a cap file from a Java file. The card internal virtual machine is responsible for interpreting and executing the bytecode on the card, managing classes and objects, etc., to ensure the security and consistency of the code. JCVM only supports a limited subset of the Java programming language, retaining features such as objects, inheritance, packages, dynamic object creation, virtual methods, interfaces, and exceptions. The life cycle of JCVM is consistent with the life cycle of the card itself.
[0004] Java card applications involve multiple application scenarios such as electronic payment, identity authentication, data encryption, etc. Especially in the use scenarios such as electronic payment and identity authentication, the shorter the user's expected time in actual use, the better. However, the execution of Java applications is limited by the parsing method of the Java card virtual machine, so the optimization of the Java card virtual machine is particularly important.
[0005] The existing Java Card virtual machines are basically implemented based on interpreters. Java Applet (Java Card application) consists of a series of bytecodes. When the interpreter is running, it reads a single Java bytecode in sequence, and then interprets and executes it with a piece of C code. The operating efficiency is very low. Its operating efficiency is basically the same as that of the early version of the Java virtual machine. The operating efficiency of the same function is roughly 1 / 5 of that of the C language implementation. Due to the limitation of smart card hardware resources, Java optimization technologies such as JIT (Just-In-Time Compiler) and AOT (Ahead-Of-Time) are difficult to implement on the Java Card virtual machine. This is also a major bottleneck that hinders the continued development of Java Card.
[0006] Therefore, the technical problem that urgently needs to be solved is: how to optimize the Java card virtual machine and improve the operating efficiency of Java applications. Summary of the invention
[0007] The purpose of the present application is to provide a method and system for optimizing a Java card virtual machine. The method converts a CAP format file compiled from a Java card application into an optimized CAP file format consisting of executable machine code and bytecode through an off-card virtual machine, and then downloads the file to a Java card. When the application on the Java card is executed, the bytecode and machine code can be directly identified by the optimized on-card virtual machine, thereby improving the operating efficiency of the Java application.
[0008] To achieve the above-mentioned purpose, as a first aspect of the present application, the present application provides a method for optimizing a Java card virtual machine, the method comprising: obtaining a CAP format file after compiling a Java application, wherein the CAP format file is a file composed of bytecodes and complies with the JCVM specification; converting the CAP format file of the Java application into an optimized CAP format file, wherein the optimized CAP format file is an optimized CAP format file composed of machine code and bytecode or an optimized CAP format file composed of pure machine code; downloading the Java application stored in the optimized CAP format file to a Java card; and in response to application instructions on the Java card, sequentially reading the Java application stored in the optimized CAP format file corresponding to the application instructions.
[0009] The method for optimizing the Java card virtual machine as described above, wherein the CAP format file of the Java application is converted into an optimized CAP format file, comprises: a CAP format file splitting step, which comprises: when reading the CAP format file, identifying the jump when executing the bytecode, if there is a jump, using the jump as a node, splitting the CAP format file into multiple sub-program blocks, and recording the jump relationship between each sub-program block; if not, the CAP format file is not split.
[0010] The Java card virtual machine optimization method as described above, wherein the CAP format file of the Java application is converted into an optimized CAP format file, also includes: a bytecode translation step, which includes: if there is no jump, all JAVA bytecodes of the CAP format file are translated into C code; if there is a jump, the bytecodes in each subroutine block after the split are translated into C code, and the remaining bytecodes maintain the original format.
[0011] In the Java card virtual machine optimization method as described above, the bytecode translation step further includes: restoring the translated C code of each subroutine to the organizational structure of the Java method before translation according to the jump relationship.
[0012] The method for optimizing the Java card virtual machine as described above, wherein the reading of the CAP format file and the decomposition of the CAP format file into multiple sub-program blocks include: reading the CAP format file and parsing out all Java classes; parsing out all Java methods of the Java class, and then sequentially reading the bytecode of a single Java method; when sequentially reading the bytecode of a single Java method, identifying the jumps that occur when executing the bytecode, and using the jumps as nodes to decompose the bytecode into multiple sub-program blocks.
[0013] The method for optimizing the Java card virtual machine as described above, wherein the CAP format file of the Java application is converted into an optimized CAP format file, also includes: a reorganization compilation step, which includes: optimizing the C code by running the external simulation subroutine block function; reorganizing and compiling the optimized C code according to the calling relationship of the CAP format file before conversion to obtain machine code, wherein the calling relationship of the CAP format file is the calling relationship between methods and classes followed by Java application development.
[0014] In the method for optimizing the Java card virtual machine as described above, after the COS system receives the instruction sent by the card reader, it determines whether the instruction is an application instruction. If so, the instruction is sent to the corresponding application on the Java card for processing. If not, the instruction is directly processed by the COS system.
[0015] The Java card virtual machine optimization method as described above, wherein, in response to the application instruction on the Java card, sequentially reading the Java application stored in the optimized CAP format file corresponding to the application instruction includes: after the virtual machine in the card reads a single data in the series of data generated after compiling the application corresponding to the application instruction, it is determined whether the data is a bytecode, and if so, the bytecode is first parsed according to the bytecode parsing process, and then the parsing code of the bytecode is executed in sequence; otherwise, the data is a machine code, and the machine code is directly executed; and the above steps are executed in a loop until the execution of the application instruction is completed.
[0016] As a second aspect of the present application, the present application provides a system for optimizing a Java card virtual machine, which executes the method for optimizing a Java card virtual machine, and the system includes: an off-card virtual machine, which is used to convert a CAP format file of a Java application into an optimized CAP format file, wherein the optimized CAP format file is an optimized CAP format file composed of machine code and bytecode, or is an optimized CAP format file composed of pure machine code; an on-card virtual machine, which is used to respond to application instructions on the Java card and sequentially read the Java application stored in the optimized CAP format file corresponding to the application instructions.
[0017] The beneficial effects achieved by this application are as follows:
[0018] (1) Under the premise that the design of Java application development and compilation remains unchanged, this application optimizes the compilation of Java applications before running by optimizing the virtual machine outside the card, and optimizes the Java card at the running level by optimizing the virtual machine inside the card, which can significantly improve the execution efficiency of the Java card. The execution efficiency of the optimized Java application is significantly improved, and the user experience is significantly improved when using the card. BRIEF DESCRIPTION OF THE DRAWINGS
[0019] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present application. For those skilled in the art, other drawings can also be obtained based on these drawings.
[0020] Figure 1 The present invention is a flowchart of a method for optimizing a Java card virtual machine according to an embodiment of the present application.
[0021] Figure 2 This is a flow chart of a method in which an off-card virtual machine according to an embodiment of the present application converts Java application code into an optimized CAP format file consisting of machine code and bytecode.
[0022] Figure 3 This is a flow chart of a method for converting a CAP format file into an optimized CAP format file consisting of machine code and bytecode in an embodiment of the present application.
[0023] Figure 4 A flow chart of a method for reading a CAP format file and decomposing the CAP format file into multiple sub-program blocks according to an embodiment of the present application.
[0024] Figure 5 A flowchart of a method for reorganizing and compiling C code to obtain machine code and form an optimized CAP format file is provided for the embodiment of the present application.
[0025] Figure 6 This is a schematic diagram of an off-card virtual machine converting Java application code into a CAP format file according to an embodiment of the present application.
[0026] Figure 7 This is a schematic diagram of an off-card virtual machine converting Java application code into an optimized CAP format file according to an embodiment of the present application.
[0027] Figure 8 A schematic diagram of the implementation process of off-card virtual machine optimization according to an embodiment of the present application.
[0028] Fig. 9 The present invention is a flowchart of the implementation of the virtual machine optimization in the card of the embodiment of the present application.
[0029] Fig.10 This is a schematic diagram of a CAP format file disassembly method according to an embodiment of the present application.
[0030] Fig.11 A schematic diagram of a bytecode translation method according to an embodiment of the present application.
[0031] Fig.12 Schematic diagram of the reorganization compilation method according to an embodiment of the present application.
[0032] Fig.13 A schematic diagram of the structure of a system for optimizing a Java card virtual machine according to an embodiment of the present application. DETAILED DESCRIPTION
[0033] The following is a clear and complete description of the technical solutions in the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.
[0034] Embodiment 1
[0035] like Figure 1 As shown, the present application provides a method for optimizing a Java card virtual machine, the method comprising:
[0036] Step S1, obtaining a CAP format file after compiling the Java application.
[0037] Among them, the CAP format file is a file composed of bytecodes and complies with the JCVM specification.
[0038] Step S2: convert the CAP format file of the Java application into an optimized CAP format file.
[0039] The optimized CAP format file is an optimized CAP format file composed of machine code and bytecode or an optimized CAP format file composed of pure machine code.
[0040] Specifically, the CAP format file of the Java application is converted into an optimized CAP format file consisting of machine code and bytecode or an optimized CAP format file consisting of pure machine code through an off-card virtual machine.
[0041] More specifically, the Java application code of the Java card application is first compiled to obtain a CAP format file composed of bytecodes (CAP format file is a commonly used network data packet storage format), and then the CAP format file is converted into formatted data composed of a series of bytecodes and machine codes or formatted data composed of pure machine codes through off-card virtual machine optimization processing, that is, the optimized CAP format file.
[0042] As an embodiment of the present invention, the off-card virtual machine converts the Java application code into an optimized CAP format file, including: directly obtaining the CAP format file of the Java application, and converting the CAP format file of the Java application into an optimized CAP format file.
[0043] As another embodiment of the present invention, Figure 2 As shown, the off-card virtual machine converts the Java application code into an optimized CAP format file including:
[0044] Step S210: the external virtual machine converts the Java application code into a CAP format file.
[0045] It should be explained that the off-card virtual machine refers to a tool that converts Java application code into CAP format files.
[0046] like Figure 6 As shown, the Java application code is converted into a CAP format file by a Java card external virtual machine.
[0047] Among them, the CAP format file is composed of Java bytecodes that follow the JCVM specification and are divided into 11 components, including Header, Import, Class, Method, etc. After the Java application code is optimized, the CAP format file can be converted into an optimized CAP file format consisting of executable machine code and bytecode.
[0048] Step S220, converting the CAP format file into an optimized CAP format file.
[0049] like Figure 7 As shown, after the Java off-card virtual machine converts the Java application code into a CAP format file, the CAP format file is converted into an optimized CAP format file through off-card optimization.
[0050] like Figure 3 As shown, converting a CAP format file into an optimized CAP format file includes:
[0051] Step S221, read the CAP format file, and disassemble the CAP format file into multiple sub-program blocks.
[0052] It should be explained that after breaking down the CAP format file into multiple subprogram blocks, developers can have a clearer understanding of the structure of the application. These subprogram blocks can be translated into C code and then recompiled into machine code for direct recognition and execution by the virtual machine in the card.
[0053] like Figure 4 As shown, the CAP format file is read and the CAP format file is disassembled into multiple subprogram blocks including:
[0054] Step S2211, read the CAP format file and parse out all Java classes.
[0055] It needs to be explained that in Java classes, classes are usually composed of fields (attributes) and methods (behaviors). Fields represent the state of the object, while methods define the operations that the object can perform.
[0056] Step S2212, parse out all Java methods of the Java class, and then read the bytecode of each Java method in sequence.
[0057] Step S2213, when reading the bytecode of a single Java method in sequence, identify the jumps that occur when executing the bytecode, and split the bytecode into multiple subprogram blocks using the jumps as nodes.
[0058] When the bytecodes of a single Java method are read sequentially, the jumps that occur when the bytecodes are executed are identified, and the bytecodes before the current bytecode are formed into a subprogram block. In the above manner, all the bytecodes of a single Java method are split into multiple subprogram blocks.
[0059] Step S222, parse all bytecodes in a single subroutine block and translate them into corresponding C codes.
[0060] Step S223, reorganize and compile the C code to obtain machine code and form an optimized CAP format file.
[0061] like Figure 5 As shown, the C code is recompiled to obtain the machine code, and the optimized CAP format file is formed, including:
[0062] Step S2231, optimizing the C code by running the external simulation subroutine block function.
[0063] It should be explained that the external simulation of sub-program block function operation usually refers to the use of specific software tools or development platforms to simulate the functional logic of a sub-program block in the smart card to perform operation tests and other operations in an environment outside the card. For example, when developing Java card applications, since it is relatively difficult to debug the internal environment of the smart card and resources are limited, developers can use simulator software to simulate the behavior of each sub-program block in the smart card in an ordinary computer environment. For example, the sub-program block simulating the payment function can simulate its operation processes such as receiving payment instructions, calculating the amount, and verifying passwords, so as to verify whether the function of the sub-program block is correct and whether it meets business requirements, so as to find and solve problems before the application is officially deployed in the smart card.
[0064] It should be explained that the benefit of optimizing the translated C code by running external simulation subroutine block functions is that it facilitates debugging and analysis: the simulation subroutine block function operation allows developers to observe the execution of each functional module more clearly, such as whether the input and output meet expectations, the state changes of various variables, etc. When debugging C code translated from other languages, it is possible to accurately locate which subroutine block corresponds to the part of the C code that has logical errors or does not meet expectations, which is convenient for quick correction.
[0065] Step S2232, reorganize the optimized C code according to the calling relationship of the CAP format file before conversion, where the calling relationship of the CAP format file is the calling relationship between methods and classes followed by Java application development.
[0066] It is necessary to explain that the C code is reorganized according to the calling relationship of the CAP format file before conversion, that is, according to the established association order between the various parts of the original Java card application, the corresponding functions, modules, etc. in the C code are reorganized and arranged so that the structure can be restored or close to the functional logic architecture in the original CAP format file. Ensure that the converted C code can accurately reproduce the functions of the original Java card application. Reorganizing the C code according to the calling relationship of the CAP format file before conversion can ensure the application function and improve the efficiency of application development.
[0067] Step S2233, compile the reorganized C code into executable machine code to form an optimized CAP format file.
[0068] It should be explained that the above steps are the implementation process of off-card virtual machine optimization, which is the process of converting the CAP format file generated by Java Applet code into an optimized CAP format file composed of machine code and bytecode or pure machine code.
[0069] Step S3, downloading the Java application stored in the optimized CAP format file into the Java card.
[0070] It should be explained that when the optimized CAP format file is downloaded to the Java card, the virtual machine in the card can directly recognize the optimized CAP format file composed of machine code.
[0071] As a specific embodiment of the present invention, the optimized CAP format file is downloaded to the Java card, so that when the application is executed, the virtual machine in the card can directly recognize the bytecode and machine code after optimization. The machine code is the code that the virtual machine in the card can directly understand and execute. The direct execution of the machine code avoids the extra overhead caused by the interpretation or compilation process of the intermediate code, can make the execution speed of the program faster, and the instructions can be quickly processed by the hardware, reducing the processing delay. Since there is no need for a complex compilation tool chain or an additional interpreter to occupy space, a large amount of storage resources can be saved in a resource-limited card environment (the memory and storage resources of devices such as smart cards are usually very small). The virtual machine in the card directly recognizes and executes the machine code, which can greatly improve the execution efficiency of the application.
[0072] Step S4, in response to the application instruction on the Java card, sequentially read the Java application stored in the optimized CAP format file corresponding to the application instruction.
[0073] After receiving the instruction sent by the card reader, the COS system determines whether the instruction is an application instruction. If so, the instruction is sent to the corresponding application on the Java card for processing. If not, the instruction is directly processed by the COS system.
[0074] As a specific embodiment of the present invention, the off-card virtual machine converts the CAP format file of the Java application into the optimized CAP format file, including three steps: CAP format file disassembly, bytecode translation and recompilation.
[0075] like Figure 8 and 10 As shown, the CAP format file disassembly includes:
[0076] Step P1, read the CAP format file and identify whether there is a jump when executing the bytecode.
[0077] Step P2: If there is a jump, the CAP format file will be split into multiple sub-program blocks with the jump as a node, and the jump relationship between each sub-program block will be recorded. If there is no jump, the CAP format file will not be split.
[0078] It should be noted that when reading the bytecode of the CAP format file, the jump when executing the bytecode is identified, the CAP format file is split into multiple sub-program blocks and the jump relationship between the sub-program blocks is recorded.
[0079] Specifically, the CAP format file disassembly method includes: first reading the CAP format file and parsing out all Java classes; then parsing out all Java methods of the Java class in turn; then reading the bytecode of a single Java method in turn, identifying the jump when executing the bytecode, and splitting these bytecodes into multiple sub-program blocks with the jump as the node, to ensure that the bytecode within a single sub-program block does not have any jump. When reading the bytecode of a single Java method, the jump when executing the bytecode is identified during the reading process and split into sub-program blocks with the jump as the node, that is, when the bytecode of a single method is split into multiple sub-program blocks, the jump relationship between each sub-program block can be obtained. It can be understood that the bytecode between two adjacent jumps is regarded as a sub-program block. It should be noted that the sub-program blocks need to be translated and parsed, and the other bytecodes maintain the original bytecodes.
[0080] As a specific embodiment of the present invention, when the jump recognizes that bytecode A is a jump statement, the current bytecode A is used as a node, and the bytecodes before the current bytecode A form a subprogram block.
[0081] It needs to be explained that the jump relationship refers to the recognition that a certain bytecode A in program B is a jump statement, allowing program B to interrupt the current execution flow and continue execution from another program C. This line is called a jump, and the jump relationship refers to jumping from program B to program C.
[0082] like Figure 8 and 11 As shown, bytecode translation includes:
[0083] Step P3: If there is no jump when the bytecode is identified and executed, all JAVA bytecodes in the CAP format file are translated into C code.
[0084] Step P4: If a jump is detected when executing the bytecode, the bytecodes in each of the split subprogram blocks are translated into C code, and the remaining bytecodes maintain their original formats.
[0085] Step P5, restore the translated C code of each subroutine block to the organizational structure of the Java method of each subroutine block before translation according to the jump relationship.
[0086] Specifically, if a jump is identified when executing the bytecode, all the bytecodes in a single subroutine block are parsed separately and translated into corresponding C codes. The jump relationship table established when the CAP format file is disassembled is queried, and the corresponding C code is restored to the Java method structure before translation according to the jump relationship. For example, the basic stack operation bytecode sadd (0x41) is translated into C code as: result = value1 + value2; when all the bytecodes in a single subroutine block are parsed, object access operations occur, and object access and modification are implemented by designing get / set interface methods.
[0087] It needs to be explained that the CAP format file is divided into 11 components, including Header, Import, Class, Method, etc., by Java bytecode following the JCVM specification. The class structure after translation still complies with the requirements of Java Card and maintains its original organizational structure.
[0088] like Fig.12 As shown, the reorganization compilation includes:
[0089] Step P6, optimizing the C code by running the external simulation subroutine block function.
[0090] Step P7, reorganize and compile the optimized C code according to the calling relationship of the CAP format file before conversion to obtain machine code.
[0091] Specifically, the Java method structure in C code format is reorganized according to the calling relationship between methods and classes in the original CAP format file, and the reorganized C code is compiled into executable machine code to form an optimized CAP format file. Among them, the calling relationship is the calling relationship between methods and classes followed by Java application development.
[0092] It should be explained that the relationship between method calls and classes is reorganized. To ensure that Java application packages can access methods and call variables normally, the class structure still complies with the requirements of Java Card and maintains its original organizational structure, including all variable domains, links to external access methods, etc. Finally, the reorganized C code is compiled into executable machine code to form an optimized CAP format file.
[0093] It needs to be explained that the virtual machine in the card can be understood as a machine or processor responsible for interpreting and running Java bytecodes, managing classes, objects, etc. The current Java card virtual machine mainly executes Java applications by parsing and running Java bytecodes.
[0094] As a specific embodiment of the present invention, a Java application is converted into CAP format data consisting of a series of bytecodes by an unoptimized off-card virtual machine; and converted into optimized CAP format data consisting of a series of executable machine codes and bytecodes by an off-card optimized virtual machine. When the application is running, the optimized virtual machine inside the card can interpret the bytecode and recognize and execute the machine code, thereby improving the running efficiency of the Java application.
[0095] The virtual machine in the card sequentially reads the series of data generated after the application is compiled corresponding to the application instruction, and parses and executes the read data including:
[0096] After the virtual machine in the card reads a single data in the series of data generated after the application corresponding to the application instruction is compiled, it determines whether the data is a bytecode. If so, it first parses the bytecode according to the bytecode parsing process, and then executes the parsing code of the bytecode in sequence; otherwise, the data is a machine code and the machine code is directly executed; the above steps are executed in a loop until the application instruction is executed.
[0097] like Fig. 9 As shown, the working process of the virtual machine in the card is as follows:
[0098] Step T1, in response to the COS system receiving the instruction, determining whether the instruction is an application instruction, if so, it is processed by the corresponding application; if not, it is directly processed by the COS system.
[0099] Step T2: the virtual machine in the card sequentially reads a series of data generated after the application is compiled, and determines whether the read single data is a bytecode.
[0100] Specifically, the application instruction is executed, and the virtual machine in the card sequentially reads the series of data generated after the application is compiled and parses and executes. The virtual machine in the card directly parses the bytecode in the optimized CAP format file, and directly recognizes and runs the machine code in the optimized CAP format file.
[0101] Step T3: If the virtual machine in the card determines that the read data is a bytecode, it will parse the bytecode according to the bytecode parsing process, and then execute the parsing code of the bytecode in sequence.
[0102] Step T4: the virtual machine in the card determines that the read data is not bytecode, but machine code, and directly executes the machine code.
[0103] Step T5, determine whether the application instruction is completed. If not, loop through steps T2-T4 until the application instruction is completed. If yes, execute step T6.
[0104] Step T6: After the application instruction is completed, it is processed by the COS system and the instruction flow ends.
[0105] This application requires the cooperation of the virtual machine inside the card and the virtual machine outside the card to achieve the optimization effect of the Java card virtual machine and improve the operating efficiency of the Java application.
[0106] Embodiment 2
[0107] like Fig.13 As shown, the present application provides a system 100 for optimizing a Java card virtual machine, the system executes the method for optimizing a Java card virtual machine, and the system includes:
[0108] The off-card virtual machine 10 is used to convert the CAP format file of the Java application into an optimized CAP format file. The optimized CAP format file is an optimized CAP format file composed of machine code and byte code or an optimized CAP format file composed of pure machine code.
[0109] The virtual machine 20 in the card is used to respond to the execution of the application instruction on the Java card and sequentially read the Java application stored in the optimized CAP format file corresponding to the application instruction.
[0110] The present application also provides a computer storage medium, wherein the computer storage medium stores computer instructions, and when the computer instructions are called, they are used to execute the address mapping method of the large-capacity solid-state hard disk. The computer storage medium contains one or more program instructions, and the one or more program instructions are used by the processor to execute a method for optimizing a Java card virtual machine.
[0111] The embodiment disclosed in the present invention provides a computer-readable storage medium, in which computer program instructions are stored. When the computer program instructions are executed on a computer, the computer executes the above-mentioned method for optimizing a Java card virtual machine.
[0112] An embodiment of the present invention provides a processor for processing the above-mentioned method for optimizing a Java card virtual machine.
[0113] In the embodiment of the present invention, the processor may be an integrated circuit chip having the ability to process signals. The processor may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0114] The methods, steps and logic block diagrams disclosed in the embodiments of the present invention can be implemented or executed. The general processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the embodiments of the present invention can be directly embodied as a hardware decoding processor for execution, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The processor reads the information in the storage medium and completes the steps of the above method in combination with its hardware.
[0115] The storage medium may be a memory, which may be, for example, a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memory.
[0116] Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM) and direct RAM bus random access memory (DRRAM).
[0117] The beneficial effects achieved by this application are as follows:
[0118] (1) Under the premise that the design of Java application development and compilation remains unchanged, this application optimizes the compilation of Java applications before running by optimizing the virtual machine outside the card, and optimizes the Java card at the running level by optimizing the virtual machine inside the card, which can significantly improve the execution efficiency of the Java card. The execution efficiency of the optimized Java application is significantly improved, and the user experience is significantly improved when using the card.
[0119] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this application, "plurality" means two or more, unless otherwise clearly and specifically defined.
[0120] In the description of the present application, the word "for example" is used to mean "used as an example, illustration or explanation". Any embodiment described as "for example" in the present application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is given to enable any technician in the field to implement and use the present invention. In the following description, details are listed for the purpose of explanation. It should be understood that a person of ordinary skill in the art can recognize that the present invention can be implemented without using these specific details. In other examples, well-known structures and processes will not be elaborated in detail to avoid obscuring the description of the present invention with unnecessary details. Therefore, the present invention is not intended to be limited to the embodiments shown, but is consistent with the widest scope consistent with the principles and features disclosed in the present application.
[0121] The above description is only an embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent substitution, improvement, etc. made within the spirit and principle of the present invention should be included in the scope of the claims of the present invention.
Claims
1. A method for optimizing a Java card virtual machine, characterized in that: The method includes: Obtain a CAP format file after the Java application is compiled, wherein the CAP format file is a file composed of bytecodes and complies with the JCVM specification; Converting a CAP format file of a Java application into an optimized CAP format file, wherein the optimized CAP format file is an optimized CAP format file composed of machine code and bytecode or an optimized CAP format file composed of pure machine code; Download the Java application stored in the optimized CAP format file to the Java card; In response to the application instructions on the Java card, the Java applications stored in the optimized CAP format files corresponding to the application instructions are read in sequence.
2. The Java Card virtual machine optimization method according to claim 1, characterized in that: Convert the Java application's CAP format file to an optimized CAP format file, including: The CAP format file splitting step includes: reading the CAP format file, identifying whether there is a jump when executing the bytecode, if there is a jump, taking the jump as a node, splitting the CAP format file into multiple sub-program blocks, and recording the jump relationship between each sub-program block; if not, the CAP format file is not split.
3. The Java Card virtual machine optimization method according to claim 2, characterized in that: Convert the Java application's CAP format file to an optimized CAP format file, including: Bytecode translation step, which includes: If there is no jump when the bytecode is identified and executed, all JAVA bytecodes in the CAP format file are translated into C code; If there is a jump when the bytecode is recognized and executed, the bytecode in each subroutine block after the split is translated into C code, and the remaining bytecodes maintain the original format.
4. The method for optimizing a Java Card virtual machine according to claim 3, characterized in that: The bytecode translation step also includes: The translated C codes of each subroutine are restored to the organizational structure of the Java method before translation according to the jump relationship.
5. The method for optimizing a Java card virtual machine according to claim 1 or 3, characterized in that: Decomposing the CAP format file into multiple subprogram blocks includes: Read the CAP format file and parse out all Java classes; Parse all Java methods of the Java class, and then read the bytecode of each Java method in turn; When reading the bytecode of a single Java method in sequence, the jumps that occur when executing the bytecode are identified, and the bytecode is split into multiple subprogram blocks using the jumps as nodes.
6. The method for optimizing a Java Card virtual machine according to claim 3, characterized in that: Convert the Java application's CAP format file to an optimized CAP format file, including: Reorganize the compilation step, which includes: Optimize C code by running external simulation subroutine block functions; The optimized C code is reorganized and compiled according to the calling relationship of the CAP format file before conversion to obtain the machine code.
7. The Java Card virtual machine optimization method according to claim 6, characterized in that: The calling relationship of the CAP format file is the calling relationship between methods and classes followed by Java application development.
8. The Java Card virtual machine optimization method according to claim 1, characterized in that: After receiving the instruction sent by the card reader, the COS system determines whether the instruction is an application instruction. If so, the instruction is sent to the corresponding application on the Java card for processing. If not, the instruction is directly processed by the COS system.
9. The Java Card virtual machine optimization method according to claim 1, characterized in that: In response to the application instruction on the Java card, sequentially reading the Java application stored in the optimized CAP format file corresponding to the application instruction includes: After the virtual machine in the card reads a single data in the series of data generated after the application instruction is compiled, it determines whether the data is bytecode. If so, it first parses the bytecode according to the bytecode parsing process, and then executes the parsing code of the bytecode in sequence; otherwise, the data is machine code, and the machine code is directly executed; The above steps are executed repeatedly until the application instruction is executed.
10. A system for optimizing a Java card virtual machine, characterized in that: The system executes the method according to any one of claims 1 to 9, and the system comprises: The off-card virtual machine is used to convert the CAP format file of the Java application into an optimized CAP format file, wherein the optimized CAP format file is an optimized CAP format file composed of machine code and byte code or an optimized CAP format file composed of pure machine code; The virtual machine in the card is used to respond to the application instructions on the Java card and sequentially read the Java application stored in the optimized CAP format file corresponding to the application instructions.