US20030229769A1 - Using short references to access program elements in a large address space - Google Patents
Using short references to access program elements in a large address space Download PDFInfo
- Publication number
- US20030229769A1 US20030229769A1 US10/165,160 US16516002A US2003229769A1 US 20030229769 A1 US20030229769 A1 US 20030229769A1 US 16516002 A US16516002 A US 16516002A US 2003229769 A1 US2003229769 A1 US 2003229769A1
- Authority
- US
- United States
- Prior art keywords
- address
- component
- desired element
- package
- global
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/0292—User address space allocation, e.g. contiguous or non contiguous base addressing using tables or multilevel address translation means
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/357—Cards having a plurality of specified features
- G06Q20/3576—Multiple memory zones on card
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
- G06F12/0615—Address space extension
- G06F12/0623—Address space extension for memory modules
Definitions
- the present invention relates to addressing mechanisms within computer systems. More specifically, the present invention relates to a method and an apparatus for using short references to access program elements in a large address space.
- Smart cards are used in a variety of applications to solve common security and identity needs. For example, smart cards have been integrated into credit cards, debit cards, corporate badges, and even cell phones.
- Smart card applications are beginning to access large amounts of data. For example, applications that use biometric data, digital certificates and GSM SIM cards must be able to access large amounts of application data, and these requirements are expected to grow ten-fold by the near future.
- 16-bit computer systems typically use segmentation strategies to access memory beyond 64 kilobytes. Segmentation requires complex memory management structures, which consume a large amount of space. This is a problem in memory-constrained devices, such as smart cards, where memory space is very scarce. Furthermore, segmentation requires pre-allocation of memory, which tends to cause fragmentation of the address space, which also results in memory space being used inefficiently.
- One embodiment of the present invention provides a system that accesses a desired element during execution of a program.
- the system receives a reference to the desired element.
- the system determines if the reference is an internal reference to a location in a local package that is currently executing, or an external reference to a location in an external package. If the reference is an external reference, the system uses an index component of the reference to lookup an address for the desired element in a global reference table. Next, the system uses the address to access the desired element. Note that the address retrieved from the global reference table is larger than the reference, which allows the address to access a larger address space than is possible to access with the reference alone.
- the system determines a base address of a component in which the desired element is located, and adds an offset of the reference to the base address to produce the address for the desired element.
- determining the base address of the component involves obtaining an identifier for the local package that is currently executing, and using the identifier to lookup an entry in a package location table, wherein the entry points to a component location table for the local package.
- the system examines the component location table to determine the base address of the component. Note that the system may examine an instruction preceding the reference to determine which component the desired element is located in.
- the system installs a new package by calculating element addresses for all exported references associated with the new package, and then adding the element addresses to the global reference table. Next, the system replaces all external references within the new package with references to entries in the global reference table, wherein the entries in the global reference table contain element addresses for the desired elements.
- determining if the reference is an internal reference or an external reference involves examining a reserved bit within the reference, wherein the reserved bit indicates whether the reference is an internal reference or an external reference.
- looking up the address for the desired element in the global reference table involves retrieving an absolute address for the desired element from the global reference table.
- looking up the address for the desired element in the global reference table involves retrieving a relative address for the desired element from the global reference table, wherein the relative address specifies an offset relative to a base address of a component containing the desired element.
- the desired element can include: a class record; a static field; or a method.
- the reference is 16 bits in size and the address retrieved from the global reference table is 32 bits in size.
- the global reference table is stored as a multi-level table so that the entire global reference table does not have to be allocated at once.
- a given package includes: a static field component containing static fields; a class component containing class records; a method component containing methods; an export component; and an import component.
- FIG. 1 illustrates a smart card in accordance with an embodiment of the present invention.
- FIG. 2 illustrates data structures involved in the addressing operations in accordance with an embodiment of the present invention.
- FIG. 3 illustrates a multi-level global reference table in accordance with an embodiment of the present invention.
- FIG. 4 illustrates two reference formats in accordance with an embodiment of the present invention.
- FIG. 5 is a flow chart illustrating the process of installing a package in accordance with an embodiment of the present invention.
- FIG. 6 is a flow chart illustrating the process of converting a reference into an address of a desired element in accordance with an embodiment of the present invention.
- FIG. 7 is a flow chart illustrating the process of converting an object reference into an object address in accordance with an embodiment of the present invention.
- a computer readable storage medium which may be any device or medium that can store code and/or data for use by a computer system.
- the transmission medium may include a communications network, such as the Internet.
- FIG. 1 illustrates a smart card 100 in accordance with an embodiment of the present invention.
- Smart card 100 can generally include any type of miniature computing device, such as may be located within identification cards, client loyalty cards, electronic wallets and cellular telephones.
- the present invention is not meant to be limited to smart cards, and can generally be applied to any type of computing device or computer system that stores objects in writeable non-volatile memory and/or volatile memory.
- Smart card 100 contains a computational engine 126 , which includes circuitry for performing computational operations. Smart card 100 also contains a number of different types of memory, including random access memory (RAM) 120 , electrically erasable programmable read-only memory (EEPROM) 122 and read-only memory (ROM) 124 .
- RAM 120 can include any type of volatile random access memory
- EEPROM 122 can include any type of writeable non-volatile memory, such as EEPROM, flash memory, or magnetic memory
- ROM 124 can include any type of read-only memory.
- RAM 120 is used to store various data items and data structures.
- RAM 120 can contain portions of objects 112 , 115 and 113 .
- objects 112 , 113 and 115 are “transient objects” that include a persistent portion stored in EEPROM 122 , and a transient portion stored in a RAM 120 .
- ROM 124 includes a virtual machine 108 , such as the JAVA virtual machine developed by SUN Microsystems, Inc. of Santa Clara, Calif. Note that applications written in a platform-independent programming language, such as the JAVA programming language, can be executed on virtual machine 108 .
- Virtual machine 108 includes a memory manager 109 that manages allocation and freeing of memory within smart card 100 .
- ROM 124 also contains a number of applications, 104 and 105 , which provide services for clients accessing smart card 100 .
- Other applications, such as application 106 can be located in EEPROM 122 .
- Further applications may be located in both ROM 124 and EEPROM 122 .
- ROM 124 also includes a card manager 102 , which contains code for managing the execution of applications on smart card 100 .
- a card manager 102 which contains code for managing the execution of applications on smart card 100 .
- Client 110 first communicates with card manager 102 (step A).
- Card manager 102 puts client 110 in contact with an application 104 (step B). This allows client 110 to communicate directly with application 104 (step C).
- step A the number of applications 104
- step A the number of the application 104
- step B This allows client 110 to communicate directly with application 104
- card manager 102 can also delete objects from memory.
- RAM 120 and EEPROM 122 contain a number of objects 112 - 116 , which are accessed by applications 104 - 105 . More specifically, application 104 accesses objects 112 , 115 and 116 , application 105 accesses objects 113 and 114 , and application 106 accesses object 114 .
- FIG. 2 illustrates various data structures involved in the addressing operations in accordance with an embodiment of the present invention. These data structures include package location table 202 , global reference table 212 and object manager 236 . During program execution, these data structures are operated on by an execution engine 200 that is part of virtual machine 108 illustrated in FIG. 1.
- FIG. 2 also illustrates a new package 224 , which is installed into the system by installer 222 .
- This installation process is described in more detail below with reference to FIG. 5.
- Package location table (PLT) 202 stores pointers to specific packages and is indexed by a package identifier. For example, the first entry in PLT 202 is associated with a specific package and points to a component location table (CLT) 204 for the specific package.
- Component location table 204 stores entries for components that make up the specific package.
- component location table 204 contains static field component entry 205 , class component entry 206 , method component entry 206 and export component entry 208 . Each of these entries contains a location (base address) for the component as well as the size of the component.
- static field component entry 205 contains a location 209 for the static field component as well as the size 210 of the static field component. Note that location 209 points to the base address of static field component which contains component data 211 . Also note that the import component is not tracked because the import component is eliminated after it is used during installation as is described below with reference to FIG. 5.
- GRT 212 contains pointers to program elements, such as class records, static fields and methods. Each entry in GRT 212 contains an address 214 of a program element and a package identifier 216 , which identifies the package to which the program element belongs. GRT 212 is used to convert short 16-bit external references into longer 32-bit addresses as is described below with reference to FIG. 6.
- Object manager 236 is a table that is used to convert object identifiers into object addresses as is described below with reference to FIG. 7.
- FIG. 3 illustrates a multi-level implementation of global reference table (GRT) 212 in accordance with an embodiment of the present invention.
- GRT 212 is divided into two or more levels of indirection, so that the entire table does not have to be allocated at once.
- the high-level table 304 is allocated the first time the card runs. Elements are subsequently allocated into the respective sub-tables.
- a new lower-level table is allocated, containing a specified number of entries, which initially are empty.
- a low-level table is emptied out due to deletion of all elements, it can be garbage-collected by the virtual machine.
- Each table is indexed by specific bits of the index reference.
- GRT 212 is divided into 3 levels: a high-level table 304 containing 8 entries (3 bits, indexed by bits 12 - 14 ), that are either empty or holding a reference into a second-level table.
- Each second-level table such as second-level table 306 , can hold 64 entries (6 bits, indexed by bits 6 - 11 of the reference index), wherein each entry is either empty or contains a reference to a third-level table.
- Each third-level table such as third-level table 308 , can hold 64 entries (6 bits, indexed by bits 0 - 5 of the index reference), and can contain the actual element addresses, or possibly empty entries with no element associated with them.
- This indexed design allows for fast access during execution because each index reference can be divided into its bit components that are used to quickly index the table and find the entry.
- the cost of finding the entry address is: one memory access per level, one shift right operation per level, one multiplication per level, and one addition per level.
- accesses require 12 operations. These operations are fast, and hence should not cause significant delays during program execution.
- FIG. 4 illustrates two reference formats in accordance with an embodiment of the present invention. As is illustrated in FIG. 4, if the high-order bit of a 16-bit reference is a zero, the remaining 15 bits specify an offset into a local package component. Otherwise, if the high-order bit is a one, the remaining 15 bits specify an index into global reference table 212 illustrated in FIG. 2. This index is used to retrieve the address of a desired element from global reference table 212 as is described below with reference to FIG. 6.
- smart card 100 is a JAVA CARD.
- the JAVA CARD application unit is referred to as a “package.”
- a package contains a set of classes, which could also act as library classes, and can also contain applets, each representing a unique card application.
- Each package is individually contained inside a Converted APplet (CAP) file—a portable binary format used to distribute JAVA CARD applications.
- CAP Converted APplet
- One or more package CAP files can be installed into a JAVA CARD device at a given time, wherein each package CAP file contains one or more applications.
- Packages can interact with each other—normally by performing API calls or by accessing classes, fields or methods defined on different packages.
- Code inside a given package uses references to access both internal and external elements. These references usually map to the memory address where the desired element is located. Note that a package can export its elements to make them available to other packages to link to.
- One embodiment of the present invention relies in the properties of JAVA CARD packages to overcome the 64-kilobyte memory limit for JAVA CARD.
- all internal references to packages are given as offsets, while external references are usually associated with tokens that must be mapped against external packages' export components for linking purposes.
- One embodiment of the present invention presumes references in the CAP file will remain 16 bits in size, in order to avoid conflict with existing CAP file structures. This embodiment establishes a mapping between the 16-bit references and the actual 32-bit addresses they represent. Note that the references themselves are structured to encode information on how to locate the element address they represent.
- the JAVA CARD virtual machine In order to convert such a reference into an address, the JAVA CARD virtual machine must first know which package it is executing. Once it has this information, it uses the package identifier to obtain a reference to a table containing the individual package's different component addresses. Depending on the bytecode, the lower 15 bits of the reference could be interpreted as an offset into the class, method or static field components of the package. The virtual machine then retrieves from the component table the base address of the component in question and adds the offset from the reference to the address obtained. This produces the memory address of the element desired, which might be at a memory space beyond 16-bit range (i.e. above 64 kilobytes of RAM).
- External references are more complicated to process.
- installer 222 revises all references to be exported. For each exported reference, installer 222 calculates the element address (which could be larger than 16 bits) and adds the element address to global reference table 212 . (Note that there can be a single global reference table for all elements, or one for each type of element: static fields, methods and classes.)
- the table structure returns a reference index to installer 222 .
- Installer 222 places this reference index inside the new package's export component. In doing so, the system replaces the referenced entry's package offset in the respective component with the returned reference index. In this way, a package is prepared so that other packages can be linked to it.
- each component size is limited to 32,768 bytes, a limit imposed by the CAP file format that cannot be expanded.
- this strategy guarantees that each package component will have up to 32,768 bytes for code individually.
- each package's static field, class, method and export component can be as long as 32,768 bytes each.
- each package component can grow up to 32,768 bytes, the addition of all components from all packages can well exceed 32,768 bytes, and even 65,536 bytes (64 kilobytes) in total, because the size of each individual component does not restrict the size of other components. Therefore, the above-described technique overcomes the 64-kilobyte addressing limit.
- the JAVA CARD virtual machine keeps track of the package where the current code is located. When a local reference is found, the virtual machine consults the local package's component location table to get the component base address and simply adds the offset component from the reference. When the JAVA CARD virtual machine encounters an external reference, it extracts the index component from the reference and uses it to access the respective global reference table. An address, which could be greater than 16 bits in size, is returned. The virtual machine then uses the returned address to access the desired element. In addition, for some bytecodes like checkcast, instanceof, and for all method calls across packages, the JAVA CARD virtual machine can obtain the package ID associated with the element, which is also stored in the global reference table.
- each package can create objects, which can be stored at any address, even higher than 64 kilobytes. Newly created objects are inserted into the object manager data structure, which stores their address (which could be 32 bits in length) and assigns each object a 16-bit reference. Such 16-bit references are stored into static fields or given as parameters for virtual or interface method calls.
- object manager table 236 in FIG. 2 is similar to global reference table 212 . It is merely specialized for objects with optimizations to aid in garbage collection.
- each entry has also a package ID associated with it makes it easier to remove entries from the table.
- two methods can be used: all table elements can be scanned and deleted entries marked, or the export component of the package to delete could be scanned for exported references, and such references marked in the table. Since the table is designed to use holes from deleted entries first, it is guaranteed that slots previously occupied by deleted references will be filled by new references when new packages are installed.
- FIG. 5 is a flow chart illustrating the process of installing a new package 224 into a smart card 100 in accordance with an embodiment of the present invention.
- the system starts by copying the CAP file containing the new package 224 into the smart card 100 (step 502 ).
- the system parses the various components of the new package 224 , including the class component and the method component (step 504 ).
- imported references are modified. This can involve retrieving the package ID and token ID for the imported reference from the import component of new package 224 .
- the system uses the package ID to locate the export component of the linking package.
- the system retrieves a global reference table index from the export component of the linking package (step 508 ).
- the system parses the export component of the new package (step 510 ). For each entry in the export component, the system resolves the address, adds the address and package ID into the global reference table, and replaces the value in the export component of new package 224 with the index of the address in global reference table 212 (step 512 ). This allows subsequent packages to link into the export component of new package 224 .
- FIG. 6 is a flow chart illustrating the process of converting an element reference into an element address in accordance with an embodiment of the present invention. The process starts by reading a reference (step 602 ) and then examining the high-order bit of the reference to determine whether the reference is imported or local (step 604 ).
- the system uses the index from the reference to lookup the address of the desired element in the global reference table 212 (step 616 ). The system uses this address to access the desired element (step 614 ).
- the system obtains an identifier for the local package that is currently executing (step 606 ). (This may involve examining the stack.) The system uses this identifier to lookup an entry in package location table 202 , which points to a component location table for the package (step 608 ).
- the system gets the base address of the component from the component location table (step 610 ). This may involve examining a preceding byte code instruction to determine which component the access is directed to.
- the system adds the offset to the base address to produce the address of the desired element (step 612 ). Note that this address can be larger than the original reference. The system then uses the address to access the desired element (step 614 ).
- FIG. 7 is a flow chart illustrating the process of converting an object reference into an object address in accordance with an embodiment of the present invention.
- the system starts by obtaining an object reference from the system stack (step 702 ).
- the system uses this object to reference and retrieve an entry from the object manager table 236 from FIG. 2 (step 704 ). If the object is a transient object, the system reads the object header to obtain the location of the object data step ( 706 ). The system then adds an element offset to the address of the object to get an address of an element within the object (step 708 ).
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- Software Systems (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
- 1. Field of the Invention
- The present invention relates to addressing mechanisms within computer systems. More specifically, the present invention relates to a method and an apparatus for using short references to access program elements in a large address space.
- 2. Related Art
- Dramatic advances in computer technology presently make it possible to integrate a significant amount of computing power onto “smart cards.” Smart cards are used in a variety of applications to solve common security and identity needs. For example, smart cards have been integrated into credit cards, debit cards, corporate badges, and even cell phones.
- In order to provide portability for smart card applications, some designers have begun to integrate virtual machines, such as the JAVA virtual machine, into smart cards. Smart cards containing a JAVA virtual machine are often referred to as “JAVA CARDS.” Integrating a virtual machine into a smart card enables the smart card execute a large number of platform-independent applications. Moreover, the associated development environment for the virtual machine can simplify the process of developing applications for smart cards.
- Smart card applications are beginning to access large amounts of data. For example, applications that use biometric data, digital certificates and GSM SIM cards must be able to access large amounts of application data, and these requirements are expected to grow ten-fold by the near future.
- Unfortunately, the JAVA CARD virtual machine was originally designed to support 16-bit addresses, which limits the virtual machine to accessing 64 kilobytes of memory, unless more sophisticated strategies are used. Hence, existing JAVA CARD systems are likely to be hindered by the lack of storage capacity as well as addressing limitations.
- 16-bit computer systems typically use segmentation strategies to access memory beyond 64 kilobytes. Segmentation requires complex memory management structures, which consume a large amount of space. This is a problem in memory-constrained devices, such as smart cards, where memory space is very scarce. Furthermore, segmentation requires pre-allocation of memory, which tends to cause fragmentation of the address space, which also results in memory space being used inefficiently.
- Hence, what is needed is a method and an apparatus that allows smart card applications to access a larger address space without the above-described disadvantages of segmentation.
- One embodiment of the present invention provides a system that accesses a desired element during execution of a program. During operation, the system receives a reference to the desired element. The system determines if the reference is an internal reference to a location in a local package that is currently executing, or an external reference to a location in an external package. If the reference is an external reference, the system uses an index component of the reference to lookup an address for the desired element in a global reference table. Next, the system uses the address to access the desired element. Note that the address retrieved from the global reference table is larger than the reference, which allows the address to access a larger address space than is possible to access with the reference alone.
- In a variation on this embodiment, if the reference is an internal reference, the system determines a base address of a component in which the desired element is located, and adds an offset of the reference to the base address to produce the address for the desired element.
- In a further variation, determining the base address of the component involves obtaining an identifier for the local package that is currently executing, and using the identifier to lookup an entry in a package location table, wherein the entry points to a component location table for the local package. Next, the system examines the component location table to determine the base address of the component. Note that the system may examine an instruction preceding the reference to determine which component the desired element is located in.
- In a variation on this embodiment, the system installs a new package by calculating element addresses for all exported references associated with the new package, and then adding the element addresses to the global reference table. Next, the system replaces all external references within the new package with references to entries in the global reference table, wherein the entries in the global reference table contain element addresses for the desired elements.
- In a variation on this embodiment, determining if the reference is an internal reference or an external reference involves examining a reserved bit within the reference, wherein the reserved bit indicates whether the reference is an internal reference or an external reference.
- In a variation on this embodiment, looking up the address for the desired element in the global reference table involves retrieving an absolute address for the desired element from the global reference table.
- In a variation on this embodiment, looking up the address for the desired element in the global reference table involves retrieving a relative address for the desired element from the global reference table, wherein the relative address specifies an offset relative to a base address of a component containing the desired element.
- In a variation on this embodiment, the desired element can include: a class record; a static field; or a method.
- In a variation on this embodiment, the reference is 16 bits in size and the address retrieved from the global reference table is 32 bits in size.
- In a variation on this embodiment, the global reference table is stored as a multi-level table so that the entire global reference table does not have to be allocated at once.
- In a variation on this embodiment, a given package includes: a static field component containing static fields; a class component containing class records; a method component containing methods; an export component; and an import component.
- FIG. 1 illustrates a smart card in accordance with an embodiment of the present invention.
- FIG. 2 illustrates data structures involved in the addressing operations in accordance with an embodiment of the present invention.
- FIG. 3 illustrates a multi-level global reference table in accordance with an embodiment of the present invention.
- FIG. 4 illustrates two reference formats in accordance with an embodiment of the present invention.
- FIG. 5 is a flow chart illustrating the process of installing a package in accordance with an embodiment of the present invention.
- FIG. 6 is a flow chart illustrating the process of converting a reference into an address of a desired element in accordance with an embodiment of the present invention.
- FIG. 7 is a flow chart illustrating the process of converting an object reference into an object address in accordance with an embodiment of the present invention.
- The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
- The data structures and code described in this detailed description are typically stored on a computer readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) and DVDs (digital versatile discs or digital video discs), and computer instruction signals embodied in a transmission medium (with or without a carrier wave upon which the signals are modulated). For example, the transmission medium may include a communications network, such as the Internet.
- Smart Card
- FIG. 1 illustrates a smart card100 in accordance with an embodiment of the present invention. Smart card 100 can generally include any type of miniature computing device, such as may be located within identification cards, client loyalty cards, electronic wallets and cellular telephones. However, note that the present invention is not meant to be limited to smart cards, and can generally be applied to any type of computing device or computer system that stores objects in writeable non-volatile memory and/or volatile memory.
- Smart card100 contains a
computational engine 126, which includes circuitry for performing computational operations. Smart card 100 also contains a number of different types of memory, including random access memory (RAM) 120, electrically erasable programmable read-only memory (EEPROM) 122 and read-only memory (ROM) 124. In general,RAM 120 can include any type of volatile random access memory; EEPROM 122 can include any type of writeable non-volatile memory, such as EEPROM, flash memory, or magnetic memory; andROM 124 can include any type of read-only memory. -
RAM 120 is used to store various data items and data structures. For example, as illustrated in FIG. 1,RAM 120 can contain portions ofobjects EEPROM 122, and a transient portion stored in aRAM 120. -
ROM 124 includes avirtual machine 108, such as the JAVA virtual machine developed by SUN Microsystems, Inc. of Santa Clara, Calif. Note that applications written in a platform-independent programming language, such as the JAVA programming language, can be executed onvirtual machine 108.Virtual machine 108 includes a memory manager 109 that manages allocation and freeing of memory within smart card 100. -
ROM 124 also contains a number of applications, 104 and 105, which provide services for clients accessing smart card 100. Other applications, such asapplication 106, can be located inEEPROM 122. Further applications (not illustrated) may be located in bothROM 124 andEEPROM 122. -
ROM 124 also includes acard manager 102, which contains code for managing the execution of applications on smart card 100. For example, suppose aclient 110 wishes to access a service provided by one of the applications 104-106 on smart card 100.Client 110 first communicates with card manager 102 (step A).Card manager 102 putsclient 110 in contact with an application 104 (step B). This allowsclient 110 to communicate directly with application 104 (step C). Note thatcard manager 102 can also delete objects from memory. -
RAM 120 andEEPROM 122 contain a number of objects 112-116, which are accessed by applications 104-105. More specifically,application 104 accessesobjects application 105 accessesobjects application 106 accessesobject 114. - Data Structures
- FIG. 2 illustrates various data structures involved in the addressing operations in accordance with an embodiment of the present invention. These data structures include package location table202, global reference table 212 and
object manager 236. During program execution, these data structures are operated on by an execution engine 200 that is part ofvirtual machine 108 illustrated in FIG. 1. - FIG. 2 also illustrates a
new package 224, which is installed into the system byinstaller 222. This installation process is described in more detail below with reference to FIG. 5. Package location table (PLT) 202 stores pointers to specific packages and is indexed by a package identifier. For example, the first entry inPLT 202 is associated with a specific package and points to a component location table (CLT) 204 for the specific package. Component location table 204 stores entries for components that make up the specific package. In particular, component location table 204 contains static field component entry 205, class component entry 206, method component entry 206 and export component entry 208. Each of these entries contains a location (base address) for the component as well as the size of the component. For example, static field component entry 205 contains alocation 209 for the static field component as well as thesize 210 of the static field component. Note thatlocation 209 points to the base address of static field component which containscomponent data 211. Also note that the import component is not tracked because the import component is eliminated after it is used during installation as is described below with reference to FIG. 5. - Global reference table (GRT)212 contains pointers to program elements, such as class records, static fields and methods. Each entry in
GRT 212 contains anaddress 214 of a program element and apackage identifier 216, which identifies the package to which the program element belongs.GRT 212 is used to convert short 16-bit external references into longer 32-bit addresses as is described below with reference to FIG. 6. -
Object manager 236 is a table that is used to convert object identifiers into object addresses as is described below with reference to FIG. 7. - Multi-Level Global Reference Table
- FIG. 3 illustrates a multi-level implementation of global reference table (GRT)212 in accordance with an embodiment of the present invention. In this embodiment,
GRT 212 is divided into two or more levels of indirection, so that the entire table does not have to be allocated at once. The high-level table 304 is allocated the first time the card runs. Elements are subsequently allocated into the respective sub-tables. - When new entries are added into
GRT 212, if a lower-level table already allocated exists with empty entries, the entries are added there first by looking for holes (from deleted entries) and then by appending new entries into the table. - When more entries are needed, a new lower-level table is allocated, containing a specified number of entries, which initially are empty. When a low-level table is emptied out due to deletion of all elements, it can be garbage-collected by the virtual machine. Each table is indexed by specific bits of the index reference. For example, in FIG. 3,
GRT 212 is divided into 3 levels: a high-level table 304 containing 8 entries (3 bits, indexed by bits 12-14), that are either empty or holding a reference into a second-level table. Each second-level table, such as second-level table 306, can hold 64 entries (6 bits, indexed by bits 6-11 of the reference index), wherein each entry is either empty or contains a reference to a third-level table. - Each third-level table, such as third-level table308, can hold 64 entries (6 bits, indexed by bits 0-5 of the index reference), and can contain the actual element addresses, or possibly empty entries with no element associated with them.
- This indexed design allows for fast access during execution because each index reference can be divided into its bit components that are used to quickly index the table and find the entry. The cost of finding the entry address is: one memory access per level, one shift right operation per level, one multiplication per level, and one addition per level. For the three-level table illustrated in FIG. 3, accesses require 12 operations. These operations are fast, and hence should not cause significant delays during program execution.
- Reference Formats
- FIG. 4 illustrates two reference formats in accordance with an embodiment of the present invention. As is illustrated in FIG. 4, if the high-order bit of a 16-bit reference is a zero, the remaining 15 bits specify an offset into a local package component. Otherwise, if the high-order bit is a one, the remaining 15 bits specify an index into global reference table212 illustrated in FIG. 2. This index is used to retrieve the address of a desired element from global reference table 212 as is described below with reference to FIG. 6.
- Address Conversion Process
- In one embodiment of the present invention, smart card100 is a JAVA CARD. The JAVA CARD application unit is referred to as a “package.” A package contains a set of classes, which could also act as library classes, and can also contain applets, each representing a unique card application. Each package is individually contained inside a Converted APplet (CAP) file—a portable binary format used to distribute JAVA CARD applications. One or more package CAP files can be installed into a JAVA CARD device at a given time, wherein each package CAP file contains one or more applications.
- Packages can interact with each other—normally by performing API calls or by accessing classes, fields or methods defined on different packages. Code inside a given package uses references to access both internal and external elements. These references usually map to the memory address where the desired element is located. Note that a package can export its elements to make them available to other packages to link to.
- One embodiment of the present invention relies in the properties of JAVA CARD packages to overcome the 64-kilobyte memory limit for JAVA CARD. When the package is stored in a CAP file, all internal references to packages are given as offsets, while external references are usually associated with tokens that must be mapped against external packages' export components for linking purposes.
- In prior JAVA CARD implementations, when a package is installed, all references—both external and internal—are resolved into 16-bit addresses. Hence, in prior implementations a package cannot address memory beyond 64 kilobytes. If the package were to be installed into a 32-bit smart card using a similar technique (where references are represented as 32-bit addresses), all references in the smart card would have to be recalculated, because the CAP file structure implicitly assumes a 16-bit architecture.
- One embodiment of the present invention presumes references in the CAP file will remain 16 bits in size, in order to avoid conflict with existing CAP file structures. This embodiment establishes a mapping between the 16-bit references and the actual 32-bit addresses they represent. Note that the references themselves are structured to encode information on how to locate the element address they represent.
- All references, upon installation, are modified by the
installer 222. Internal references within the package are largely left intact from the CAP file. The high-order bit (bit 15) is marked as “0,” while the 15 low-order bits (bits 0-14) encode the offset of the element within the component. Note that a component could be a method, a class, or a static field. The bytecode that precedes a reference determines how the reference is interpreted. - In order to convert such a reference into an address, the JAVA CARD virtual machine must first know which package it is executing. Once it has this information, it uses the package identifier to obtain a reference to a table containing the individual package's different component addresses. Depending on the bytecode, the lower 15 bits of the reference could be interpreted as an offset into the class, method or static field components of the package. The virtual machine then retrieves from the component table the base address of the component in question and adds the offset from the reference to the address obtained. This produces the memory address of the element desired, which might be at a memory space beyond 16-bit range (i.e. above 64 kilobytes of RAM).
- External references, on the other hand, are more complicated to process. During installation,
installer 222 revises all references to be exported. For each exported reference,installer 222 calculates the element address (which could be larger than 16 bits) and adds the element address to global reference table 212. (Note that there can be a single global reference table for all elements, or one for each type of element: static fields, methods and classes.) The table structure returns a reference index toinstaller 222.Installer 222 places this reference index inside the new package's export component. In doing so, the system replaces the referenced entry's package offset in the respective component with the returned reference index. In this way, a package is prepared so that other packages can be linked to it. - In a similar way, all the references that this package makes to other packages are resolved. When an external reference is found, the installer consults the new package's import component and locates the external package that the remote reference is referring to. The installer then goes to the external package's export component (which is already be installed in the card) and retrieves the index reference stored in the export component. Finally, the external reference is replaced by the index reference obtained. An index reference can be differentiated from a local reference, since the high-order bit (bit15) is set to “1,” while the lower 15 bits (bits 0-14) represent the index into global reference table 212. In addition to storing references, global reference table 212 also stores the package ID associated with the respective reference. Such entry can be used for complex bytecode execution (like checkcast, instanceof), virtual method calls (to find out new package ID of execution) or for package deletion purposes.
- Please note that when following the above strategy, the address space that can be used by each component size is limited to 32,768 bytes, a limit imposed by the CAP file format that cannot be expanded. However, this strategy guarantees that each package component will have up to 32,768 bytes for code individually. Hence, each package's static field, class, method and export component can be as long as 32,768 bytes each. However, since each package component can grow up to 32,768 bytes, the addition of all components from all packages can well exceed 32,768 bytes, and even 65,536 bytes (64 kilobytes) in total, because the size of each individual component does not restrict the size of other components. Therefore, the above-described technique overcomes the 64-kilobyte addressing limit.
- During bytecode execution, the JAVA CARD virtual machine keeps track of the package where the current code is located. When a local reference is found, the virtual machine consults the local package's component location table to get the component base address and simply adds the offset component from the reference. When the JAVA CARD virtual machine encounters an external reference, it extracts the index component from the reference and uses it to access the respective global reference table. An address, which could be greater than 16 bits in size, is returned. The virtual machine then uses the returned address to access the desired element. In addition, for some bytecodes like checkcast, instanceof, and for all method calls across packages, the JAVA CARD virtual machine can obtain the package ID associated with the element, which is also stored in the global reference table.
- Furthermore, each package can create objects, which can be stored at any address, even higher than 64 kilobytes. Newly created objects are inserted into the object manager data structure, which stores their address (which could be 32 bits in length) and assigns each object a 16-bit reference. Such 16-bit references are stored into static fields or given as parameters for virtual or interface method calls.
- Note that the structure of the object manager table236 in FIG. 2 is similar to global reference table 212. It is merely specialized for objects with optimizations to aid in garbage collection.
- For package deletion, the fact that each entry has also a package ID associated with it makes it easier to remove entries from the table. During the package deletion process, two methods can be used: all table elements can be scanned and deleted entries marked, or the export component of the package to delete could be scanned for exported references, and such references marked in the table. Since the table is designed to use holes from deleted entries first, it is guaranteed that slots previously occupied by deleted references will be filled by new references when new packages are installed.
- Note that by using the method above on a 16-bit JAVA CARD, a maximum of 32,767 exported elements of each type (objects, methods, static fields, classes) will be able to exist in the card. It is not be possible to have more elements of each type than the available number of index references, since each index reference must be unique inside the smart card.
- The different processes involved in the address resolution process are described in more detail below.
- Process of Installing a Package
- FIG. 5 is a flow chart illustrating the process of installing a
new package 224 into a smart card 100 in accordance with an embodiment of the present invention. The system starts by copying the CAP file containing thenew package 224 into the smart card 100 (step 502). Next, the system parses the various components of thenew package 224, including the class component and the method component (step 504). - During this process, the system leaves local references intact (step506).
- In contrast, imported references are modified. This can involve retrieving the package ID and token ID for the imported reference from the import component of
new package 224. Next, the system uses the package ID to locate the export component of the linking package. The system then retrieves a global reference table index from the export component of the linking package (step 508). - Next, the system parses the export component of the new package (step510). For each entry in the export component, the system resolves the address, adds the address and package ID into the global reference table, and replaces the value in the export component of
new package 224 with the index of the address in global reference table 212 (step 512). This allows subsequent packages to link into the export component ofnew package 224. - Process of Converting an Element Reference into an Element Address
- FIG. 6 is a flow chart illustrating the process of converting an element reference into an element address in accordance with an embodiment of the present invention. The process starts by reading a reference (step602) and then examining the high-order bit of the reference to determine whether the reference is imported or local (step 604).
- If the reference is imported, the system uses the index from the reference to lookup the address of the desired element in the global reference table212 (step 616). The system uses this address to access the desired element (step 614).
- If the reference is local at
step 606, the system obtains an identifier for the local package that is currently executing (step 606). (This may involve examining the stack.) The system uses this identifier to lookup an entry in package location table 202, which points to a component location table for the package (step 608). - Next, the system gets the base address of the component from the component location table (step610). This may involve examining a preceding byte code instruction to determine which component the access is directed to.
- Next, the system adds the offset to the base address to produce the address of the desired element (step612). Note that this address can be larger than the original reference. The system then uses the address to access the desired element (step 614).
- Process of Converting an Object Reference into an Object Address
- FIG. 7 is a flow chart illustrating the process of converting an object reference into an object address in accordance with an embodiment of the present invention. The system starts by obtaining an object reference from the system stack (step702). The system uses this object to reference and retrieve an entry from the object manager table 236 from FIG. 2 (step 704). If the object is a transient object, the system reads the object header to obtain the location of the object data step (706). The system then adds an element offset to the address of the object to get an address of an element within the object (step 708).
- The foregoing descriptions of embodiments of the present invention have been presented only for purposes of illustration and description. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.
Claims (37)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2003/011419 WO2003104974A2 (en) | 2002-06-07 | 2003-04-11 | Using short references to access program elements in a large address space |
AU2003226369A AU2003226369A1 (en) | 2002-06-07 | 2003-04-11 | Using short references to access program elements in a large address space |
EP03757249A EP1563374A2 (en) | 2002-06-07 | 2003-04-11 | Using short references to access program elements in a large address space |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US38685602P | 2002-06-07 | 2002-06-07 |
Publications (2)
Publication Number | Publication Date |
---|---|
US20030229769A1 true US20030229769A1 (en) | 2003-12-11 |
US6865659B2 US6865659B2 (en) | 2005-03-08 |
Family
ID=29712239
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/165,160 Expired - Lifetime US6865659B2 (en) | 2002-06-07 | 2002-06-07 | Using short references to access program elements in a large address space |
Country Status (1)
Country | Link |
---|---|
US (1) | US6865659B2 (en) |
Cited By (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040143827A1 (en) * | 2003-01-16 | 2004-07-22 | Sun Microsystems, Inc., A Delware Corporation | Linking of virtual methods |
US20040143641A1 (en) * | 2003-01-16 | 2004-07-22 | Sun Microsystems, Inc., A Delaware Corporation | System for communicating program data between a first device and a second device |
US20040143820A1 (en) * | 2003-01-16 | 2004-07-22 | Sun Microsystems, Inc., A Delaware Corporation | Optimized representation of data type information in program verification |
US20040143551A1 (en) * | 2003-01-16 | 2004-07-22 | Sun Microsystems, Inc., A Delaware Corporation | Signing program data payload sequence in program loading |
US20040143831A1 (en) * | 2003-01-16 | 2004-07-22 | Sun Microsystems, Inc., A Delaware Corporation | Ordering program data for loading on a device |
US20040154013A1 (en) * | 2003-01-16 | 2004-08-05 | Sun Microsystems, Inc., A Delaware Corporation | Using a digital fingerprint to commit loaded data in a device |
WO2005111952A1 (en) * | 2004-05-10 | 2005-11-24 | Giesecke & Devrient Gmbh | Data carrier with memory management |
US20060073478A1 (en) * | 2001-09-21 | 2006-04-06 | The Regents Of The University Of Michigan | Atlastin |
EP1650717A1 (en) * | 2004-10-21 | 2006-04-26 | Kabushiki Kaisha Toshiba | Portable electronic apparatus and method of updating application in portable electronic apparatus |
US20070033323A1 (en) * | 2005-08-03 | 2007-02-08 | Gorobets Sergey A | Interfacing systems operating through a logical address space and on a direct data file basis |
US20070094483A1 (en) * | 2005-10-26 | 2007-04-26 | James Wilson | Pipelined digital signal processor |
US20080010439A1 (en) * | 2005-10-26 | 2008-01-10 | Yosef Stein | Variable length decoder system and method |
US20080092151A1 (en) * | 2006-10-02 | 2008-04-17 | Transitive Limited | Method and apparatus for handling dynamically linked function calls with respect to program code conversion |
EP1941370A2 (en) * | 2005-10-26 | 2008-07-09 | Analog Devices, Inc. | Lookup table addressing system and method |
US7450420B2 (en) | 2005-08-03 | 2008-11-11 | Sandisk Corporation | Reclaiming data storage capacity in flash memories |
US20090089649A1 (en) * | 2007-09-27 | 2009-04-02 | James Wilson | Programmable compute unit with internal register and bit FIFO for executing Viterbi code |
US7529905B2 (en) | 2005-10-13 | 2009-05-05 | Sandisk Corporation | Method of storing transformed units of data in a memory system having fixed sized storage blocks |
US20090114111A1 (en) * | 2007-10-26 | 2009-05-07 | Andreas Heine | Explosive charge |
US7552271B2 (en) | 2005-08-03 | 2009-06-23 | Sandisk Corporation | Nonvolatile memory with block management |
US7558906B2 (en) | 2005-08-03 | 2009-07-07 | Sandisk Corporation | Methods of managing blocks in nonvolatile memory |
US7669003B2 (en) | 2005-08-03 | 2010-02-23 | Sandisk Corporation | Reprogrammable non-volatile memory systems with indexing of directly stored data files |
US7747837B2 (en) | 2005-12-21 | 2010-06-29 | Sandisk Corporation | Method and system for accessing non-volatile storage devices |
US7769978B2 (en) | 2005-12-21 | 2010-08-03 | Sandisk Corporation | Method and system for accessing non-volatile storage devices |
US7793068B2 (en) | 2005-12-21 | 2010-09-07 | Sandisk Corporation | Dual mode access for non-volatile storage devices |
US7814262B2 (en) | 2005-10-13 | 2010-10-12 | Sandisk Corporation | Memory system storing transformed units of data in fixed sized storage blocks |
US7877539B2 (en) | 2005-02-16 | 2011-01-25 | Sandisk Corporation | Direct data file storage in flash memories |
US7949845B2 (en) | 2005-08-03 | 2011-05-24 | Sandisk Corporation | Indexing of file data in reprogrammable non-volatile memories that directly store data files |
US7984233B2 (en) | 2005-02-16 | 2011-07-19 | Sandisk Corporation | Direct data file storage implementation techniques in flash memories |
US20110265186A1 (en) * | 2008-12-26 | 2011-10-27 | Sk Telecom Co., Ltd. | Method for protecting a software license, system for same, server, terminal, and computer-readable recording medium |
US8214583B2 (en) | 2005-02-16 | 2012-07-03 | Sandisk Technologies Inc. | Direct file data programming and deletion in flash memories |
US9104315B2 (en) | 2005-02-04 | 2015-08-11 | Sandisk Technologies Inc. | Systems and methods for a mass data storage system having a file-based interface to a host and a non-file-based interface to secondary storage |
US10783082B2 (en) | 2019-08-30 | 2020-09-22 | Alibaba Group Holding Limited | Deploying a smart contract |
FR3095054A1 (en) * | 2019-04-11 | 2020-10-16 | Idemia Identity & Security France | Managing a memory in an electronic device |
WO2021036174A1 (en) * | 2019-08-30 | 2021-03-04 | 创新先进技术有限公司 | Method and device for deploying and executing intelligent contract |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7634768B2 (en) * | 2005-02-17 | 2009-12-15 | Intel Corporation | Methods and apparatus to support mixed-mode execution within a single instruction set architecture process of a virtual machine |
US7627733B2 (en) * | 2005-08-03 | 2009-12-01 | Sandisk Corporation | Method and system for dual mode access for storage devices |
US7877540B2 (en) * | 2005-12-13 | 2011-01-25 | Sandisk Corporation | Logically-addressed file storage methods |
EP1936574A1 (en) * | 2006-12-01 | 2008-06-25 | Cassis International PTE Ltd. | CAP file for the personalisation of a Java application |
US9118686B2 (en) | 2011-09-06 | 2015-08-25 | Microsoft Technology Licensing, Llc | Per process networking capabilities |
US9773102B2 (en) | 2011-09-09 | 2017-09-26 | Microsoft Technology Licensing, Llc | Selective file access for applications |
US8990561B2 (en) | 2011-09-09 | 2015-03-24 | Microsoft Technology Licensing, Llc | Pervasive package identifiers |
US9800688B2 (en) | 2011-09-12 | 2017-10-24 | Microsoft Technology Licensing, Llc | Platform-enabled proximity service |
US10356204B2 (en) | 2012-12-13 | 2019-07-16 | Microsoft Technology Licensing, Llc | Application based hardware identifiers |
US9858247B2 (en) | 2013-05-20 | 2018-01-02 | Microsoft Technology Licensing, Llc | Runtime resolution of content references |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6047362A (en) * | 1994-06-30 | 2000-04-04 | Sun Microsystems, Inc. | Delayed removal of address mapping for terminated processes |
US6085296A (en) * | 1997-11-12 | 2000-07-04 | Digital Equipment Corporation | Sharing memory pages and page tables among computer processes |
US6098111A (en) * | 1996-03-05 | 2000-08-01 | Digital Vision Laboratories Corporation | Parallel distributed processing system and method of same |
US20020174318A1 (en) * | 1999-04-09 | 2002-11-21 | Dave Stuttard | Parallel data processing apparatus |
US20030066881A1 (en) * | 2001-10-10 | 2003-04-10 | Nokia Corporation | Method for presenting proprietary data on a SIM card |
US6766433B2 (en) * | 2001-09-21 | 2004-07-20 | Freescale Semiconductor, Inc. | System having user programmable addressing modes and method therefor |
-
2002
- 2002-06-07 US US10/165,160 patent/US6865659B2/en not_active Expired - Lifetime
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6047362A (en) * | 1994-06-30 | 2000-04-04 | Sun Microsystems, Inc. | Delayed removal of address mapping for terminated processes |
US6098111A (en) * | 1996-03-05 | 2000-08-01 | Digital Vision Laboratories Corporation | Parallel distributed processing system and method of same |
US6085296A (en) * | 1997-11-12 | 2000-07-04 | Digital Equipment Corporation | Sharing memory pages and page tables among computer processes |
US20020174318A1 (en) * | 1999-04-09 | 2002-11-21 | Dave Stuttard | Parallel data processing apparatus |
US6766433B2 (en) * | 2001-09-21 | 2004-07-20 | Freescale Semiconductor, Inc. | System having user programmable addressing modes and method therefor |
US20030066881A1 (en) * | 2001-10-10 | 2003-04-10 | Nokia Corporation | Method for presenting proprietary data on a SIM card |
Cited By (60)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060073478A1 (en) * | 2001-09-21 | 2006-04-06 | The Regents Of The University Of Michigan | Atlastin |
US20040143827A1 (en) * | 2003-01-16 | 2004-07-22 | Sun Microsystems, Inc., A Delware Corporation | Linking of virtual methods |
US20040143820A1 (en) * | 2003-01-16 | 2004-07-22 | Sun Microsystems, Inc., A Delaware Corporation | Optimized representation of data type information in program verification |
US20040143551A1 (en) * | 2003-01-16 | 2004-07-22 | Sun Microsystems, Inc., A Delaware Corporation | Signing program data payload sequence in program loading |
US20040143831A1 (en) * | 2003-01-16 | 2004-07-22 | Sun Microsystems, Inc., A Delaware Corporation | Ordering program data for loading on a device |
US20040154013A1 (en) * | 2003-01-16 | 2004-08-05 | Sun Microsystems, Inc., A Delaware Corporation | Using a digital fingerprint to commit loaded data in a device |
US7222331B2 (en) | 2003-01-16 | 2007-05-22 | Sun Microsystems, Inc. | Linking of virtual methods |
US7484095B2 (en) | 2003-01-16 | 2009-01-27 | Sun Microsystems, Inc. | System for communicating program data between a first device and a second device |
US20040143641A1 (en) * | 2003-01-16 | 2004-07-22 | Sun Microsystems, Inc., A Delaware Corporation | System for communicating program data between a first device and a second device |
US8121955B2 (en) | 2003-01-16 | 2012-02-21 | Oracle America, Inc. | Signing program data payload sequence in program loading |
US8473417B2 (en) | 2003-01-16 | 2013-06-25 | Oracle America, Inc. | Signing program data payload sequence in program loading |
US7165246B2 (en) * | 2003-01-16 | 2007-01-16 | Sun Microsystems, Inc. | Optimized representation of data type information in program verification |
US7281244B2 (en) | 2003-01-16 | 2007-10-09 | Sun Microsystems, Inc. | Using a digital fingerprint to commit loaded data in a device |
US7272830B2 (en) | 2003-01-16 | 2007-09-18 | Sun Microsystems, Inc. | Ordering program data for loading on a device |
WO2005111952A1 (en) * | 2004-05-10 | 2005-11-24 | Giesecke & Devrient Gmbh | Data carrier with memory management |
DE102004022907A1 (en) * | 2004-05-10 | 2005-12-01 | Giesecke & Devrient Gmbh | Storage management media |
US20060086785A1 (en) * | 2004-10-21 | 2006-04-27 | Kabushiki Kaisha Toshiba | Portable electronic apparatus and method of updating application in portable electronic apparatus |
EP1650717A1 (en) * | 2004-10-21 | 2006-04-26 | Kabushiki Kaisha Toshiba | Portable electronic apparatus and method of updating application in portable electronic apparatus |
US10055147B2 (en) | 2005-02-04 | 2018-08-21 | Sandisk Technologies Llc | Systems and methods for a mass data storage system having a file-based interface to a host and a non-file-based interface to secondary storage |
US10126959B2 (en) | 2005-02-04 | 2018-11-13 | Sandisk Technologies Llc | Systems and methods for a mass data storage system having a file-based interface to a host and a non-file-based interface to secondary storage |
US9104315B2 (en) | 2005-02-04 | 2015-08-11 | Sandisk Technologies Inc. | Systems and methods for a mass data storage system having a file-based interface to a host and a non-file-based interface to secondary storage |
US8214583B2 (en) | 2005-02-16 | 2012-07-03 | Sandisk Technologies Inc. | Direct file data programming and deletion in flash memories |
US7984233B2 (en) | 2005-02-16 | 2011-07-19 | Sandisk Corporation | Direct data file storage implementation techniques in flash memories |
US7877539B2 (en) | 2005-02-16 | 2011-01-25 | Sandisk Corporation | Direct data file storage in flash memories |
US7581057B2 (en) | 2005-08-03 | 2009-08-25 | Sandisk Corporation | Memory system with management of memory blocks that directly store data files |
US20070033323A1 (en) * | 2005-08-03 | 2007-02-08 | Gorobets Sergey A | Interfacing systems operating through a logical address space and on a direct data file basis |
US7552271B2 (en) | 2005-08-03 | 2009-06-23 | Sandisk Corporation | Nonvolatile memory with block management |
US7558906B2 (en) | 2005-08-03 | 2009-07-07 | Sandisk Corporation | Methods of managing blocks in nonvolatile memory |
US7558905B2 (en) | 2005-08-03 | 2009-07-07 | Sandisk Corporation | Reclaiming data storage capacity in flash memory systems |
US7669003B2 (en) | 2005-08-03 | 2010-02-23 | Sandisk Corporation | Reprogrammable non-volatile memory systems with indexing of directly stored data files |
US7450420B2 (en) | 2005-08-03 | 2008-11-11 | Sandisk Corporation | Reclaiming data storage capacity in flash memories |
US8055832B2 (en) | 2005-08-03 | 2011-11-08 | SanDisk Technologies, Inc. | Management of memory blocks that directly store data files |
US7480766B2 (en) | 2005-08-03 | 2009-01-20 | Sandisk Corporation | Interfacing systems operating through a logical address space and on a direct data file basis |
US7949845B2 (en) | 2005-08-03 | 2011-05-24 | Sandisk Corporation | Indexing of file data in reprogrammable non-volatile memories that directly store data files |
US7814262B2 (en) | 2005-10-13 | 2010-10-12 | Sandisk Corporation | Memory system storing transformed units of data in fixed sized storage blocks |
US7529905B2 (en) | 2005-10-13 | 2009-05-05 | Sandisk Corporation | Method of storing transformed units of data in a memory system having fixed sized storage blocks |
US8024551B2 (en) | 2005-10-26 | 2011-09-20 | Analog Devices, Inc. | Pipelined digital signal processor |
US20070094483A1 (en) * | 2005-10-26 | 2007-04-26 | James Wilson | Pipelined digital signal processor |
US8458445B2 (en) | 2005-10-26 | 2013-06-04 | Analog Devices Inc. | Compute units using local luts to reduce pipeline stalls |
US20080010439A1 (en) * | 2005-10-26 | 2008-01-10 | Yosef Stein | Variable length decoder system and method |
US7728744B2 (en) | 2005-10-26 | 2010-06-01 | Analog Devices, Inc. | Variable length decoder system and method |
EP1941370A2 (en) * | 2005-10-26 | 2008-07-09 | Analog Devices, Inc. | Lookup table addressing system and method |
US8285972B2 (en) | 2005-10-26 | 2012-10-09 | Analog Devices, Inc. | Lookup table addressing system and method |
EP1941370A4 (en) * | 2005-10-26 | 2009-04-15 | Analog Devices Inc | Lookup table addressing system and method |
US7793068B2 (en) | 2005-12-21 | 2010-09-07 | Sandisk Corporation | Dual mode access for non-volatile storage devices |
US7769978B2 (en) | 2005-12-21 | 2010-08-03 | Sandisk Corporation | Method and system for accessing non-volatile storage devices |
US7747837B2 (en) | 2005-12-21 | 2010-06-29 | Sandisk Corporation | Method and system for accessing non-volatile storage devices |
US8209516B2 (en) | 2005-12-21 | 2012-06-26 | Sandisk Technologies Inc. | Method and system for dual mode access for storage devices |
US8468552B2 (en) * | 2006-10-02 | 2013-06-18 | International Business Machines Corporation | Handling dynamically linked function calls with respect to program code conversion |
US20080092151A1 (en) * | 2006-10-02 | 2008-04-17 | Transitive Limited | Method and apparatus for handling dynamically linked function calls with respect to program code conversion |
US9043816B2 (en) | 2006-10-02 | 2015-05-26 | International Business Machines Corporation | Handling dynamically linked function calls with respect to program code conversion |
US8301990B2 (en) | 2007-09-27 | 2012-10-30 | Analog Devices, Inc. | Programmable compute unit with internal register and bit FIFO for executing Viterbi code |
US20090089649A1 (en) * | 2007-09-27 | 2009-04-02 | James Wilson | Programmable compute unit with internal register and bit FIFO for executing Viterbi code |
US20090114111A1 (en) * | 2007-10-26 | 2009-05-07 | Andreas Heine | Explosive charge |
US20110265186A1 (en) * | 2008-12-26 | 2011-10-27 | Sk Telecom Co., Ltd. | Method for protecting a software license, system for same, server, terminal, and computer-readable recording medium |
FR3095054A1 (en) * | 2019-04-11 | 2020-10-16 | Idemia Identity & Security France | Managing a memory in an electronic device |
US10783082B2 (en) | 2019-08-30 | 2020-09-22 | Alibaba Group Holding Limited | Deploying a smart contract |
WO2021036174A1 (en) * | 2019-08-30 | 2021-03-04 | 创新先进技术有限公司 | Method and device for deploying and executing intelligent contract |
US11010303B2 (en) | 2019-08-30 | 2021-05-18 | Advanced New Technologies Co., Ltd. | Deploying a smart contract |
US11307990B2 (en) | 2019-08-30 | 2022-04-19 | Advanced New Technologies Co., Ltd. | Deploying a smart contract |
Also Published As
Publication number | Publication date |
---|---|
US6865659B2 (en) | 2005-03-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6865659B2 (en) | Using short references to access program elements in a large address space | |
US6928460B2 (en) | Method and apparatus for performing generational garbage collection in a segmented heap | |
US6766432B2 (en) | Memory management system supporting object deletion in non-volatile memory | |
US9400668B2 (en) | Computer program product containing instructions for providing a processor the capability of executing an application derived from a compiled form | |
US8521790B2 (en) | Increasing efficiency of data storage in a file system | |
JP3632598B2 (en) | Java runtime system with modified constant pool | |
US9141539B2 (en) | System and method for object deletion in persistent memory using bitmap windows | |
KR20000057005A (en) | Extended card file system | |
US7058785B1 (en) | Addressing objects in a large persistent storage address space | |
US20120259822A1 (en) | Method for compressing identifiers | |
CN116661910B (en) | Application calling method and device | |
US6738873B2 (en) | Memory management system supporting deletion of transient objects | |
US7228532B1 (en) | Method and apparatus to facilitate code verification and garbage collection in a platform-independent virtual machine | |
US6279148B1 (en) | Method and apparatus for supporting efficient programming in dynamic pointer-safe languages | |
US7028287B2 (en) | Method and apparatus for facilitating compact object headers | |
US6959309B2 (en) | Interface between programming languages and method therefor | |
US11995333B2 (en) | Method for reducing non-volatile memory fragmentation in integrated circuit cards, corresponding card and apparatus | |
EP1563374A2 (en) | Using short references to access program elements in a large address space | |
US6735680B2 (en) | Method and apparatus for deleting objects from memory within a smart card | |
CN116225332A (en) | Storage management method, storage device and embedded chip | |
CN113760193A (en) | Data reading and writing method and device for resource-limited device and instruction set | |
US6889303B2 (en) | Method and apparatus for distinguishing reachable objects and non-reachable objects in an object-based application | |
CN116382785B (en) | Method and device for data processing, computing equipment and storage medium | |
WO2003001371A2 (en) | Storing and retrieving of field descriptors in java computing environments | |
US7246347B1 (en) | Method and apparatus for loading class files into non-volatile memory |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SUN MICROSYSTEMS, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MONTEMAYOR, OSCAR A.;REEL/FRAME:012990/0879 Effective date: 20020606 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
AS | Assignment |
Owner name: ORACLE AMERICA, INC., CALIFORNIA Free format text: MERGER AND CHANGE OF NAME;ASSIGNORS:ORACLE USA, INC.;SUN MICROSYSTEMS, INC.;ORACLE AMERICA, INC.;REEL/FRAME:037278/0877 Effective date: 20100212 |
|
FPAY | Fee payment |
Year of fee payment: 12 |