Method for managing Java Card converted applet files and storage system

Abstract

A method for managing Java Card CAP file data (converted applet) is provided. The method may comprise: during loading and / or linking of the CAP file, resolving a plurality of original references provided in a constant pool component of the CAP file, each of the plurality of original references pointing to a package element of a plurality of package elements of the CAP file, and generating a plurality of new references, each of the new references replacing a corresponding one of the plurality of original references, each of the new references comprising an index to a physical address in a pointer table of the CAP file and offset information representing an offset of the respective element with respect to a reference position.

Description

Technical area

[0001] Various embodiments generally relate to a method for managing Java Card Converted Applet (CAP) file data and a storage system. background

[0002] According to the Java Card™ Virtual Machine (JCVM) specification, at least some package elements, which may be contained, for example, in a Java Card Converted Applet (CAP) file, are typically resolved dynamically, which can be costly in terms of performance.

[0003] Previous countermeasures include, for example, resolving the package elements and replacing element references (e.g., tokens / offsets) with their physical pointers during loading (e.g., the CAP file). For example, a four-byte package element info in the constant pool component and class ref info in the other components of the CAP file can be replaced with a four-byte physical address of the respective package element.

[0004] However, a memory defragmentation process that also covers the Java heap can cause objects to be relocated within the heap. In this case, physical pointers stored in the constant pool and other CAP components would no longer be valid.

[0005] Since CAP link information in the constant pool was modified by the physical pointers during the initial link process, relinking of package elements after memory defragmentation is not possible in this context.

[0006] Optional relinking can be enabled by keeping the original CAP file information in the constant pool in memory, where it is stored. However, this would consume a lot of heap memory. Brief description

[0007] A method for managing Java Card CAP file data (converted applet) is provided. The method may comprise: during loading and / or linking of the CAP file, resolving a plurality of original references provided in a constant pool component of the CAP file, each of the plurality of original references pointing to a package element of a plurality of package elements of the CAP file, and generating a plurality of new references, each of the new references replacing a corresponding one of the plurality of original references, each of the new references comprising an index to a physical address in a pointer table of the CAP file and offset information representing an offset of the respective element with respect to a reference position. Brief description of the drawings

[0008] In the drawings, like reference characters generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed generally upon illustrating the principles of the invention. In the following description, various embodiments of the invention are described with reference to the following drawings. In the drawings: Fig. 1 is a flowchart of a method for managing Java Card CAP file data (Converted Applet) according to various embodiments; Fig. 2 schematically shows a management of Java Card CAP file data (Converted Applet) in the prior art; Fig. 3 schematically shows a management of Java Card CAP file data (Converted Applet) in the prior art; Fig. 4 schematically shows a management of Java Card CAP file data (Converted Applet) according to various embodiments; and Fig. 5 shows managing Java Card CAP file data (Converted Applet) according to various embodiments; Description

[0009] The following detailed description refers to the accompanying drawings which show, by way of illustration, specific details and embodiments in which the invention may be practiced.

[0010] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" should not necessarily be construed as preferred or advantageous over other embodiments or designs.

[0011] Various aspects of the disclosure are provided for devices, and various aspects of the disclosure are provided for methods. It is understood that basic properties of the devices also apply to the methods, and vice versa. Therefore, for the sake of brevity, a repeated description of such properties may be omitted.

[0012] Java Card™ is a technology that can be used to develop applications (payment, ID, etc.) for smart cards. After compiling a Java Card applet, a CAP (Converted Applet) file is generated, which is a binary representation of the applet.

[0013] A Java Card CAP file can consist of a set of components. Each component can describe a set of elements in the defined application or library, or an aspect of the CAP file. A complete CAP file must contain all required components and may also contain optional components.

[0014] Each component can be structured as multiple elements. Consecutive elements are stored sequentially without padding or alignment. CAP file data can be addressed and retrieved element by element.

[0015] Components of the package that can be included in the CAP file would be, for example, header, class, method, static field, and so on.

