KR101054596B1 - Memory saving method using Java Card Migrator - Google Patents

Abstract

The present invention relates to a method for saving memory of a Java card, which is an IC card operating in Java.

The present invention, in the memory saving method using the Java Card Migrator,

Storing, in NAND Flash, the Java bytecode with a delimiter having the name of the method, for each package and class name of the Java bytecode; Calling a specific method while the virtual machine of the Javacard is performing any method; Storing recovery information related to any method currently being executed; Retrieving, by the interpreter, the entire byte code corresponding to the called specific method from the NAND Flash based on the name of a package and a class to which the specific method belongs; When the specific method is terminated, recovering the stored recovery information related to any of the methods, and performing the rest of the arbitrary methods.

By using the present invention as described above, it is possible to provide a method for saving memory by using a software module (migrator) for storing Java byte code in a NAND flash in a Java card.

 Java Card, Memory Relief, Migrator, NAND Flash, Methods

Description

Memory Reduction Method using Migrator for Java Card

The present invention relates to a method for saving memory of a Java card, which is an IC card operating in Java.

Java Card, an IC card that operates in Java, can add or delete applications after card issuance, so it is possible to add new services without issuing a new card, and to develop applications without relying on hardware. Widely used as such.

1 is an internal structure of a Java card, in which the Java Card Virtual Machine (VM) is responsible for interpreting and processing byte codes of a compiled Java framework.

So in order to play this role, the ROMizer has to make sure that the byte codes are in the code area in NOR Flash. In other words, the Java code of the Java framework must be transformed into a code and program structure that the VM can recognize, and the result of this process is ROMJava.c.

Also, Java code is mainly composed of packages, classes, methods, fields, etc., each of which defines components in structures such as AllClassblocks, AllMethods, AllFields.

However, since NOR Flash of Java Card that stores Java byte code is only 768 KB, and logical E2P area should be reserved in NOR Flash, the available NOR Flash is about 700 KB, so all USIM, GP, etc. There is not enough space to store more than 1MB of Java code that implements the feature.

In order to solve such physical difficulties, it is urgent to develop a module (software) that stores Java byte code that occupies more than 30% of Java code in NAND Flash.

SUMMARY OF THE INVENTION The present invention provides a method of saving memory by using a software module (migrator) for storing Java byte code in a NAND Flash in the Java card.

In order to achieve the above technical problem, the present invention provides a memory saving method using a Java Card Migrator,

Storing, in NAND Flash, the Java bytecode with a delimiter having the name of the method, for each package and class name of the Java bytecode; Calling a specific method while the virtual machine of the Javacard is performing any method; Storing recovery information related to any method currently being executed; Retrieving, by the interpreter, the entire byte code corresponding to the called specific method from the NAND Flash based on the name of a package and a class to which the specific method belongs; When the specific method is terminated, recovering the stored recovery information related to any of the methods, and performing the rest of the arbitrary methods.

By using the present invention as described above, it is possible to provide a method for saving memory by using a software module (migrator) for storing Java byte code in a NAND flash in a Java card.

Figure 2 compares the operation of the VM according to the present invention and the prior art.

As can be seen in Figure 2, in the present invention, a function such as a method finder (Method Finder), a thread switcher (Thread Switcher), a token status saver (Token Status Saver) is added.

The method finder is responsible for loading the byte code of a method located in NAND Flash into RAM or E2P in NOR Flash, and works when an arbitrary method is called from the byte code being executed.

The thread switcher is a module that reloads the context that was performed on an existing thread at the moment of thread switching, and based on this information, allows you to execute after the previous execution point. In this module, a number of functions stored in NAND Flash are used. The key is to remember exactly whether the first byte code is being executed.

The token state store is responsible for saving and restoring the state of register values currently executing in thread switching and method invocation situations.Instruction offsets, stack pointers, frames Pointer values such as points (frame pointers) are stored in variables that act as logical registers in the RAM area.

On the other hand, the Java Card runs a VM after booting, and mainly executes a Java application. While executing this application, various Java APIs are called and a library is used. This operation is precompiled from the point of view of the Java Card VM. This is a process of fetching, decoding, and executing the byte code.

In addition, the Java code written by the application developer is made of byte code defined in the virtual machine specification through a java compiler. These byte codes are physically stored in a structure called "All Code" in ROMJava.c.

And since the execution unit of Java code is a method, Java byte code is basically made by function unit. Therefore, unique functions are created for each package and class.In the All Code structure, the byte codes of functions are stored separately for each package and class.

When the migrator stores the byte code in any file of NAND Flash rather than ROMJava.c of NOR Flash, the name of the package and class separating the function stores the name of the physical file that stores the byte code of the method. Becomes

For example, if you have a class named "FormAuthenticator" under the package "org / mortbay / jetty / security", and there is a "authenticate" method among the functions that make up this class, then you can use the root of the NAND Flash web area. It has a folder structure according to package name under folder and subfolder code and creates a file named “FormAuthenticator.byte” under this folder. So, as shown in Figure 3, the file Root \ code \ org \ mortbay \ jetty \ security \ FormAuthenticator.byte has a corresponding method name [Method: authenticate (org.mortbay.jetty.Request), Method: valueUnbound (javax.servlet.http.HttpSessionBindingEvent The compiled bytecodes are stored with a delimiter with)].

