CA2267477C - Packaging memory image files - Google Patents
Packaging memory image files Download PDFInfo
- Publication number
- CA2267477C CA2267477C CA002267477A CA2267477A CA2267477C CA 2267477 C CA2267477 C CA 2267477C CA 002267477 A CA002267477 A CA 002267477A CA 2267477 A CA2267477 A CA 2267477A CA 2267477 C CA2267477 C CA 2267477C
- Authority
- CA
- Canada
- Prior art keywords
- memory
- classes
- computer
- class
- objects
- 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.)
- Expired - Lifetime
Links
- 238000004806 packaging method and process Methods 0.000 title description 3
- 230000008859 change Effects 0.000 claims abstract description 6
- 238000000034 method Methods 0.000 claims description 56
- 238000003860 storage Methods 0.000 claims description 3
- 230000006872 improvement Effects 0.000 claims description 2
- 238000007781 pre-processing Methods 0.000 claims description 2
- 238000004590 computer program Methods 0.000 claims 2
- 230000009467 reduction Effects 0.000 abstract description 2
- 230000008569 process Effects 0.000 description 12
- 230000008901 benefit Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- VREFGVBLTWBCJP-UHFFFAOYSA-N alprazolam Chemical compound C12=CC(Cl)=CC=C2N2C(C)=NN=C2CN=C1C1=CC=CC=C1 VREFGVBLTWBCJP-UHFFFAOYSA-N 0.000 description 1
- 230000003190 augmentative effect Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 101150087654 chrnd gene Proteins 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011946 reduction process Methods 0.000 description 1
Classifications
-
- 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/44568—Immediately runnable code
- G06F9/44573—Execute-in-place [XIP]
Abstract
In typical Java and other interpreted programming language environments, the code is stored in ROM in a semi-processed state, .class files containing byte codes. When the device is turned on, a virtual machine resolves references and links the .class file in RAM to permit desired applications to be run. In the invention, the .class files are further pre-processed to select the data which will not change or require updating. This data is packaged into memory image files containing internal data pre-linking this data. The memory image files are stored in ROM and are accessible from ROM by the virtual machine at runtime. Only elements that will be updated, such as the objects themselves, must be instantiated in RAM at runtime. This reduces the amount of RAM needed to run the application. In an environment with memory constraints, the reduction in RAM
requirements permits more RAM to be made available for application use.
requirements permits more RAM to be made available for application use.
Description
PACKAGING MEMORY IMAGE FILES
Field of the Invention The present invention is directed to the field of managing memory use in run time environments in interpreted programming language environments. In particular, the invention provides a structure for a file of one or more JavaTM' classes that can be stored and accessed at runtime from non-volatile memory such as read only memory (ROM).
Background of the Invention Portable devices, including cellular telephones, pagers and personal digital assistants (PDAs), are operated by embedded processing systems. Similar embedded systems are used in other types of devices, including automotive navigational systems found in the new generation of so called "smart"
cars and household electrical management systems for remotely controlling home lighting, alarm and other systems.
A feature of embedded systems, particularly in portable devices, is that the memory available is constrained, generally of the order of one to four megabytes. Further, the memory of a system is subdivided between read only memory (ROM) which can hold permanent data from which the volatile elements are constructed or instantiated in random access memory (RAM) at runtime. The ROM and RAM are fixed during manufacture of the device, although they may be augmented to a limited extent by the addition of PCMCIA cards.
Because of these memory constraints, embedded systems do not contain layers of software between a running application and the hardware components typically found in larger systems. Many embedded applications are designed to run on thin realtime operating systems or with only some interface code (a memory manager and graphics driver) directly on the hardware.
' Java is a trademark of Sun Microsystems, Inc.
Interpreted language environments, such as Java and Smalltalk, make good runtime operating systems. Typically, the code is stored in ROM in a semi-processed state, .class files containing byte codes. When the device is turned on, a virtual machine (VM) resolves references and links the .class file to permit desired applications to be run.
One problem with the conventional approach is that the copying of all runtime code to RAM reduces the amount of RAM available for application use. In an environment in which there are limitations on total memory, the assignment of increasingly large portions to RAM reduces the amount of RAM
available for application use.
A more general problem is that the time it takes to translate the semi-processed .class files to a runtime state delays start up of applications in the device when powering on.
Summary of the Invention It is therefore an object of the present invention to provide a means for a directly accessing data stored in ROM in order to be able to maximize the amount of memory available in devices, particularly those with constrained resources.
The invention provides the structure of the portion of data stored in ROM that permits it to be accessed at run time. This is accomplished by prelinking data elements and writing them to files that are stored in ROM. These files are then directly accessible in ROM by the virtual machine at run time.
The invention also provides a process for designing in advance those portions of an application that will change and those that won't, and building the application so that the portions that will not change are accessible directly from ROM at runtime.
One advantage of providing ROM-accessible files is that the RAM requirements for running applications can be reduced. More RAM memory, in a constrained memory environment, is available, thereby permitting more and/or more complex applications to be run on the device at the same time.
In maximizing ROM usage, a further object of the invention is to avoid sacrificing performance due to excessive indirection.
Another advantage realized by prelinking or prereferencing the .class files is that run time files are immediately available from ROM on powering up a device, effectively providing "instant on"
capability.
According to these and other objects, the present invention provides a system for use in an interpreted programming environment, in which files are pre-processed to a semi-processed state for linking and execution by a virtual machine at runtime on a target device. The improvement of the invention is a builder which is adapted to analyze the semi-processed files to select data that will not change, and to construct files to be run by the virtual machine from read-only memory on the target device including the selected data and internal pointers from the selected data.
The present invention also provides a data file adapted to be accessed by a virtual machine from read-only memory at runtime. The data file consists of class definitions and byte code data required to run an application, and internal pointers pre-linking the data.
Finally, the invention provides a method for constructing a memory image file for storage in read-only memory of a target device. A maximal set of objects is defined for inclusion in the image file.
The maximal set of objects is reduced to remove unused code. Each object of the reduced maximal set is converted to image format, and each image format is written to the memory image file.
Brief Description of the Drawings Embodiments of the invention will now be described in detail in association with the accompanying drawings, in which:
Figure 1 is a schematic view showing the operation of a convention Java virtual machine processing .class files;
Figure 2 is a schematic view, similar to Figure l, showing the packaging of .class files and the use of the packaged files by the virtual machine at run time, according to the invention; and Figures 3 through 5 are flow diagrams illustrating the process for determining the content of and building a ROM memory image file according to the invention, in which Figure 3 illustrates a method for determining the maximal set of classes to be included in the build, and Figures 4 and 5 (consisting of Figures SA through SD) illustrate a process for reducing the maximal set of classes to arrive at an optimal content for the ROM memory image file.
Detailed Description of the Preferred Embodiments As illustrated schematically in Figure 1 and discussed briefly above, a conventional Java virtual machine ("VM") 6 reads Java .class files 4 containing data in the form of byte codes. The .class files 4 are obtained from memory such as a disk 2. Where the system is embedded, the memory 2 storing the semi-processed .class files 4 is the device's ROM.
The .class file input to the Java virtual machine 6 may also be in some packaged form such as .jar or .zip files (not shown).
The Java virtual machine 6 processes the .class files 4 with its internal compiler and converts them to a runtime structure in RAM 8 containing all of the data and objects required to execute the application.
Referring now to Figure 2, in overview, a pre-processing tool called a memory image file builder ("builder") 14 takes .class files 12 from memory 10, determines what data will not change or require updating, such as class definitions and the byte codes themselves, and constructs ROM memory image files 16 (at times abbreviated to "image file") with internal pointers from the selected data.
Just as in the conventional Java virtual machine, the builder 14 can take as its .class file input .jar CA9-99-005 q.
or .zip files (not shown).
According to the preferred embodiment, the ROM memory image files 16 constructed by the builder contain information about the image itself used by a memory manager in the target device for downloading the files to ROM, and by a virtual machine for constructing components in RAM for running applications on the target device. This information includes:
1. A memory segment;
Field of the Invention The present invention is directed to the field of managing memory use in run time environments in interpreted programming language environments. In particular, the invention provides a structure for a file of one or more JavaTM' classes that can be stored and accessed at runtime from non-volatile memory such as read only memory (ROM).
Background of the Invention Portable devices, including cellular telephones, pagers and personal digital assistants (PDAs), are operated by embedded processing systems. Similar embedded systems are used in other types of devices, including automotive navigational systems found in the new generation of so called "smart"
cars and household electrical management systems for remotely controlling home lighting, alarm and other systems.
A feature of embedded systems, particularly in portable devices, is that the memory available is constrained, generally of the order of one to four megabytes. Further, the memory of a system is subdivided between read only memory (ROM) which can hold permanent data from which the volatile elements are constructed or instantiated in random access memory (RAM) at runtime. The ROM and RAM are fixed during manufacture of the device, although they may be augmented to a limited extent by the addition of PCMCIA cards.
Because of these memory constraints, embedded systems do not contain layers of software between a running application and the hardware components typically found in larger systems. Many embedded applications are designed to run on thin realtime operating systems or with only some interface code (a memory manager and graphics driver) directly on the hardware.
' Java is a trademark of Sun Microsystems, Inc.
Interpreted language environments, such as Java and Smalltalk, make good runtime operating systems. Typically, the code is stored in ROM in a semi-processed state, .class files containing byte codes. When the device is turned on, a virtual machine (VM) resolves references and links the .class file to permit desired applications to be run.
One problem with the conventional approach is that the copying of all runtime code to RAM reduces the amount of RAM available for application use. In an environment in which there are limitations on total memory, the assignment of increasingly large portions to RAM reduces the amount of RAM
available for application use.
A more general problem is that the time it takes to translate the semi-processed .class files to a runtime state delays start up of applications in the device when powering on.
Summary of the Invention It is therefore an object of the present invention to provide a means for a directly accessing data stored in ROM in order to be able to maximize the amount of memory available in devices, particularly those with constrained resources.
The invention provides the structure of the portion of data stored in ROM that permits it to be accessed at run time. This is accomplished by prelinking data elements and writing them to files that are stored in ROM. These files are then directly accessible in ROM by the virtual machine at run time.
The invention also provides a process for designing in advance those portions of an application that will change and those that won't, and building the application so that the portions that will not change are accessible directly from ROM at runtime.
One advantage of providing ROM-accessible files is that the RAM requirements for running applications can be reduced. More RAM memory, in a constrained memory environment, is available, thereby permitting more and/or more complex applications to be run on the device at the same time.
In maximizing ROM usage, a further object of the invention is to avoid sacrificing performance due to excessive indirection.
Another advantage realized by prelinking or prereferencing the .class files is that run time files are immediately available from ROM on powering up a device, effectively providing "instant on"
capability.
According to these and other objects, the present invention provides a system for use in an interpreted programming environment, in which files are pre-processed to a semi-processed state for linking and execution by a virtual machine at runtime on a target device. The improvement of the invention is a builder which is adapted to analyze the semi-processed files to select data that will not change, and to construct files to be run by the virtual machine from read-only memory on the target device including the selected data and internal pointers from the selected data.
The present invention also provides a data file adapted to be accessed by a virtual machine from read-only memory at runtime. The data file consists of class definitions and byte code data required to run an application, and internal pointers pre-linking the data.
Finally, the invention provides a method for constructing a memory image file for storage in read-only memory of a target device. A maximal set of objects is defined for inclusion in the image file.
The maximal set of objects is reduced to remove unused code. Each object of the reduced maximal set is converted to image format, and each image format is written to the memory image file.
Brief Description of the Drawings Embodiments of the invention will now be described in detail in association with the accompanying drawings, in which:
Figure 1 is a schematic view showing the operation of a convention Java virtual machine processing .class files;
Figure 2 is a schematic view, similar to Figure l, showing the packaging of .class files and the use of the packaged files by the virtual machine at run time, according to the invention; and Figures 3 through 5 are flow diagrams illustrating the process for determining the content of and building a ROM memory image file according to the invention, in which Figure 3 illustrates a method for determining the maximal set of classes to be included in the build, and Figures 4 and 5 (consisting of Figures SA through SD) illustrate a process for reducing the maximal set of classes to arrive at an optimal content for the ROM memory image file.
Detailed Description of the Preferred Embodiments As illustrated schematically in Figure 1 and discussed briefly above, a conventional Java virtual machine ("VM") 6 reads Java .class files 4 containing data in the form of byte codes. The .class files 4 are obtained from memory such as a disk 2. Where the system is embedded, the memory 2 storing the semi-processed .class files 4 is the device's ROM.
The .class file input to the Java virtual machine 6 may also be in some packaged form such as .jar or .zip files (not shown).
The Java virtual machine 6 processes the .class files 4 with its internal compiler and converts them to a runtime structure in RAM 8 containing all of the data and objects required to execute the application.
Referring now to Figure 2, in overview, a pre-processing tool called a memory image file builder ("builder") 14 takes .class files 12 from memory 10, determines what data will not change or require updating, such as class definitions and the byte codes themselves, and constructs ROM memory image files 16 (at times abbreviated to "image file") with internal pointers from the selected data.
Just as in the conventional Java virtual machine, the builder 14 can take as its .class file input .jar CA9-99-005 q.
or .zip files (not shown).
According to the preferred embodiment, the ROM memory image files 16 constructed by the builder contain information about the image itself used by a memory manager in the target device for downloading the files to ROM, and by a virtual machine for constructing components in RAM for running applications on the target device. This information includes:
1. A memory segment;
2. A list of virtual machine contexts or processes; and 3. A list of ROM and RAM memory segment descriptors which describe the content of the image file and provide direction for downloading the image file in the described segments to the target device.
A description of the download of memory image files (or application components) to ROM is found in a concurrently filed application titled "Loading and Unloading of Application Components" (IBM
docket no. CA9-99-004), which is commonly assigned, and which is incorporated herein by reference.
In addition to ROM image files 16, the memory image build creates, as it runs, statistics 18 of what was packaged and why, and a log 20 which indicates what the builder 14 did, what classes it read, what problems it found, what classes it wrote to the image format, etc.
In the preferred embodiment, all of the builder 14 activity takes place at a server remote from the target device 22.
The ROM memory image files 16 are then loaded into ROM 24 in the device 22. At run time, the Java VM 28 of the invention reads the image files for the running application in ROM 24, and constructs RAM classes pointing to the ROM files. The RAM classes contain material, such as the objects, that will be updated during program execution, for example through garbage collection (implicit memory management). Because it contains only select, changeable material, the portion of memory required for RAM will be much smaller than the portion used for ROM.
A memory image file contains definitions for one or more Java classes which are laid out contiguously in memory. The classes included in the memory image file are those required to construct an image or provided to find grouping of functionality in the target device, such as the basic system operations.
S
Figures 3, 4 and 5 are flow diagrams illustrating the steps for building an image file, according to the invention. The tool used to package the memory image file is the memory image file builder discussed above.
The first object of the builder is to determine the maximal set of classes, that is, the set of all objects which cannot be excluded from being built to the image format because they are referenced in some way. A preferred method is illustrated in Figure 3.
An initial set of objects which cannot be removed is determined. This initial set can be some initial set of Java .class files to be converted to image format specified by the user. In most cases, the initial maximal set can be determined by including the class containing the main( ) method of an application, since this will result in all needed classes being pulled in by the builder. However, Java native interface (JNI) code may reference other classes, and Java code may use reflection or Class.forNameQ to dynamically reference other classes. In these cases, the user will have to explicitly include these classes in the initial set of classes for the builder to process.
Beginning with the initial set of classes, including the class which contains the main() method for an application, the true maximal class set must be determined. This set is determined by examining the constant pool for each class. The constant pool is a table of structures accessed by the bytecodes by index. The constant pool is examined to find other CONSTANT Class references. These references point to other classes which must be added to the maximal set. This processing is recursive; that is, each class found via a reference to a CONSTANT Class entry in the constant pool will also be examined to find further class references.
Referring to Figure 3, a class is exttwacted from the set of classes to be axarnined (block 50). The extracted class is added to tl~e maximal class set (block 52). This class is analyzed by scanning its constant pool looking for CONSTAN~I._Class entries (block ~:~). The classes located by this analysis are added to the set of classes to be ~~xannined (block 56). This process is repeated until the set of classes to be examined is empty (block 58) and the true maximal class set has been captured.
Once the maximal set of classes has, been determined, an optional reduction step can be run. This step will remove unused classes, methods and Iields from the resulting image format.
The set of objects which can be removed is obtained by first determining what objects cannot be removed. Then the set of objects which can be removed is everything outside of the set of objects that cannot be removed.
The act of determining that an object: cannot be removed is referred to as 'marking it as referenced'.
In the preferred embodiment of the method, the process of marking objects as referenced begins with the application's main( 1 method. The. virtual machine may require certain classes, methods, or fields be present when it starts, and these must also be marked as referenced.
Lastly, there may be objects which are used dynamically such a~~ classes loaded via ret7ection or the C',lass.forName() method which also must be added to the initial li3t of objects to be marked as rc~terenced.
Referring to Figure 4, once the initial list of objects to mark as referenced is determined (block 100), marking frcrther objects as referenced is determined by examining each referenced object (blocks 102, 104) to determine whether it falls into one of t:he following categories:
a class (block 106), a field (block 108), a method (block 1 l Ci), a set of byte codes (block 112), ;~ constant string entry (block 114), a constant reference (l>l~:~ck 1 18), a r~>nstant naime_ and-type entry (block 124), an attribute of a method (block l 30), an exceptions attribute ofa method (block 134) or a constant value attribute of a field (block 138). All other attributes of classes, methods and fields are ignored.
Figure SA sets out the process where the referenced object is a class (from block 106 in Figure 4).
The superclass of the class is marked as referenced (block 200), along with any interface classes implemented by the class (block 202 j. The constant pool entry for this class and for its superclass are marked as referenced (blocks 204, 206). In addition, the following methods, if available, are marked as referenced <clinit> (blocks 208, 210);
finalize (blocks 212, '214);
clone; (blocks 216, 2 l8) write object (C>bject Output Stream) (blocks 220, 222); and readObject (ObjectInputStream) (blocks 224, 226).
Figure SB illustrates the process the referenced object is a field (from block 108 in Figure 4). The class it is defined in is marked as referenced (,block 230), the constant pool entry for this field's name is marked as referenced (block 232 j, the constant pool entry for this field's descriptor marked as referenced (block 234) and any attribi.ites of the field are marked as referenced (block f.36).
Figure SC illustrates the process when a method is marked as referenced (from block 110 in Figure 4). The class it is defined in is marked as referenced (block 240), the constant pool entry for this method's name is marked a.s referewced ( block 242 j. the constant pool entry for this method's descriptor marked as referenced (block 244) and attributes of the method are marked as referenced (block 246).
Figure SD illustrates the process when a set of byte codes are marked as referenced (from block 112 in Figure 4). Any constant pool item referenced in the byte code is marked as referenced (blocks 250, 252). For occurrences of the anethods "new", "anewarray", "checkcast", "instanceof' and "multinewarray", the referenced class is marked as ref~renceci (blocks 254, 256). For a "getfield", "getstatic",, "putfield" and "putstatic", the referenced field is marked as referenced (blocks 258, 260).
For invoke XXX, a method of invo<:ation, the referenced method is marked as referenced (blocks 262, 264).
Returning to Figure ~4, when a constant string entry (identified by CONSTANT
String in the environment of the preferred embodiment) is marked as referenced (block 114), its UTFB constant pool entry is marked as references! (block 116). A UTF structure in a .lava programming environment represents constant string value, acrd symbolic information such as names of classes, methods and fields used by both the bytecodes and the internal elements of the class structure.
When a constant reference (CONSfAN'I'--Field Ret%nrethodref7interface method ref) is marked as referenced (block 118), its class constant pcaol entry is marked as referenced (block 120), and its NameAnd~fype constant pool entry is marked a:. referenced (block 12'2).
When a CONSTANT Name and Type--entry is marked as referenced (block 124), its name constant pool entry is marked as referenced (block 126), and its descriptor constant pool entry is marked as referenced (block 128).
When a code attribute of a method is marked as referenced (block 130}ry its set of byte codes will be marked as referenced (block 132).
When an exceptions attribute of a method is marked as referenced (black 134), its constant pool entries for the exception class namos will be marked as revf'erence (block 13fi).
When a constant value attribute of a field is marked as reforence (block 138), its constant pool entries for the initial value will be marked as referenced (block 140).
Because the set of traversals is recursive, all required objects will eventually be referenced. For example, marking a class as referenced will causo its entire super class chain up to the class Object to be marked as referenced.
Walking the initial set of objects (classes, methods and fields) will end up marking a large set of base classes and application-specific classes as being referenced. However, due to the use of virtual CA9-99-005 ~) methods, this initial set of referenced objects does not usually capture all of the methods required to allow the application to run correctly.
For instance, the body of the metlood java.util.Vector.indexOt(Ubject,int0 invokes t:he method java.lang.Ubject.equals(Object). If the Java.util.Vector.irzdexOt(Ubject,int) method is marked as referenced, it is not enough to only include the method java.lang.Object.equals(Object) in the generated output, because some class may override this method. In fact, for this particular method, there are likely to be many classes which override the method. For virtual method processing, each referenced virtual method is checked to sec if' it has been overridden in airy of its referenced subclasses. If it has, these methods are also marked as referenced, potentially causing other classes, methods, and fields to be marked as r~efertnced. Processing of virtual methods runs repeatedly until it has run once with no additional items being marked as referenced (block 104).
Following the reduction process described above, the builder sequentially converts each class file to image format and writes it to a tile: (block 142).
There are two optimizations that the builder makes across all the classes being converted. The builder will only write one copy of unique strings t~> the unage tile. If this was not done, the string "javallanglObject", for instance, we>uld be written to the image multiple times. As a second optimization, the builder only writes cane copy of unique CONSTANT__NameAndType entries.
Although the preferred embodiment has been described in association with a specific platform and programming enviromnent, it will be. understood by those skilled in the art that modifications to this invention obvious to the person skilled in the art are intended to be covered by the appended claims.
CA9-99-OUS 1 O>
A description of the download of memory image files (or application components) to ROM is found in a concurrently filed application titled "Loading and Unloading of Application Components" (IBM
docket no. CA9-99-004), which is commonly assigned, and which is incorporated herein by reference.
In addition to ROM image files 16, the memory image build creates, as it runs, statistics 18 of what was packaged and why, and a log 20 which indicates what the builder 14 did, what classes it read, what problems it found, what classes it wrote to the image format, etc.
In the preferred embodiment, all of the builder 14 activity takes place at a server remote from the target device 22.
The ROM memory image files 16 are then loaded into ROM 24 in the device 22. At run time, the Java VM 28 of the invention reads the image files for the running application in ROM 24, and constructs RAM classes pointing to the ROM files. The RAM classes contain material, such as the objects, that will be updated during program execution, for example through garbage collection (implicit memory management). Because it contains only select, changeable material, the portion of memory required for RAM will be much smaller than the portion used for ROM.
A memory image file contains definitions for one or more Java classes which are laid out contiguously in memory. The classes included in the memory image file are those required to construct an image or provided to find grouping of functionality in the target device, such as the basic system operations.
S
Figures 3, 4 and 5 are flow diagrams illustrating the steps for building an image file, according to the invention. The tool used to package the memory image file is the memory image file builder discussed above.
The first object of the builder is to determine the maximal set of classes, that is, the set of all objects which cannot be excluded from being built to the image format because they are referenced in some way. A preferred method is illustrated in Figure 3.
An initial set of objects which cannot be removed is determined. This initial set can be some initial set of Java .class files to be converted to image format specified by the user. In most cases, the initial maximal set can be determined by including the class containing the main( ) method of an application, since this will result in all needed classes being pulled in by the builder. However, Java native interface (JNI) code may reference other classes, and Java code may use reflection or Class.forNameQ to dynamically reference other classes. In these cases, the user will have to explicitly include these classes in the initial set of classes for the builder to process.
Beginning with the initial set of classes, including the class which contains the main() method for an application, the true maximal class set must be determined. This set is determined by examining the constant pool for each class. The constant pool is a table of structures accessed by the bytecodes by index. The constant pool is examined to find other CONSTANT Class references. These references point to other classes which must be added to the maximal set. This processing is recursive; that is, each class found via a reference to a CONSTANT Class entry in the constant pool will also be examined to find further class references.
Referring to Figure 3, a class is exttwacted from the set of classes to be axarnined (block 50). The extracted class is added to tl~e maximal class set (block 52). This class is analyzed by scanning its constant pool looking for CONSTAN~I._Class entries (block ~:~). The classes located by this analysis are added to the set of classes to be ~~xannined (block 56). This process is repeated until the set of classes to be examined is empty (block 58) and the true maximal class set has been captured.
Once the maximal set of classes has, been determined, an optional reduction step can be run. This step will remove unused classes, methods and Iields from the resulting image format.
The set of objects which can be removed is obtained by first determining what objects cannot be removed. Then the set of objects which can be removed is everything outside of the set of objects that cannot be removed.
The act of determining that an object: cannot be removed is referred to as 'marking it as referenced'.
In the preferred embodiment of the method, the process of marking objects as referenced begins with the application's main( 1 method. The. virtual machine may require certain classes, methods, or fields be present when it starts, and these must also be marked as referenced.
Lastly, there may be objects which are used dynamically such a~~ classes loaded via ret7ection or the C',lass.forName() method which also must be added to the initial li3t of objects to be marked as rc~terenced.
Referring to Figure 4, once the initial list of objects to mark as referenced is determined (block 100), marking frcrther objects as referenced is determined by examining each referenced object (blocks 102, 104) to determine whether it falls into one of t:he following categories:
a class (block 106), a field (block 108), a method (block 1 l Ci), a set of byte codes (block 112), ;~ constant string entry (block 114), a constant reference (l>l~:~ck 1 18), a r~>nstant naime_ and-type entry (block 124), an attribute of a method (block l 30), an exceptions attribute ofa method (block 134) or a constant value attribute of a field (block 138). All other attributes of classes, methods and fields are ignored.
Figure SA sets out the process where the referenced object is a class (from block 106 in Figure 4).
The superclass of the class is marked as referenced (block 200), along with any interface classes implemented by the class (block 202 j. The constant pool entry for this class and for its superclass are marked as referenced (blocks 204, 206). In addition, the following methods, if available, are marked as referenced <clinit> (blocks 208, 210);
finalize (blocks 212, '214);
clone; (blocks 216, 2 l8) write object (C>bject Output Stream) (blocks 220, 222); and readObject (ObjectInputStream) (blocks 224, 226).
Figure SB illustrates the process the referenced object is a field (from block 108 in Figure 4). The class it is defined in is marked as referenced (,block 230), the constant pool entry for this field's name is marked as referenced (block 232 j, the constant pool entry for this field's descriptor marked as referenced (block 234) and any attribi.ites of the field are marked as referenced (block f.36).
Figure SC illustrates the process when a method is marked as referenced (from block 110 in Figure 4). The class it is defined in is marked as referenced (block 240), the constant pool entry for this method's name is marked a.s referewced ( block 242 j. the constant pool entry for this method's descriptor marked as referenced (block 244) and attributes of the method are marked as referenced (block 246).
Figure SD illustrates the process when a set of byte codes are marked as referenced (from block 112 in Figure 4). Any constant pool item referenced in the byte code is marked as referenced (blocks 250, 252). For occurrences of the anethods "new", "anewarray", "checkcast", "instanceof' and "multinewarray", the referenced class is marked as ref~renceci (blocks 254, 256). For a "getfield", "getstatic",, "putfield" and "putstatic", the referenced field is marked as referenced (blocks 258, 260).
For invoke XXX, a method of invo<:ation, the referenced method is marked as referenced (blocks 262, 264).
Returning to Figure ~4, when a constant string entry (identified by CONSTANT
String in the environment of the preferred embodiment) is marked as referenced (block 114), its UTFB constant pool entry is marked as references! (block 116). A UTF structure in a .lava programming environment represents constant string value, acrd symbolic information such as names of classes, methods and fields used by both the bytecodes and the internal elements of the class structure.
When a constant reference (CONSfAN'I'--Field Ret%nrethodref7interface method ref) is marked as referenced (block 118), its class constant pcaol entry is marked as referenced (block 120), and its NameAnd~fype constant pool entry is marked a:. referenced (block 12'2).
When a CONSTANT Name and Type--entry is marked as referenced (block 124), its name constant pool entry is marked as referenced (block 126), and its descriptor constant pool entry is marked as referenced (block 128).
When a code attribute of a method is marked as referenced (block 130}ry its set of byte codes will be marked as referenced (block 132).
When an exceptions attribute of a method is marked as referenced (black 134), its constant pool entries for the exception class namos will be marked as revf'erence (block 13fi).
When a constant value attribute of a field is marked as reforence (block 138), its constant pool entries for the initial value will be marked as referenced (block 140).
Because the set of traversals is recursive, all required objects will eventually be referenced. For example, marking a class as referenced will causo its entire super class chain up to the class Object to be marked as referenced.
Walking the initial set of objects (classes, methods and fields) will end up marking a large set of base classes and application-specific classes as being referenced. However, due to the use of virtual CA9-99-005 ~) methods, this initial set of referenced objects does not usually capture all of the methods required to allow the application to run correctly.
For instance, the body of the metlood java.util.Vector.indexOt(Ubject,int0 invokes t:he method java.lang.Ubject.equals(Object). If the Java.util.Vector.irzdexOt(Ubject,int) method is marked as referenced, it is not enough to only include the method java.lang.Object.equals(Object) in the generated output, because some class may override this method. In fact, for this particular method, there are likely to be many classes which override the method. For virtual method processing, each referenced virtual method is checked to sec if' it has been overridden in airy of its referenced subclasses. If it has, these methods are also marked as referenced, potentially causing other classes, methods, and fields to be marked as r~efertnced. Processing of virtual methods runs repeatedly until it has run once with no additional items being marked as referenced (block 104).
Following the reduction process described above, the builder sequentially converts each class file to image format and writes it to a tile: (block 142).
There are two optimizations that the builder makes across all the classes being converted. The builder will only write one copy of unique strings t~> the unage tile. If this was not done, the string "javallanglObject", for instance, we>uld be written to the image multiple times. As a second optimization, the builder only writes cane copy of unique CONSTANT__NameAndType entries.
Although the preferred embodiment has been described in association with a specific platform and programming enviromnent, it will be. understood by those skilled in the art that modifications to this invention obvious to the person skilled in the art are intended to be covered by the appended claims.
CA9-99-OUS 1 O>
Claims (13)
1. In an interpreted programming environment, a system in which files are pre-processed to a semi-processed state for linking and execution by a virtual machine at runtime on a target device, wherein the improvement comprises:
a pre-processing tool adapted to analyze the semi-processed files to select data that will not change, and to construct files to be run by the virtual machine from read-only memory on the target device including the selected data arid internal pointers from the selected data.
a pre-processing tool adapted to analyze the semi-processed files to select data that will not change, and to construct files to be run by the virtual machine from read-only memory on the target device including the selected data arid internal pointers from the selected data.
2. Computer-readable program code stored on computer readable medium comprising a data file adapted to be accessed by a virtual machine from read-only memory (ROM) at runtime, the data file comprising:
class definitions and byte code data required to run an application; and internal pointers pre-lining the data.
class definitions and byte code data required to run an application; and internal pointers pre-lining the data.
3. The computer readable program code according to claim 2, wherein the data file further comprises ROM and random access memory (RAM) segment descriptors providing direction for downloading the data file in segments to a target device.
4. The computer readable program code according to claim 2, wherein the data file further comprises:
a list of virtual machine contexts; and a list of ROM and random access memory (RAM) segment descriptors describing the data file content, said list being accessible by the virtual machine at runtime.
a list of virtual machine contexts; and a list of ROM and random access memory (RAM) segment descriptors describing the data file content, said list being accessible by the virtual machine at runtime.
5. A method for constructing a memory image file for storage in read-only memory (ROM) of a target device, comprising:
defining a maximal set of objects for inclusion in the image file;
reducing the maximal set of objects to remove unused code;
converting each object of the reduced maximal set to image format; and writing each image format to the memory image file.
defining a maximal set of objects for inclusion in the image file;
reducing the maximal set of objects to remove unused code;
converting each object of the reduced maximal set to image format; and writing each image format to the memory image file.
6. The method, according to claim 5, wherein the step of defining the maximal set of objects comprises:
i) adding a class containing a main~ method to the maximal set;
ii) examining references in classes in the maximal set to locate new classes;
iii) adding the located classes to the maximal set; and iv) repeating steps ii) and iii) until no new classes are located.
i) adding a class containing a main~ method to the maximal set;
ii) examining references in classes in the maximal set to locate new classes;
iii) adding the located classes to the maximal set; and iv) repeating steps ii) and iii) until no new classes are located.
7. The method, according to claim 5, wherein the step of defining the maximal set of objects comprises:
i) determining a set of classes to be examined:
ii) extracting a class from the set of classes to be examined;
iii) adding the extracted class to the maximal set of classes;
iv) analyzing the extracted class to locate references to other classes;
v) adding the located classes to the set of classes to be examined; and vi) repeating steps ii) through v) until the set of classes to be examined is empty.
i) determining a set of classes to be examined:
ii) extracting a class from the set of classes to be examined;
iii) adding the extracted class to the maximal set of classes;
iv) analyzing the extracted class to locate references to other classes;
v) adding the located classes to the set of classes to be examined; and vi) repeating steps ii) through v) until the set of classes to be examined is empty.
8. The method according to claim 5, wherein the step of reducing the maximal set of objects to remove unused code comprises:
examining each object in the maximal set to identify each referenced attribute;
determining whether the object depends on each referenced attribute for an application to run;
and if a dependency is found, adding the referenced attribute to the maximal set of objects, else, removing the referenced attribute from the maximal set of objects.
examining each object in the maximal set to identify each referenced attribute;
determining whether the object depends on each referenced attribute for an application to run;
and if a dependency is found, adding the referenced attribute to the maximal set of objects, else, removing the referenced attribute from the maximal set of objects.
9. The method, according to claim 5 wherein the step of writing each image format to the memory file comprises:
writing a single copy of unique strings to the image file.
writing a single copy of unique strings to the image file.
10. The method, according to claims 5 or 9, wherein the step of writing each image format to the memory file comprises:
writing a single copy of unique constant name and type entries to the image file.
writing a single copy of unique constant name and type entries to the image file.
11. A computer-readable memory for storing the instructions for use in the execution in a computer of any one of the methods of claims 5 to 10.
12. A computer program product comprising a computer usable medium having computer readable program code means embodied therein for causing a computer to construct a memory image file for storage in read-only memory (ROM) of a target device, the computer readable program code means in said computer program product comprising:
computer readable program code means for causing the computer, to define a maximal set of objects for inclusion in the image file;
computer readable program code means for causing the computer, to reduce the maximal set of objects to remove unused code;
computer readable program code means for causing the computer, to convert each object of the reduced maximal set to image format; and computer readable program code means for causing the computer, to write each image format to the memory image file.
computer readable program code means for causing the computer, to define a maximal set of objects for inclusion in the image file;
computer readable program code means for causing the computer, to reduce the maximal set of objects to remove unused code;
computer readable program code means for causing the computer, to convert each object of the reduced maximal set to image format; and computer readable program code means for causing the computer, to write each image format to the memory image file.
13
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002267477A CA2267477C (en) | 1999-03-30 | 1999-03-30 | Packaging memory image files |
| US09/374,154 US6446254B1 (en) | 1999-03-30 | 1999-08-13 | Packaging memory image files |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002267477A CA2267477C (en) | 1999-03-30 | 1999-03-30 | Packaging memory image files |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2267477A1 CA2267477A1 (en) | 2000-09-30 |
| CA2267477C true CA2267477C (en) | 2003-10-14 |
Family
ID=4163414
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002267477A Expired - Lifetime CA2267477C (en) | 1999-03-30 | 1999-03-30 | Packaging memory image files |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6446254B1 (en) |
| CA (1) | CA2267477C (en) |
Families Citing this family (37)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4118456B2 (en) * | 1999-06-29 | 2008-07-16 | 株式会社東芝 | Program language processing system, code optimization method, and machine-readable storage medium |
| US20010042241A1 (en) * | 2000-01-21 | 2001-11-15 | Fujitsu Limited | Apparatus and method for executing program using just-in time-compiler system |
| US6813762B1 (en) * | 2000-02-22 | 2004-11-02 | Freescale Semiconductor, Inc. | Method for processing program files in a programming language capable of dynamic loading |
| JP2001256058A (en) * | 2000-03-13 | 2001-09-21 | Omron Corp | Executing method of program by interpreter language and information processor using the same method |
| US20020087958A1 (en) * | 2000-04-20 | 2002-07-04 | International Business Machines Corporation | Method and apparatus of transforming a class |
| US7159223B1 (en) * | 2000-05-12 | 2007-01-02 | Zw Company, Llc | Methods and systems for applications to interact with hardware |
| JP2002091762A (en) * | 2000-09-14 | 2002-03-29 | Denso Corp | Program generator |
| US6996813B1 (en) | 2000-10-31 | 2006-02-07 | Sun Microsystems, Inc. | Frameworks for loading and execution of object-based programs |
| US7080373B2 (en) * | 2001-03-07 | 2006-07-18 | Freescale Semiconductor, Inc. | Method and device for creating and using pre-internalized program files |
| US7096466B2 (en) | 2001-03-26 | 2006-08-22 | Sun Microsystems, Inc. | Loading attribute for partial loading of class files into virtual machines |
| US7020874B2 (en) * | 2001-03-26 | 2006-03-28 | Sun Microsystems, Inc. | Techniques for loading class files into virtual machines |
| US7543288B2 (en) * | 2001-03-27 | 2009-06-02 | Sun Microsystems, Inc. | Reduced instruction set for Java virtual machines |
| US6525613B2 (en) * | 2001-05-25 | 2003-02-25 | Infineon Technologies Ag | Efficient current feedback buffer |
| JP2005515520A (en) * | 2001-05-30 | 2005-05-26 | リサーチ イン モーション リミテッド | Mobile communication device application processing system |
| US6964033B2 (en) * | 2001-06-20 | 2005-11-08 | Sun Microsystems, Inc. | Object band customization of Java runtime environments |
| US7117489B2 (en) * | 2001-06-20 | 2006-10-03 | Sun Microsystems, Inc. | Optional attribute generator for customized Java programming environments |
| US7228533B2 (en) * | 2001-08-24 | 2007-06-05 | Sun Microsystems, Inc. | Frameworks for generation of Java macro instructions for performing programming loops |
| US7058934B2 (en) * | 2001-08-24 | 2006-06-06 | Sun Microsystems, Inc. | Frameworks for generation of Java macro instructions for instantiating Java objects |
| US7039904B2 (en) | 2001-08-24 | 2006-05-02 | Sun Microsystems, Inc. | Frameworks for generation of Java macro instructions for storing values into local variables |
| US6988261B2 (en) * | 2001-08-24 | 2006-01-17 | Sun Microsystems, Inc. | Frameworks for generation of Java macro instructions in Java computing environments |
| GB0125176D0 (en) * | 2001-10-19 | 2001-12-12 | Koninkl Philips Electronics Nv | A method of compiling bytecode to native code |
| US6944846B2 (en) * | 2001-12-14 | 2005-09-13 | Hewlett-Packard Development Company, L.P. | Algorithm for localization of a JAVA application using reflection API and a custom class loader |
| US7051324B2 (en) * | 2003-01-16 | 2006-05-23 | International Business Machines Corporation | Externalized classloader information for application servers |
| FR2883390A1 (en) * | 2005-03-15 | 2006-09-22 | Gemplus Sa | MANAGING MEMORY DATA STRUCTURE PLACEMENT BASED ON DEDICATED PROGRAMMING LANGUAGE |
| US20070294676A1 (en) * | 2006-06-19 | 2007-12-20 | Ewan Ellis Mellor | Open virtual appliance |
| US7870411B2 (en) * | 2006-07-17 | 2011-01-11 | Xensource, Inc. | Tracking current time on multiprocessor hosts and virtual machines |
| US8539551B2 (en) * | 2007-12-20 | 2013-09-17 | Fujitsu Limited | Trusted virtual machine as a client |
| US9740500B2 (en) | 2012-08-30 | 2017-08-22 | Microsoft Technology Licensing, Llc | Layout system for operating systems using BPRAM |
| US9952879B2 (en) * | 2012-08-30 | 2018-04-24 | Microsoft Technology Licensing, Llc | Application pre-layout in byte-addressable persistent random access memory |
| US10025602B2 (en) * | 2014-06-03 | 2018-07-17 | Mentor Graphics Corporation | Prelinked embedding |
| CN106354536A (en) * | 2016-08-31 | 2017-01-25 | 北京奇虎科技有限公司 | Method and device of loading ELF file of Linux system in Windows system |
| US10747512B2 (en) * | 2017-01-06 | 2020-08-18 | International Business Machines Corporation | Partial object instantiation for object oriented applications |
| FR3074317B1 (en) * | 2017-11-27 | 2019-11-22 | Idemia Identity & Security France | METHOD FOR ACCESSING A FLASH TYPE NON-VOLATILE MEMORY ZONE OF A SECURE ELEMENT, SUCH AS A CHIP CARD |
| US11221835B2 (en) | 2020-02-10 | 2022-01-11 | International Business Machines Corporation | Determining when to perform and performing runtime binary slimming |
| CN111427856B (en) * | 2020-03-11 | 2023-06-02 | 北京明略软件系统有限公司 | Java data processing method and device |
| CN112131000B (en) * | 2020-09-23 | 2024-02-06 | 腾讯科技（深圳）有限公司 | Memory release method and device for plug-in application program |
| CN112667285B (en) * | 2021-01-25 | 2023-11-03 | Vidaa(荷兰)国际控股有限公司 | Application upgrading method, display device and server |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6006231A (en) * | 1996-09-10 | 1999-12-21 | Warp 10 Technologies Inc. | File format for an image including multiple versions of an image, and related system and method |
| US6083279A (en) * | 1996-10-10 | 2000-07-04 | International Business Machines Corporation | Platform independent technique for transferring software programs over a network |
| US6061057A (en) * | 1997-03-10 | 2000-05-09 | Quickbuy Inc. | Network commercial system using visual link objects |
| US6166729A (en) * | 1997-05-07 | 2000-12-26 | Broadcloud Communications, Inc. | Remote digital image viewing system and method |
| US6144992A (en) * | 1997-05-09 | 2000-11-07 | Altiris, Inc. | Method and system for client/server and peer-to-peer disk imaging |
| US6012068A (en) * | 1997-06-30 | 2000-01-04 | International Business Machines Corporation | Media manager for access to multiple media types |
| US6025826A (en) * | 1997-06-30 | 2000-02-15 | Sun Microsystems, Inc. | Method and apparatus for handling alpha premultiplication of image data |
| US6112304A (en) * | 1997-08-27 | 2000-08-29 | Zipsoft, Inc. | Distributed computing architecture |
| US6161107A (en) * | 1997-10-31 | 2000-12-12 | Iota Industries Ltd. | Server for serving stored information to client web browser using text and raster images |
| US6026405A (en) * | 1997-11-21 | 2000-02-15 | International Business Machines Corporation | Method of locating and downloading files on a network |
| US6349344B1 (en) * | 1997-12-16 | 2002-02-19 | Microsoft Corporation | Combining multiple java class files into a run-time image |
| US6121903A (en) * | 1998-01-27 | 2000-09-19 | Infit Communications Ltd. | On-the-fly data re-compression |
| US6301582B1 (en) * | 1998-03-30 | 2001-10-09 | International Business Machines Corporation | System and method for storage of shared persistent objects |
| US6330709B1 (en) * | 1998-03-30 | 2001-12-11 | International Business Machines Corporation | Virtual machine implementation for shared persistent objects |
| US6281874B1 (en) * | 1998-08-27 | 2001-08-28 | International Business Machines Corporation | Method and system for downloading graphic images on the internet |
| US6230184B1 (en) * | 1998-10-19 | 2001-05-08 | Sun Microsystems, Inc. | Method and apparatus for automatically optimizing execution of a computer program |
| US6349404B1 (en) * | 1999-06-08 | 2002-02-19 | Unisys Corp. | Object-oriented repository, a system and method for reusing existing host-based application assets for the development of business-centric applications |
-
1999
- 1999-03-30 CA CA002267477A patent/CA2267477C/en not_active Expired - Lifetime
- 1999-08-13 US US09/374,154 patent/US6446254B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US6446254B1 (en) | 2002-09-03 |
| CA2267477A1 (en) | 2000-09-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2267477C (en) | Packaging memory image files | |
| US6704746B2 (en) | Method and apparatus for lazy instantiation of objects in a virtual machine | |
| US7543309B2 (en) | Efficient linking and loading for late binding and platform retargeting | |
| US6081665A (en) | Method for efficient soft real-time execution of portable byte code computer programs | |
| US8434099B2 (en) | Efficient linking and loading for late binding and platform retargeting | |
| US6557168B1 (en) | System and method for minimizing inter-application interference among static synchronized methods | |
| US7143421B2 (en) | Highly componentized system architecture with a demand-loading namespace and programming model | |
| US7565665B2 (en) | Efficient linking and loading for late binding and platform retargeting | |
| CA2255042C (en) | Class loader | |
| CA2321787C (en) | Transparent garbage collection of resources | |
| US6633892B1 (en) | Archiving tool | |
| US20090133042A1 (en) | Efficient linking and loading for late binding and platform retargeting | |
| US6959430B2 (en) | Specialized heaps for creation of objects in object-oriented environments | |
| US6799185B2 (en) | Frameworks for accessing Java class files | |
| US6996813B1 (en) | Frameworks for loading and execution of object-based programs | |
| US7159222B1 (en) | Highly componentized system architecture with object mutation | |
| US7096466B2 (en) | Loading attribute for partial loading of class files into virtual machines | |
| US6804681B2 (en) | Identifying and tracking object references in a java programming environment | |
| US7096467B2 (en) | Initialization of Java classes in Java virtual machine environments | |
| US6751790B2 (en) | Frameworks for efficient representation of string objects in Java programming environments | |
| US20040015873A1 (en) | Identifying references to objects during bytecode verification | |
| US6934726B2 (en) | Storing and retrieving of field descriptors in Java computing environments | |
| US6978456B1 (en) | Methods and apparatus for numeric constant value inlining in virtual machines | |
| US6996824B2 (en) | Frameworks for efficient representation of string objects in Java programming environments |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20190401 |