[0016] As an example, the header component may have a structure that includes tag, size, magic, CAP_Format_minor_version, CAP_Format_major_version, flags, package, and package_name of the elements.

[0017] While executing bytecode, the virtual machine can dynamically resolve references by creating links between components or with external packages.

[0018] Fig. Figure 2 shows such a dynamic resolution of references as a prior art method for handling data from a CAP file 202. A corresponding algorithm can essentially function as follows: 1. Fetch the four-byte entry 206 from the constant pool 204 at the specified index. 2. Extract the two-byte reference info from entry 206. 3. Check if the item belongs to the same package: a. Use the two-byte reference as an offset to access the field from the component. b. Return the value of the accessed field. 4. Otherwise: a. Extract the package token from the reference info. b. Find the external package using the package token. c. Extract the class token from entry 206. d. Obtain the external class using the class token in the external package. e. Extract the token of the package element (class, method, fields, etc.) from entry 206. f. Retrieve the package element offset using the package element token in the external class. g. Using the offset to access the package element from the external component. h. Return the value of the accessed package element.

[0019] This process can take time, especially if the requested item is not part of the same package, and may therefore negatively impact performance.

[0020] By linking and resolving referenced elements during the loading of the CAP file 202, the virtual machine can become more powerful. As briefly explained above, linking package elements using their physical addresses is an outdated solution, which is schematically described in Fig. 3 is shown.

[0021] Package elements can be resolved and element references (tokens / offsets) 206 replaced by their physical pointers 330 while the CAP file 202 is loaded.

[0022] A corresponding algorithm can be much faster than that in the context of Fig. 2 described above. The algorithm can be as follows: 1. Fetch the four-byte entry 330 from the constant pool 204 (physical address of an element) at the specified index. 2. b. Return the accessed field value.

[0023] However, this technique can cause problems when memory defragmentation is offered as a feature of a product. In particular, after defragmenting the Java heap 208, the CAP file 202 may be relocated within the memory address space. Thus, any pointers 330 or references to their previous location stored in the components of the CAP file 202 become invalid.

[0024] An automatic relinking of CAP 202 is also not possible, since during the first linking process either the original links 206 were modified (e.g. overwritten; overwriting is in Fig. 3 is not reproduced - the original links 206 would be overwritten by the pointers 330).

[0025] If relinking is to be enabled, the original information of the CAP file 202 must be retained by storing it in memory, e.g., the Java heap, which represents a footprint cost.

[0026] Fig. 1 shows a flowchart 100 of a method for managing Java Card CAP file data (Converted Applet) according to various embodiments.

[0027] The method may comprise: during loading and / or linking of the CAP file (110), resolving a plurality of original references provided in a constant pool component of the CAP file, each of the plurality of original references being directed to a package element of a plurality of package elements of the CAP file (120), and generating a plurality of new references, each of the new references replacing a corresponding one of the plurality of original references, each of the new references comprising an index to a physical address in a pointer table of the CAP file and offset information representing an offset of the respective element with respect to a reference position (130).

[0028] In various embodiments, linking and resolving package elements using their relative offset within the component along with a heap object reference are used to resolve a pointer to the CAP file 202.

[0029] In various embodiments, a four-byte member info in the constant pool component and a class ref info in the other components of the CAP file can be replaced by a two-byte heap object reference and a two-byte member offset. During bytecode execution, the two-byte object reference can be used in combination with the two-byte member offset, which can be added to the CAP file pointer, to obtain a correspondence with the four-byte member info in the constant pool component and class ref info in the other components of the CAP file.

[0030] In various embodiments, while the Java Card CAP binary data is being loaded, it may be modified, for example, by replacing four-byte data in the constant pool component and two-byte class ref data in other components with a heap CAP object reference and an element offset.

[0031] In other words, package elements can be resolved and can replace element references (e.g., tokens / offsets) with a two-byte CAP object reference (e.g., an index to a physical address in a CAP file pointer table) and a two-byte element offset. The replacement can occur during loading and / or linking of the CAP file.