As a result, the migrator of the present invention organizes the byte codes of the methods of each class into one file, and then performs the function of systematically organizing the file system according to the package folder structure. In order to operate Java Card's virtual machine normally, copy the Root folder, which is the result of the microphone, to the web area of NAND Flash before Java Card is issued.

Now, after the byte code of the method of each class is stored in the NAND Flash by using the microphone of the present invention as described in FIG. Let's do it.

First, the method of the prior art will be described.

Javacard's virtual machine executes Java methods at a specific point in time. Which function to call at any point is determined by information in the class's constant pool, or method index.

Methods are unique based on their package, class, and method signature (parameter type, count, return type, etc.), so information about the package name, class name, method signature, etc. is needed to determine any method. Do.

This information tells you the value of the NOR Flash address where the method's bytecodes are located. This address is then stored in the global_ip variable, which logically acts as a register.

An interpreter that interprets and executes bytecodes sequentially reads and executes the method's bytecodes based on the value of the ip (instruction pointer) register.

However, when applying the migrator of the present invention, the global_ip variable itself does not serve as a register. For actual execution, variable length variable is needed to fetch and store the full byte code of the method temporarily. The interpreter executes the byte code stored in this variable sequentially.

Thus, when the byte code of the methods of each class is stored in the NAND Flash as shown in FIG. If is called (S41), the byte code index and function information related to the method (A) currently being executed are stored in the thread stack (S42), and the entire byte code corresponding to the called function (method (B)) is stored. Based on the name of the package and class to which this method (B) belongs, it is loaded from NAND Flash (S43), and the interpreter executes sequentially.

When the function (method B) is terminated (S44), the stored byte code index and the function information are recovered (S45), and the rest of the method A is performed.

Next, compare the savings of the NOR Flash memory according to the present invention and the prior art.

In the implementation of the Java Card standard specification published by Sun Microsystems, the sum of the byte codes generated by Java programs through the Java compiler in PC environment, which is the actual test environment, is 142KB.

However, it is impossible to implement full specification in Java Card due to the problem of Java Card environment, which is the actual environment in which the program is run. Therefore, even if the necessary functions are left on the Java Card and the remaining functions are disabled, the sum of byte codes generated in this way Is 48KB.

In addition, if the above-mentioned E2P area is reserved and all functions such as USIM, GP, etc. are implemented, the conventional technology consequently requires more than 1MB of NOR Flash storage space, so that only 768KB of NOR Flash space can be stored. Lack.

However, when the migrator of the present invention is applied, these codes are stored in NAND Flash (256MB) instead of NOR Flash (768KB), thereby saving memory (NOR Flash) by the size of Java byte code stored in NAND Flash.

While the preferred embodiments of the present invention have been described above, it should be noted that the present invention is not limited to these embodiments, but various modifications and changes can be made without departing from the spirit of the present invention.

1 illustrates a framework of a typical Java card.

Figure 2 compares the configuration of the present invention and the prior art.

Figure 3 shows how the migrator of the present invention stores Java byte code in NAND Flash.

4 shows a method of switching a method in the present invention.

Claims (4)

delete In the memory saving method using the Java Card Migrator, Storing, in NAND Flash, the Java bytecode with a delimiter having the name of the method, for each package and class name of the Java bytecode; Calling a specific method while the virtual machine of the Javacard is performing any method; Storing recovery information related to any method currently being executed; Retrieving, by the interpreter, the entire byte code corresponding to the called specific method from the NAND Flash based on the name of a package and a class to which the specific method belongs; When the specific method ends, recovering the stored recovery information related to any of the methods, and performing the rest of the arbitrary methods; The step of storing the Java byte code, Memory saving method using the Java Card Migrator, characterized in that the Java byte code is stored as a file name of the class name under the folder of the package name. In the memory saving method using the Java Card Migrator, Storing, in NAND Flash, the Java bytecode with a delimiter having the name of the method, for each package and class name of the Java bytecode; Calling a specific method while the virtual machine of the Javacard is performing any method; Storing recovery information related to any method currently being executed; Retrieving, by the interpreter, the entire byte code corresponding to the called specific method from the NAND Flash based on the name of a package and a class to which the specific method belongs; When the specific method ends, recovering the stored recovery information related to any of the methods, and performing the rest of the arbitrary methods; The arbitrary method-related recovery information is a byte code index and function information, the memory saving method using the Java Card Migrator. In the memory saving method using the Java Card Migrator, Storing, in NAND Flash, the Java bytecode with a delimiter having the name of the method, for each package and class name of the Java bytecode; Calling a specific method while the virtual machine of the Javacard is performing any method; Storing recovery information related to any method currently being executed; Retrieving, by the interpreter, the entire byte code corresponding to the called specific method from the NAND Flash based on the name of a package and a class to which the specific method belongs; When the specific method ends, recovering the stored recovery information related to any of the methods, and performing the rest of the arbitrary methods; Sequential execution of the interpreter, And a variable length variable for patching the entire byte code and temporarily storing the variable byte code, wherein the interpreter sequentially loads and executes the interpreter.

Images