[0032] This measure solves prior art problems such as the invalidity of absolute physical pointers and the additional memory footprint, since a physical location of the CAP file is updated after defragmentation and an offset indicating a relative position of the element within the CAP file remains valid after defragmentation.

[0033] In various embodiments, a performance improvement, for example, of about 150%, may be obtained (for example, compared to dynamic resolution), as well as automatic relinking of the CAP file after defragmentation.

[0034] Fig. 4 schematically shows a management of Java Card CAP file data (Converted Applet) 202 according to various embodiments; and The lower part in Fig. 4 shows an example of how the class component can be structured.

[0035] The package elements 206 (e.g., element references (tokens / offsets)) can be replaced with a new reference 440, for example, a two-byte CAP object reference 442 and a two-byte element offset 444, while the CAP file 202 is being loaded and / or linked. The CAP object reference 442 contains two-byte data that indexes into the pointer table. The table contains addresses of the Java objects, CAP files, etc.

[0036] Both the original package elements 206 and the new reference 440 can be located in the constant pool component 204.

[0037] The constant pool component 204 may contain an entry for each of the classes, methods, and fields referred to by elements in the method component of the CAP file 202.

[0038] The method for managing data of the CAP file 202 according to various embodiments may include, during loading and / or linking of the CAP file 202: resolving a plurality of original references 206 provided in a constant pool component 204 of the CAP file 202, wherein each of the plurality of original references 206 is directed to a package element of a plurality of package elements of the CAP file 202.

[0039] The original reference 206 may include, for example, a one-byte tag for identification, a two-byte reference that may specify, for example, an offset or a packet and class token, and a one-byte token that identifies the type of the packet element. The most significant bit of the packet token may indicate whether the identified element is part of the packet itself or part of an external packet.

[0040] For each original reference 206, this complete set of original reference information, including tracing and information extraction described above in connection with Fig. 2 and which are schematically shown for the external packages in Fig. 4 by extracting information from the class component 332 and into a new four-byte reference 440, two bytes for the index (the index is used to access the corresponding physical address of the CAP file in the pointer table and in Fig. 4 referred to as “object reference”) 442 and two bytes for the element offset 444.

[0041] Accordingly, the method may further include generating a plurality of new references 440, each of the new references 440 replacing a corresponding one of the plurality of original references 206, each of the new references 440 including an index 442 to a physical address in a pointer table of the CAP file 202 and offset information 444 representing an offset of the respective element relative to a reference position. The reference position may be, for example, the beginning of the CAP file 202 or any other suitable position.

[0042] The new references 440 may, in various embodiments, be a direct replacement for the original references 206. In other words, each of the new references 440 may have a size identical to an original size of each of the original references 206, optionally a size of four bytes, for example, two bytes for the index and two bytes for the offset.

[0043] A two-byte offset information 444, when used as a direct offset value, may only be suitable for references to elements of the CAP file 202 that have a maximum offset of approximately 64 KB. However, in some cases, the CAP file 202 may be larger than 64 KB.

[0044] If this possibility can exist, the method may further comprise determining a size of the CAP file 202.

[0045] If it is determined that the size of the CAP file 202 is less than or equal to 64 kB, it can be assumed that the offset information 444 corresponds to a value of an offset in bytes.

[0046] This calculation can optionally be performed during the first execution and saved for all elements.

[0047] If the size of the CAP file 202 is determined to be greater than 64 KB, the VM dynamically calculates the package element offset by adding the size of each component and the offset of the package element.

[0048] In other words, the sizes of elements with a lower element number up to the element immediately preceding the specified element are summed.

[0049] A corresponding algorithm can be as follows: 1. Fetch the four-byte entry 440 from the constant pool (two-byte object reference 442 for the redirection table and two-byte element offset 444) at the specified index. 2. Get the physical address of the CAP file 202 from the pointer table 446 at the specified index (object reference). 3. Physical address of an element = physical address of the CAP file 202 + offset 440 4. Return the field value being accessed.

[0050] Thus, various embodiments can solve all the problems described above for the legacy solution: After heap defragmentation, relinking of the CAP components is not required, since offsets 440 are still valid. This also applies to external elements.

[0051] Furthermore, there is no need to store the original information 206 of the CAP components for resolving elements, since the linking is still valid and does not need to be repeated after defragmentation. This allows the footprint of the CAP file 202 in the Java heap 208 to be kept small.

[0052] Fig. 5 schematically shows a storage system 500 according to various embodiments;

[0053] The storage system 500 may include a memory 520 configured to store a Java Card CAP file (Converted Applet) and a processor 510 configured to: during loading and / or linking of the CAP file: Resolving a plurality of original references provided in a constant pool component of the CAP file, each of the plurality of original references being directed to a package element of a plurality of package elements of the CAP file; and Creating a plurality of new references, each of the new references replacing a corresponding one of the plurality of original references, each of the new references comprising an index to a physical address in a pointer table of the CAP file and offset information representing an offset of the respective element with respect to a reference position.

[0054] Various examples are illustrated below: Example 1 is a method for managing Java Card CAP file data (converted applet). The method may comprise, during loading and / or linking of the CAP file, resolving a plurality of original references provided in a constant pool component of the CAP file, each of the plurality of original references pointing to a package element of a plurality of package elements of the CAP file, and generating a plurality of new references, each of the new references replacing a corresponding one of the plurality of original references, each of the new references comprising an index to a physical address in a pointer table of the CAP file and offset information representing an offset of the respective element with respect to a reference position. In Example 2, the subject matter of Example 1 can optionally include each of the new references having a size identical to an original size of each of the original references, optionally a size of four bytes. In Example 3, the subject matter of Example 1 or 2 can optionally include that the index and the offset information each have a size of two bytes. In Example 4, the subject matter of any of Examples 1 to 3 can optionally further comprise: determining a size of the CAP file, wherein if it is determined that the size of the CAP file is less than or equal to 64 kB, the offset information corresponds to a value of an offset in bytes, and wherein if it is determined that the size of the CAP file is greater than 64 kB, the packet element offset is dynamically calculated by adding the size of each component and the offset of the packet element. In Example 5, the subject matter of Example 4 can optionally further comprise summing, for each element of the plurality of packaging elements, the sizes of elements having a lower element number, and storing, for each element of the plurality of packaging elements, the resulting sum. In Example 6, the subject matter of any of Examples 1 to 5 can optionally include wherein loading the CAP file comprises loading the CAP file into a memory of a smart card, and wherein the memory further stores a physical address of the CAP file in the memory that is updated when the CAP file is relocated. In Example 7, the subject matter of any of Examples 1 to 6 can optionally include each of the elements being part of an applet package or part of a library package. Example 8 is a storage system. The storage system may include a memory configured to store a Java Card CAP file (Converted Applet) and a processor configured to: during loading and / or linking of the CAP file: Resolving a plurality of original references provided in a constant pool component of the CAP file, each of the plurality of original references being directed to a package element of a plurality of package elements of the CAP file; and Creating a plurality of new references, each of the new references replacing a corresponding one of the plurality of original references, each of the new references comprising an index to a physical address in a pointer table of the CAP file and offset information representing an offset of the respective element with respect to a reference position. In Example 9, the subject matter of Example 8 can optionally include each of the new references having a size identical to an original size of each of the original references, optionally a size of four bytes. In Example 10, the subject matter of Example 8 or 9 can optionally include that the index and the offset information each have a size of two bytes. In Example 11, the subject matter of any of Examples 8 to 10 can optionally further include the processor being further configured to determine a size of the CAP file, wherein, if it is determined that the size of the CAP file is less than or equal to 64 kB, the offset information corresponds to a value of an offset in bytes, and wherein, if it is determined that the size of the CAP file is greater than 64 kB, the packet element offset is dynamically calculated by adding the size of each component and the offset of the packet element. In Example 12, the subject matter of Example 11 can optionally include the processor being further configured to sum, for each element of the plurality of elements, the sizes of elements having a lower element number, and store, for each element of the plurality of elements, the resulting sum. In Example 13, the subject matter of any of Examples 8 to 12 can optionally include the memory being a non-volatile memory of a smart card. In Example 14, the subject matter of Example 13 can optionally include the non-volatile memory being further configured to store a physical address of the CAP file in the memory that is updated when the CAP file is relocated. In Example 15, the subject matter of any of Examples 8 to 14 can optionally include each of the elements being part of an applet package or part of a library package. In Example 16, the subject matter of Examples 13 to 15 can optionally include the processor being inside or outside the chip card.

[0055] Although the invention has been particularly shown and described with reference to specific embodiments, it will be understood by one skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is accordingly indicated by the appended claims, and all changes which come within the meaning and range of equivalence of the claims are therefore intended to be embraced therein.

Claims

[1] A method for managing Java Card CAP file data (Converted Applet) is provided, the method comprising the following: during the loading and / or linking of the CAP file: Resolving multiple original references provided in a constant pool component of the CAP file, where each of the multiple original references is directed to a package element of multiple package elements of the CAP file; and Creating multiple new references, each of which replaces a corresponding one of the multiple original references, each of which includes an index to a physical address in a pointer table of the CAP file and offset information representing an offset of the respective element with respect to a reference position. [2] Method according to claim 1, wherein each of the new references has a size identical to an original size of each of the original references, optionally a size of four bytes. [3] Method according to claim 1 or 2, wherein the index and the offset information each have a size of two bytes. [4] Method according to any one of claims 1 to 3, further comprising: Determining the size of the CAP file; where, if it is determined that the size of the CAP file is less than or equal to 64 kB, the offset information corresponds to a value of an offset in bytes; and where, if it is determined that the size of the CAP file is greater than 64 kB, the package element offset is calculated dynamically by adding the size of each component and the offset of the package element. [5] The method of claim 4, further comprising: Sum up, for each of the multiple packaging elements, the sizes of elements with a lower element number; and Save, for each element of the multiple elements, the resulting sum. [6] Method according to any one of claims 1 to 5, where loading the CAP file includes loading the CAP file into the memory of a smart card; and the memory further stores a physical address of the CAP file in memory, which is updated when the CAP file is relocated. [7] Method according to any one of claims 1 to 6, wherein each of the elements is part of an applet package or part of a library package. [8] Storage system, including: a memory designed to store a Java Card CAP file (Converted Applet); and a processor designed for the following: when loading the CAP file into memory and / or when linking the CAP file: Resolving multiple original references provided in a constant pool component of the CAP file, where each of the multiple original references is directed to a package element of multiple package elements of the CAP file; and Creating multiple new references, each of which replaces a corresponding one of the multiple original references, each of which includes an index to a physical address in a pointer table of the CAP file and offset information representing an offset of the respective element with respect to a reference position. [9] Storage system according to claim 8, wherein each of the new references has a size identical to an original size of each of the original references, optionally a size of four bytes. [10] Storage system according to claim 8 or 9, wherein the index and the offset information each have a size of two bytes. [11] Storage system according to any one of claims 8 to 10, wherein the processor is further configured to Determining the size of the CAP file; where, if it is determined that the size of the CAP file is less than or equal to 64 kB, the offset information corresponds to a value of an offset in bytes; and where, if it is determined that the size of the CAP file is greater than 64 kB, the package element offset is dynamically calculated by adding the size of each component and the offset of the package element. [12] Storage system according to claim 11, wherein the processor is further configured to sum, for each element of the multiple packing elements, the sizes of elements having a lower element number; and to store the resulting sum for each element of the multiple packing elements. [13] Storage system according to any one of claims 8 to 12, wherein the storage is a non-volatile memory of a chip card. [14] Storage system according to one of claims 13, wherein the non-volatile memory is further configured to store a physical address of the CAP file in the memory which is updated when the CAP file is relocated. [15] Storage system according to any one of claims 8 to 14, wherein each of the elements is part of an applet package or part of a library package. [16] Storage system according to any one of claims 13 to 15, wherein the processor is located inside or outside the chip card.

Images