WO2002037274A2 - Methods and apparatus for numeric constant value inlining in virtual machines - Google Patents
Methods and apparatus for numeric constant value inlining in virtual machines Download PDFInfo
- Publication number
- WO2002037274A2 WO2002037274A2 PCT/US2001/032306 US0132306W WO0237274A2 WO 2002037274 A2 WO2002037274 A2 WO 2002037274A2 US 0132306 W US0132306 W US 0132306W WO 0237274 A2 WO0237274 A2 WO 0237274A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- java
- command
- constant
- load constant
- data
- Prior art date
Links
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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
- G06F9/45508—Runtime interpretation or emulation, e g. emulator loops, bytecode interpretation
-
- 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
Definitions
- the present invention relates generally to object-based high level programming environments, and more particularly, to frameworks for loading and execution of portable, platform independent programming instructions within a virtual machine.
- JavaTM programming language is an language that is designed to be portable enough to be executed on a wide range of computers ranging from small devices (e.g., pagers, cell phones and smart cards) up to supercomputers.
- Computer programs written in the Java programming language (and. other languages) may be compiled into Java virtual machine instructions (typically referred to as Java bytecodes) that are suitable for execution by a Java virtual machine implementation.
- Java virtual machine is commonly implemented in software by means of an interpreter for the Java virtual machine instruction set but, in general, may be software, hardware, or both.
- interpreter for the Java virtual machine instruction set
- Java virtual machine implementation and corresponding support libraries, together constitute a JavaTM runtime environment.
- Computer programs in the Java programming language are arranged in one or more classes or interfaces (referred to herein jointly as classes or class files). Such programs are generally platform, i.e., hardware and operating system, independent. As such, these computer programs may be executed, unmodified, on any computer that is able to run an implementation of the JavaTM runtime environment.
- a class written in the Java programming language is compiled to a particular binary format called the "class file format" that includes Java virtual machine instructions for the methods of a single class.
- the class file format includes a significant amount of ancillary information that is associated with the class.
- the class file format (as well as the general operation of the Java virtual machine) is described in some detail in The Java Virtual Machine Specification by Tim Lindholm and Frank Yellin (ISBN 0-201-31006-6), which is hereby incorporated herein by reference.
- the virtual machine when a class file is loaded into the virtual machine, the virtual machine essentially makes a copy of the class file for its internal use.
- the virtual machine's internal copy is sometimes referred to as an "internal class representation.”
- the internal class representation In conventional virtual machines, the internal class representation is typically almost an exact copy of the class file and it replicates the entire Constant Pool. This is true regardless of whether multiple classes loaded into the virtual machine reference the same method and thus replicate some (or much) of the same Constant Pool information. Such replication may, of course, result in an inefficient use of memory resources. In some circumstances (particularly in embedded systems which have limited memory resources) this inefficient use of memory resources can be a significant disadvantage.
- Constant Pool is a data structure that has several uses.
- One of the uses of the Constant Pool that is relevant to the present invention is that the Constant Pool contains the information that is needed to resolve various Java Instructions, for example, a method invocation instruction that can be invoked by any of the methods within the class.
- Fig. 1A (which may be familiar to those skilled in the art) is a representation of a Constant Pool section of a class file that contains the information necessary to uniquely identify and locate a particular invoked method.
- Fig. IB shows an exemplary conventional Java bytecode stream 150 including virtual machine instructions (typically referred to as Java bytecodes) that are suitable for execution by a conventional Java virtual machine.
- the first bytecode, Java bytecode 152 represents an arithmetic Java "Add" command with no associated parameters.
- the second bytecode, Java bytecode 154 represents a Java "iconst” instruction (load an integer constant on the stack).
- an index to the Constant Pool is constructed from the CP-IndexA and CP-IndexA.
- the Java instruction "iconstant" is executed but only after performing several operations at run time.
- the execution of a relatively simple instruction such as loading a constant value can take a significant amount of run time.
- execution of relatively more complex Java instructions requires even more processing than noted above.
- the constant pool has to be accessed several times at run time just to obtain the symbolic representation of information associated with the method.
- the CPJndexC and CP_IndexD are indexes to a constant pool where information relating to the method including its parameter values needed for execution can be found.
- a CP_IndexD associated with the method instruction 158 is typically an index to an entry into the Constant Pool wherein that entry itself provides another pair of indexes to other entries in the Constant Pool, and so forth.
- execution of an invoke method command would require a significant amount of processing at run time (e.g., accessing the Constant Pool several times to obtain symbolic representation relating to the method).
- this conventional technique is an inefficient approach that may result in significantly longer execution times.
- there may be a need to convert the symbolic information into an internal representation at run time there may be a need to convert the symbolic information into an internal representation at run time. Again, this is an inefficient approach.
- One aspect of the present invention seeks to provide a mechanism that will generally improve the runtime performance of virtual machines by eliminating the need to always traverse a constant pool at runtime to execute a Java instruction.
- the described system contemplates doing some extra work during the loading of a class into a virtual machine by obtaining the information from the constant pool during loading and representing that information in a form that can be used more efficiently at runtime.
- an enhanced Java bytecode representation having a pair of Java bytecode streams is disclosed.
- the enhanced Java bytecode has a Java code stream suitable for storing Java commands as bytecodes within a code stream.
- a Java data stream of the enhanced Java bytecode representation is used to store the data parameters associated with the Java commands in the code stream.
- the invention allows for representation in the code stream of actual parameter values, or references to actual parameter values. Accordingly, data parameters can be provided for efficient execution of Java instructions without requiring further processing of Constant Pool at run time. As a result, the performance of Java complaint virtual machine can be enhanced.
- the invention can be implemented in numerous ways, including a system, an apparatus, a method or a computer readable medium. Several embodiments of the invention are discussed below.
- one embodiment of the invention provides for converting one or more Java bytecodes representing a
- the Java bytecode streams can include a Java code stream with one or more Java bytecodes representing the Java Load Constant command and a Java data stream that includes one or more Java bytecodes representing data associated with the Java Load Constant command in the Java code stream.
- the data structure suitable for use by a virtual machine in an object oriented programming environment includes a code portion having a load constant computer executable command, and a data stream having data corresponding to the load constant computer executable command.
- one embodiment of the invention includes the acts of: fetching a load constant command from a stream; fetching from another stream data associated with the load constant command; and executing the load constant command with the associated data after the associated has been fetched.
- Fig. 1A is a representation of a Constant Pool section of a Java class file.
- Fig. IB shows an exemplary conventional Java bytecode stream including virtual machine instructions.
- Fig. 2 is a block diagram representation of Java bytecode streams in accordance with one embodiment of the invention.
- Fig. 3 illustrates an execution method for executing Java bytecode instructions in accordance with one embodiment of the invention.
- Fig. 4 illustrates an exemplary bytecode stream generation method in accordance with one embodiment of the invention.
- Fig. 5 illustrates an exemplary loading method for loading bytecodes of a class file in accordance with one embodiment of the invention.
- Fig. 6 illustrates a processing method for processing a Java Load constant command in accordance with one embodiment of the invention.
- Fig. 7 illustrates an execution method for executing a Java Load Constant command in accordance with one embodiment of the invention.
- Java programming environment has enjoyed widespread success. Therefore, there are continuing efforts to extend the breadth of Java compatible devices and to improve the performance of such devices.
- One of the most significant factors influencing the performance of Java based programs on a particular platform is the performance of the underlying virtual machine. Accordingly, there have been extensive efforts by a number of entities to provide improved performance Java compliant virtual machines.
- a virtual machine In order to be Java compliant, a virtual machine must be capable of working with Java classes, which have a defined class file format. Although it is important that any Java virtual machine be capable of handling Java classes, the Java virtual machine specification does not dictate how such classes are represented internally within a particular Java virtual machine implementation.
- the Java class file format utilizes the constant pool construct to store the information necessary to execute a Java instruction at run time.
- traversing the constant pool at runtime to obtain the information necessary to execute Java instructions is not particularly efficient.
- One aspect of the present invention seeks to provide a mechanism that will generally improve the runtime performance of virtual machines by eliminating the need to always traverse a constant pool at runtime to execute a Java instruction. Accordingly, a significant amount of work is conventionally performed at runtime. In effect, the described system contemplates doing some extra work during the loading of a class into a virtual machine by obtaining the information from the constant pool during loading and representing that information in a form that can be used more efficiently at runtime
- an enhanced Java bytecode representation having a pair of Java bytecode streams is disclosed.
- the enhanced Java bytecode has a Java code stream suitable for storing various Java commands as bytecodes within a code stream.
- a Java data stream of the enhanced Java bytecode representation is used to store the data parameters associated with the Java commands in the code stream.
- the invention allows for representation in the code stream of actual parameter values, or references to actual parameter values. Accordingly, data parameters can be provided for efficient execution of Java instructions without requiring further processing of Constant Pools at run time. As a result, the performance of Java complaint virtual machine can be enhanced.
- Fig. 2 is a block diagram representation of Java bytecode streams 200 in accordance with one embodiment of the invention.
- the Java bytecode streams 200 can be, for example, implemented as a data structure embodied in a computer readable medium that is suitable for use by a virtual machine.
- the Java bytecode streams 200 includes a pair of Java bytecode streams, namely, a Java code stream 202 and a Java data stream 204.
- the code stream 202 includes various Java commands 206, 208, and 210.
- the code stream 206 represents a Java command A which does not have any parameters associated with it.
- code streams 208 and 210 represent respectively Java commands B and C with associated data parameters which are represented in the Java data stream 204.
- the Java bytecode 212 represents data B which is the data parameters corresponding to the Java command B of Java code stream 202. It should be noted that the Java command B and data B together represent a Java instruction corresponding to a Java command B with its associated data. Similarly, the Java bytecodes 214 and 216 represent respectively data Cl and C2 which collectively represent the data parameters corresponding to the Java command C of Java code stream 202. Accordingly, the Java command C, data Cl and data C2 together represent a Java instruction corresponding to a Java command C with its associate data represented in bytecodes 214 and 216.
- the Java bytecode 200 streams are suitable for use by a virtual machine.
- an exemplary execution method 300 for executing Java bytecode instructions is disclosed.
- the execution method 300 can be used, for example, in conjunction with a pair of Java bytecode streams, for example, the Java code stream 202 and Java data stream 204.
- the next command in the code stream is fetched.
- the next command fetched can be the bytecode 206 of the Java code stream 202.
- a pointer to the Java code stream is incremented to point to the next command in the Java code stream. Referring again to Fig.
- a pointer to the Java code stream 206 is incremented to point to the next command in the Java code stream, foe example, the bytecode 206 (Java command B).
- the execution method 300 proceeds to operation 306 where a determination is made as to whether the fetched command has an associated parameter. If it is determined at operation 306 that the fetched command does not have an associated parameter, for example, in the case of Java command A of Fig. 2, the execution method 300 proceeds directly to operation 312 where the fetched command (with no associated parameter) is executed. Thereafter, at operation 314 a determination is made as to whether there are more commands in the Java code stream to execute.
- the execution method 300 ends. However, if it is determined at operation 314 that there are no more commands to execute, that execution method 300 proceeds back to operation 302 where the next command in the code stream is fetched. On the other hand, if it is determined at operation 306 that the fetched command has an associated parameter, the execution method 300 proceeds to operation 308 where the parameter values associated with the fetched command are fetched from the data stream. Referring back to Fig 2., for example, in the case when the fetched command is the Java command B of bytecode 208, the parameter values associated with Java command B, namely, data B of the bytecode 212 is fetched.
- the pointer to the data command stream is incremented to point to the appropriate position in the data stream.
- the pointer to the data stream can be updated based on the command type (i.e., based on the number of bytecodes appropriated for the data associated with the command).
- the execution method 300 proceeds to operation 314 where the fetched command is executed.
- a determination is made as to whether there are more commands in the Java code stream to execute. If it is determined at operation 314 that there are no more commands to execute, the execution method 300 ends.
- the invention provides for a pair of Java bytecode streams suitable for use by a virtual machine, for example, the code stream 202 and a Java data stream 204.
- a virtual machine for example, the code stream 202 and a Java data stream 204.
- FIG. 4 an exemplary bytecode stream generation method 400 for generation of an enhanced bytecode representation is disclosed.
- the bytecode stream generation can be used, for example, to generate a pair of bytecode streams from a conventional Java bytecode stream 150 of Fig. 1. Initially, at operation 402, the next bytecode representing a command is read.
- a bytecode representing the command is written into an entry of a code stream, for example, the Java code stream 202 of Fig. 2.
- the bytecode stream generation method 400 proceeds to operation 408 where the associated parameters are read and processed.
- the processing of the associated parameters can be performed based on the command type in accordance with one aspect of the invention. This processing will be further illustrated in Fig. 5 below.
- an appropriate value is written to a data stream, for example, the Java data stream of Fig. 2.
- the bytecode stream generation method 400 proceeds to operation 410 where a determination is made as to whether there are more bytecodes to read, if there is at least one more bytecodes to read, the bytecode stream generation method 400 proceeds to operation 402 where the next bytecode representing a command is read. However, if there are no more bytecodes to process, the bytecode stream generation method 400 ends.
- Fig. 5 illustrates an exemplary loading method 500 for loading bytecodes of a class file in accordance with one embodiment of the invention.
- the loading is used in a Java runtime environment to load a Java class file.
- the class file can include various Java instructions ( ava commands and associated data parameters) . Typically, this would be accomplished by a Java class loader.
- the Java commands are written into a Java code stream. Accordingly, the loading method 500 illustrates loading operations that can be performed to provide the corresponding Java code stream for the Java code stream.
- the loading method 500 proceeds to operation 506 where a determination is made as to whether the Java command is an invoke method command. If it is determined at operation 506 that the Java command is an invoke method command, the loading method 500 proceeds to operation 508 where the invoke method command is processed in accordance with another aspect of the invention.
- the invoke method command is processed to create a reference cell which provides the information necessary to invoke the method at run time. For example, such processing can be performed as illustrated in co-pending U.S. Patent Application No. 09/703,361, entitled "IMPROVED FRAMEWORKS FOR INVOKING METHODS IN VIRTUAL MACHINES" .
- the address of the reference cell corresponding to the invoke method command is written into the data stream.
- the loading method 500 proceeds to operation 512 where a determination is made as to whether the Java command is a Jump command. If it is determined at operation 512 that Java command is a Jump command, the appropriate code and data stream offsets of the Jump command are written into the data stream entry corresponding to the jump.
- the loading method 500 proceeds to operation 516 where a determination is made as to whether the Java command is an instantiation command. As will be appreciated, if it is determined at operation 516 that the Java command is an instantiation command, the Constant pool information for the instantiation command can be processed at operation 518. Following operation 518, in the described embodiment, the appropriate type-descriptor is written into the data stream at operation 520. However, if it is determined at operation 516 that the Java command is not an instantiation command, the loading method 500 proceeds to operation 522 where it is determined whether the Java command is a Get/Put field command.
- the Constant pool information for the instantiation command can be processed at operation 518.
- a reference cell which provides the information necessary to execute the Get/Put field command at run time can be generated. Accordingly, following operation 524, the address of a reference cell corresponding to the Get/Put field command can be written into the data stream at operation 526.
- the loading method 500 ends if it is determined at operation 522 that the Java command is not a Get/Put field command.
- Fig. 6 illustrates a processing method 600 for processing a Java Load constant command in accordance with one embodiment of the invention.
- the processing method 600 represents operations that can be performed, for example, at operation 508 of Fig. 5.
- the processing method 600 can be used to convert a conventional representation of a Load constant command with its associated parameter (e.g., bytecodes 154, 156, and represent the Load constant command and its associated parameter respectively into a Java code stream and a Java data stream, for example, the Java code stream 202 and Java data stream 204 of Fig. 2.
- the first bytecode of the Constant Pool index e.g., the first bytecode of the Constant Pool index
- the Constant Pool index is constructed from the first and second fetched bytes. After construction of the Constant Pool index, appropriate data structures of the Constant Pool are read at operation 608. Next, at operation 610, the corresponding constant value is determined based on the constant information read at operation 608. As will appreciated, other operations can be performed, for example, if necessary, byte alignment can be performed at operation 610.
- the constant value determined at operation 610 is written into a Java data stream, for example, the Java data stream 204 of Fig. 2. It should be noted that corresponding Java Load constant command is written into an appropriate entry of a Java code stream, for example, the Java code stream 202 of Fig. 2.
- Fig. 7 illustrates an execution method 700 for executing a Java Load Constant command in accordance with one embodiment of the invention.
- the execution method 700 can be implemented in a virtual machine in conjunction with an enhanced bytecode representation to allow more efficient run time execution of a Java Load Constant command.
- the processing method 600 can be used to generate the bytecode streams 200 having the Java code stream 202 and Java data stream 204. Accordingly, The Java Load Constant command can be stored in the code stream while the corresponding Constant parameters value are stored in the data stream.
- the Java Load Constant command is fetched from the code stream.
- the bytecode 206 of the Java code stream 206 (Java command A), representing a Java Load Constant command is fetched from the Java code stream 202.
- a pointer to the Java code stream is incremented to point to the next command in the Java code stream.
- a pointer to the Java code stream 206 is incremented to point to the next command in the Java code stream, namely, code stream 206 (Java command B).
- the execution method 700 proceeds to operation 706 where it is determined how many bytecodes corresponding to the Constant parameter value needs to be fetched from the Java data stream. As will appreciated this determination can be made based on the Constant's type (e.g., double, integer, float, etc.). Accordingly, at operation 708, the appropriate number of bytes which correspond to the Constant parameter value are fecthed.
- Constant's type e.g., double, integer, float, etc.
- the pointer to the data command stream is incremented to point to the appropriate position in the data stream.
- the pointer to the data stream can be updated based on the type of the Load constant command (i.e., based on the number of bytecodes appropriated for the data associated with the command).
- the Constant Load command is executed, for example, the appropriate Constant value command in pushed on the stack.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
Improved fraemworks for loading and execution of portable, platform independent programming instructions within a virtual machine are disclosed. The improved frameworks provide a mechanism that will generally improve the runtime performance of virtual machines by eliminating the need to always traverse a constant pool at runtime to execute a Java instruction. In effect, the described system contemplates doing some extra work during the loadin of a class into a virtual machine by obtaining the information from the constant pool during loading and representing that information in a form that cen be used more efficiently at runtime. Accordingly, methods for creating data structures suitable for use by a virtual machine to execute load constant commands, as well as methods for exeuction of Java load constant instructions are disclosed. The data structures can include a code portion having a load constant computer executable command, and a data stream having data corresponding to the load constant computer executable command.
Description
IMPROVED METHODS AND APPARATUS FOR NUMERIC CONSTANT VALUE INLINING IN VIRTUAL MACHINES
CROSS-REFERENCE TO RELATED APPLICATIONS
This application is related to U.S. Patent Application No. 09/703,361, entitled "IMPROVED FRAMEWORKS FOR INVOKING METHODS IN VIRTUAL MACHINES", filed concurrently herewith, and hereby incorporated herein by reference. This application is related to U.S. Patent Application No. 09/703,449, entitled "IMPROVED FRAMEWORKS FOR LOADING AN EXECUTION OF OBJECT- BASED PROGRAMS", filed concurrently herewith, and hereby incorporated herein by reference.
BACKGROUND OF THE INVENTION
The present invention relates generally to object-based high level programming environments, and more particularly, to frameworks for loading and execution of portable, platform independent programming instructions within a virtual machine.
Recently, the Java™ programming environment has become quite popular. The Java™ programming language is an language that is designed to be portable enough to be executed on a wide range of computers ranging from small devices (e.g., pagers, cell phones and smart cards) up to supercomputers. Computer programs written in the Java programming language (and. other languages) may be compiled into Java virtual machine instructions (typically referred to as Java bytecodes) that are suitable for execution by a Java virtual machine implementation.
The Java virtual machine is commonly implemented in software by means of an interpreter for the Java virtual machine instruction set but, in general, may be software, hardware, or both. A particular Java virtual machine
implementation and corresponding support libraries, together constitute a Java™ runtime environment.
Computer programs in the Java programming language are arranged in one or more classes or interfaces (referred to herein jointly as classes or class files). Such programs are generally platform, i.e., hardware and operating system, independent. As such, these computer programs may be executed, unmodified, on any computer that is able to run an implementation of the Java™ runtime environment. A class written in the Java programming language is compiled to a particular binary format called the "class file format" that includes Java virtual machine instructions for the methods of a single class. In addition to the Java virtual machine instructions for the methods of a class, the class file format includes a significant amount of ancillary information that is associated with the class. The class file format (as well as the general operation of the Java virtual machine) is described in some detail in The Java Virtual Machine Specification by Tim Lindholm and Frank Yellin (ISBN 0-201-31006-6), which is hereby incorporated herein by reference.
Conventionally, when a class file is loaded into the virtual machine, the virtual machine essentially makes a copy of the class file for its internal use. The virtual machine's internal copy is sometimes referred to as an "internal class representation." In conventional virtual machines, the internal class representation is typically almost an exact copy of the class file and it replicates the entire Constant Pool. This is true regardless of whether multiple classes loaded into the virtual machine reference the same method and thus replicate some (or much) of the same Constant Pool information. Such replication may, of course, result in an inefficient use of memory resources. In some circumstances (particularly in embedded systems which have limited memory resources) this inefficient use of memory resources can be a significant disadvantage.
As described in The Java Virtual Machine Specification, one of the structures of a standard class file is known as the "Constant Pool." The
Constant Pool is a data structure that has several uses. One of the uses of the Constant Pool that is relevant to the present invention is that the Constant Pool
contains the information that is needed to resolve various Java Instructions, for example, a method invocation instruction that can be invoked by any of the methods within the class. Fig. 1A (which may be familiar to those skilled in the art) is a representation of a Constant Pool section of a class file that contains the information necessary to uniquely identify and locate a particular invoked method.
Additionally, conventional virtual machine interpreters decode and execute the virtual machine instructions (Java bytecodes) one instruction at a time during execution, e.g., "at runtime." To execute a Java instruction, typically, several operations have to been performed to obtain the information that is necessary to execute the Java instruction. For example, to invoke a method referenced by a Java bytecode, the virtual machine must make several operations to access the Constant Pool simply to identify the information necessary to locate and access the invoked method. To illustrate, Fig. IB shows an exemplary conventional Java bytecode stream 150 including virtual machine instructions (typically referred to as Java bytecodes) that are suitable for execution by a conventional Java virtual machine. The first bytecode, Java bytecode 152 represents an arithmetic Java "Add" command with no associated parameters. The second bytecode, Java bytecode 154 represents a Java "iconst" instruction (load an integer constant on the stack). The Java bytecodes 156 and 157, CP-IndexA and CP-IndexB, respectively represent the first and second bytes of an index to the constant pool for the integer constant. It should be noted that Java bytecodes 152, 154 and 156 collectively represent a Java "iconst" instruction. In order to execute the Java Instruction iconst, at run time, an index to the Constant Pool is constructed from the CP-IndexA and CP-IndexA. Once an index to the Constant Pool has been determined, the appropriate structures in the Constant Pool have to be accessed so that the appropriate constant value can be determined. Accordingly, the Java instruction "iconstant" is executed but only after performing several operations at run time. As can be appreciated from the example above, the execution of a relatively simple instruction such as loading a constant value can take a significant amount of run time.
Furthermore, execution of relatively more complex Java instructions requires even more processing than noted above. For example, in order to conventionally execute an invoke method command 158, the constant pool has to be accessed several times at run time just to obtain the symbolic representation of information associated with the method. The CPJndexC and CP_IndexD are indexes to a constant pool where information relating to the method including its parameter values needed for execution can be found. Accordingly, a CP_IndexD associated with the method instruction 158 is typically an index to an entry into the Constant Pool wherein that entry itself provides another pair of indexes to other entries in the Constant Pool, and so forth. Thus, execution of an invoke method command would require a significant amount of processing at run time (e.g., accessing the Constant Pool several times to obtain symbolic representation relating to the method). As will be appreciated, this conventional technique is an inefficient approach that may result in significantly longer execution times. In addition, once the symbolic information relating to the method has been obtained, there may be a need to convert the symbolic information into an internal representation at run time. Again, this is an inefficient approach.
Accordingly, there is a need for improved frameworks for loading and execution of portable, platform independent programming instructions within a virtual machine.
SUMMARY OF THE INVENTION
To achieve the foregoing and other objects of the invention, improved frameworks for loading and execution of portable, platform independent programming instructions within a virtual machine will be described. One aspect of the present invention seeks to provide a mechanism that will generally improve the runtime performance of virtual machines by eliminating the need to always traverse a constant pool at runtime to execute a Java instruction. In effect, the described system contemplates doing some extra work during the loading of a class into a virtual machine by obtaining the information from the constant pool during loading and representing that information in a form that can be used more efficiently at runtime.
In other aspects of the invention, specific data structures that are suitable for use within a virtual machine and methods for creating such data structures are described. In one embodiment, an enhanced Java bytecode representation having a pair of Java bytecode streams is disclosed. The enhanced Java bytecode has a Java code stream suitable for storing Java commands as bytecodes within a code stream. A Java data stream of the enhanced Java bytecode representation is used to store the data parameters associated with the Java commands in the code stream. As will be appreciated, the invention allows for representation in the code stream of actual parameter values, or references to actual parameter values. Accordingly, data parameters can be provided for efficient execution of Java instructions without requiring further processing of Constant Pool at run time. As a result, the performance of Java complaint virtual machine can be enhanced. The invention can be implemented in numerous ways, including a system, an apparatus, a method or a computer readable medium. Several embodiments of the invention are discussed below.
As a method of creating data structures suitable for use by a virtual machine to execute a Java Load Constant instruction, one embodiment of the invention provides for converting one or more Java bytecodes representing a
Java Load Constant instruction in single stream into Java bytecodes in a pair of
Java bytecode streams suitable for use by the virtual machine. The Java bytecode streams can include a Java code stream with one or more Java bytecodes representing the Java Load Constant command and a Java data stream that includes one or more Java bytecodes representing data associated with the Java Load Constant command in the Java code stream.
As a data structure for containing a load constant computer executable command and data associated with the load constant computer executable command, the data structure suitable for use by a virtual machine in an object oriented programming environment, one embodiment of the invention includes a code portion having a load constant computer executable command, and a data stream having data corresponding to the load constant computer executable command.
As a method of executing load constant computer instructions on a virtual machine in an object oriented programming environment, one embodiment of the invention includes the acts of: fetching a load constant command from a stream; fetching from another stream data associated with the load constant command; and executing the load constant command with the associated data after the associated has been fetched.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:
Fig. 1A is a representation of a Constant Pool section of a Java class file.
Fig. IB shows an exemplary conventional Java bytecode stream including virtual machine instructions.
Fig. 2 is a block diagram representation of Java bytecode streams in accordance with one embodiment of the invention.
Fig. 3 illustrates an execution method for executing Java bytecode instructions in accordance with one embodiment of the invention.
Fig. 4 illustrates an exemplary bytecode stream generation method in accordance with one embodiment of the invention. Fig. 5 illustrates an exemplary loading method for loading bytecodes of a class file in accordance with one embodiment of the invention.
Fig. 6 illustrates a processing method for processing a Java Load constant command in accordance with one embodiment of the invention.
Fig. 7 illustrates an execution method for executing a Java Load Constant command in accordance with one embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION
As described in the background section, the Java programming environment has enjoyed widespread success. Therefore, there are continuing efforts to extend the breadth of Java compatible devices and to improve the performance of such devices. One of the most significant factors influencing the performance of Java based programs on a particular platform is the performance of the underlying virtual machine. Accordingly, there have been extensive efforts by a number of entities to provide improved performance Java compliant virtual machines. In order to be Java compliant, a virtual machine must be capable of working with Java classes, which have a defined class file format. Although it is important that any Java virtual machine be capable of handling Java classes, the Java virtual machine specification does not dictate how such classes are represented internally within a particular Java virtual machine implementation.
The Java class file format utilizes the constant pool construct to store the information necessary to execute a Java instruction at run time. However, as suggested above, traversing the constant pool at runtime to obtain the information necessary to execute Java instructions is not particularly efficient. One aspect of the present invention seeks to provide a mechanism that will generally improve the runtime performance of virtual machines by eliminating the need to always traverse a constant pool at runtime to execute a Java instruction. Accordingly, a significant amount of work is conventionally performed at runtime. In effect, the described system contemplates doing some extra work during the loading of a class into a virtual machine by obtaining the information from the constant pool during loading and representing that information in a form that can be used more efficiently at runtime
In other aspects of the invention, specific data structures that are suitable for use within a virtual machine and methods for creating such data structures are described. In one embodiment, an enhanced Java bytecode representation having a pair of Java bytecode streams is disclosed. The enhanced Java
bytecode has a Java code stream suitable for storing various Java commands as bytecodes within a code stream. A Java data stream of the enhanced Java bytecode representation is used to store the data parameters associated with the Java commands in the code stream. As will be appreciated, the invention allows for representation in the code stream of actual parameter values, or references to actual parameter values. Accordingly, data parameters can be provided for efficient execution of Java instructions without requiring further processing of Constant Pools at run time. As a result, the performance of Java complaint virtual machine can be enhanced. Furthermore, if the invention is implemented together with other improvements as described in concurrently filed, co-pending Application No. U.S. Patent Application No. 09/703,361, entitled "IMPROVED FRAMEWORKS FOR INVOKING METHODS IN VIRTUAL MACHINES", the constant pool may not even need to be copied into the virtual machine's in order to invoke methods. Thus, the use of the invention in conjunction with the improved techniques provided as described in U.S. Patent Application No. 09/703,361, entitled "IMPROVED FRAMEWORKS FOR INVOKING METHODS IN VIRTUAL MACHINES" has the potential in many circumstances to even further improve the performance of the virtual machines.
Embodiments of the invention are discussed below with reference to Figs.
2 - 7. However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanatory purposes as the invention extends beyond these limited embodiments.
Fig. 2 is a block diagram representation of Java bytecode streams 200 in accordance with one embodiment of the invention. The Java bytecode streams 200 can be, for example, implemented as a data structure embodied in a computer readable medium that is suitable for use by a virtual machine. As shown in Fig. 2, the Java bytecode streams 200 includes a pair of Java bytecode streams, namely, a Java code stream 202 and a Java data stream 204. The code stream 202 includes various Java commands 206, 208, and 210. The code stream 206 represents a Java command A which does not have any parameters
associated with it. On the other hand, code streams 208 and 210 represent respectively Java commands B and C with associated data parameters which are represented in the Java data stream 204. The Java bytecode 212 represents data B which is the data parameters corresponding to the Java command B of Java code stream 202. It should be noted that the Java command B and data B together represent a Java instruction corresponding to a Java command B with its associated data. Similarly, the Java bytecodes 214 and 216 represent respectively data Cl and C2 which collectively represent the data parameters corresponding to the Java command C of Java code stream 202. Accordingly, the Java command C, data Cl and data C2 together represent a Java instruction corresponding to a Java command C with its associate data represented in bytecodes 214 and 216.
As noted above, the Java bytecode 200 streams are suitable for use by a virtual machine. Referring now to Fig. 3, an exemplary execution method 300 for executing Java bytecode instructions is disclosed. The execution method 300 can be used, for example, in conjunction with a pair of Java bytecode streams, for example, the Java code stream 202 and Java data stream 204. Initially, at operation 302, the next command in the code stream is fetched. For example, referring back to Fig. 2, the next command fetched can be the bytecode 206 of the Java code stream 202. Next, at operation 304, a pointer to the Java code stream is incremented to point to the next command in the Java code stream. Referring again to Fig. 2, a pointer to the Java code stream 206 is incremented to point to the next command in the Java code stream, foe example, the bytecode 206 (Java command B). Following incrementing the pointer at operation 304, the execution method 300 proceeds to operation 306 where a determination is made as to whether the fetched command has an associated parameter. If it is determined at operation 306 that the fetched command does not have an associated parameter, for example, in the case of Java command A of Fig. 2, the execution method 300 proceeds directly to operation 312 where the fetched command (with no associated parameter) is executed. Thereafter, at operation 314 a determination is made as to whether there are more commands in the Java code stream to execute. If it is determined at operation
314 that there are no more commands to execute, the execution method 300 ends. However, if it is determined at operation 314 that there is at least one more command to execute, that execution method 300 proceeds back to operation 302 where the next command in the code stream is fetched. On the other hand, if it is determined at operation 306 that the fetched command has an associated parameter, the execution method 300 proceeds to operation 308 where the parameter values associated with the fetched command are fetched from the data stream. Referring back to Fig 2., for example, in the case when the fetched command is the Java command B of bytecode 208, the parameter values associated with Java command B, namely, data B of the bytecode 212 is fetched. Similarly, in the case of the Java command C (bytecode 210), data Cl and data C2 (bytecodes 214 and 216) would be fetched at operation 308. As will be appreciated, the invention allows for parameter values in the data stream which can represent actual parameter values (or references to actual parameter values). Accordingly, the data parameters in the data code can be used to execute instructions without requiring further processing of Constant Pool.
After the appropriate data is fetched, at operation 310, the pointer to the data command stream is incremented to point to the appropriate position in the data stream. As will be appreciated, the pointer to the data stream can be updated based on the command type (i.e., based on the number of bytecodes appropriated for the data associated with the command). When the command and the appropriate parameter values have been fetched, the execution method 300 proceeds to operation 314 where the fetched command is executed. Finally, at operation 314 a determination is made as to whether there are more commands in the Java code stream to execute. If it is determined at operation 314 that there are no more commands to execute, the execution method 300 ends. However, if it is determined at operation 314 that there is at least one more command to execute, that execution method 300 proceeds back to operation 302 where the next command in the code stream is fetched.
As noted above, the invention, among other things, provides for a pair of Java bytecode streams suitable for use by a virtual machine, for example, the code stream 202 and a Java data stream 204. Referring now to Fig. 4, an exemplary bytecode stream generation method 400 for generation of an enhanced bytecode representation is disclosed. The bytecode stream generation can be used, for example, to generate a pair of bytecode streams from a conventional Java bytecode stream 150 of Fig. 1. Initially, at operation 402, the next bytecode representing a command is read. Next, at operation 404, a bytecode representing the command is written into an entry of a code stream, for example, the Java code stream 202 of Fig. 2. Following operation 404, a determination is made at operation 406 as to whether the command has an associated parameter. If it is determined at operation 406 that the command does not have any associated parameters, the bytecode stream generation method 400 proceeds directly to operation 410 where a determination is made as to whether there are more bytecodes to read. If there are no more bytecodes to process, the bytecode stream generation method 400 ends. However, if there is at least one more bytecodes to read, the bytecode stream generation method 400 proceeds to operation 402 where the next bytecode representing a command is read. On the other hand, when it is determined at operation 406 that the command has associated parameters, the bytecode stream generation method 400 proceeds to operation 408 where the associated parameters are read and processed. As will be appreciated, the processing of the associated parameters can be performed based on the command type in accordance with one aspect of the invention. This processing will be further illustrated in Fig. 5 below. After appropriate processing of associated parameters, at operation 409, an appropriate value is written to a data stream, for example, the Java data stream of Fig. 2. Next, the bytecode stream generation method 400 proceeds to operation 410 where a determination is made as to whether there are more bytecodes to read, if there is at least one more bytecodes to read, the bytecode stream generation method 400 proceeds to operation 402 where the next
bytecode representing a command is read. However, if there are no more bytecodes to process, the bytecode stream generation method 400 ends.
Fig. 5 illustrates an exemplary loading method 500 for loading bytecodes of a class file in accordance with one embodiment of the invention. For the sake of illustration, in the described embodiment, the loading is used in a Java runtime environment to load a Java class file. The class file can include various Java instructions ( ava commands and associated data parameters) . Typically, this would be accomplished by a Java class loader. It should be noted that in the described embodiment the Java commands are written into a Java code stream. Accordingly, the loading method 500 illustrates loading operations that can be performed to provide the corresponding Java code stream for the Java code stream.
Initially, at operation 502, a determination is made as to whether the Java command is a load constant command. If it is determined at operation 502 that the Java command is a load constant command, the loading method 500 proceeds to operation 504 where the load constant command is processed in accordance with one aspect of the invention. For example, such processing can be performed as illustrated below in Fig. 6.
On the other hand, If it is determined at operation 502 that the Java command is not a load constant command, the loading method 500 proceeds to operation 506 where a determination is made as to whether the Java command is an invoke method command. If it is determined at operation 506 that the Java command is an invoke method command, the loading method 500 proceeds to operation 508 where the invoke method command is processed in accordance with another aspect of the invention. In a preferred embodiment, the invoke method command is processed to create a reference cell which provides the information necessary to invoke the method at run time. For example, such processing can be performed as illustrated in co-pending U.S. Patent Application No. 09/703,361, entitled "IMPROVED FRAMEWORKS FOR INVOKING METHODS IN VIRTUAL MACHINES" . Accordingly, in the described embodiment, the address of the reference cell corresponding to the invoke method command is written into the data stream.
However, If it is determined at operation 506 that the Java command is not an Invoke method command, the loading method 500 proceeds to operation 512 where a determination is made as to whether the Java command is a Jump command. If it is determined at operation 512 that Java command is a Jump command, the appropriate code and data stream offsets of the Jump command are written into the data stream entry corresponding to the jump.
On the other hand, If it is determined at operation 512 that the Java command is not a jump command, the loading method 500 proceeds to operation 516 where a determination is made as to whether the Java command is an instantiation command. As will be appreciated, if it is determined at operation 516 that the Java command is an instantiation command, the Constant pool information for the instantiation command can be processed at operation 518. Following operation 518, in the described embodiment, the appropriate type-descriptor is written into the data stream at operation 520. However, if it is determined at operation 516 that the Java command is not an instantiation command, the loading method 500 proceeds to operation 522 where it is determined whether the Java command is a Get/Put field command.
As will be appreciated, if it is determined at operation 522 that the Java command is a Get/Put field command, the Constant pool information for the instantiation command can be processed at operation 518. For example, a reference cell which provides the information necessary to execute the Get/Put field command at run time can be generated. Accordingly, following operation 524, the address of a reference cell corresponding to the Get/Put field command can be written into the data stream at operation 526. The loading method 500 ends if it is determined at operation 522 that the Java command is not a Get/Put field command.
Fig. 6 illustrates a processing method 600 for processing a Java Load constant command in accordance with one embodiment of the invention. The processing method 600 represents operations that can be performed, for example, at operation 508 of Fig. 5. It should be noted that the processing method 600 can be used to convert a conventional representation of a Load constant command with its associated parameter (e.g., bytecodes 154, 156, and
represent the Load constant command and its associated parameter respectively into a Java code stream and a Java data stream, for example, the Java code stream 202 and Java data stream 204 of Fig. 2. Initially, at operation 602, the first bytecode of the Constant Pool index
(e.g., bytecode 156 of Fig. 1) is fetched. Next, at operation 604, the second bytecode of the Constant Pool index (e.g., byte code 157 of Fig. 1) is fetched. As will be appreciated, at operation 606, the Constant Pool index is constructed from the first and second fetched bytes. After construction of the Constant Pool index, appropriate data structures of the Constant Pool are read at operation 608. Next, at operation 610, the corresponding constant value is determined based on the constant information read at operation 608. As will appreciated, other operations can be performed, for example, if necessary, byte alignment can be performed at operation 610. Finally, at operation 612 the constant value determined at operation 610 is written into a Java data stream, for example, the Java data stream 204 of Fig. 2. It should be noted that corresponding Java Load constant command is written into an appropriate entry of a Java code stream, for example, the Java code stream 202 of Fig. 2.
Fig. 7 illustrates an execution method 700 for executing a Java Load Constant command in accordance with one embodiment of the invention. It should be noted that the execution method 700 can be implemented in a virtual machine in conjunction with an enhanced bytecode representation to allow more efficient run time execution of a Java Load Constant command. For example, the processing method 600 can be used to generate the bytecode streams 200 having the Java code stream 202 and Java data stream 204. Accordingly, The Java Load Constant command can be stored in the code stream while the corresponding Constant parameters value are stored in the data stream.
Initially, at operation 702, the Java Load Constant command is fetched from the code stream. For example, referring back to Fig. 2, the bytecode 206 of the Java code stream 206 (Java command A), representing a Java Load Constant command is fetched from the Java code stream 202. Next, at operation 704, a pointer to the Java code stream is incremented to point to the
next command in the Java code stream. Referring again to Fig. 2, a pointer to the Java code stream 206 is incremented to point to the next command in the Java code stream, namely, code stream 206 (Java command B). Following incrementing the pointer at operation 704, the execution method 700 proceeds to operation 706 where it is determined how many bytecodes corresponding to the Constant parameter value needs to be fetched from the Java data stream. As will appreciated this determination can be made based on the Constant's type (e.g., double, integer, float, etc.). Accordingly, at operation 708, the appropriate number of bytes which correspond to the Constant parameter value are fecthed.
After the appropriate constant value is fetched, at operation 710, the pointer to the data command stream is incremented to point to the appropriate position in the data stream. As will be appreciated, the pointer to the data stream can be updated based on the type of the Load constant command (i.e., based on the number of bytecodes appropriated for the data associated with the command). Finally, at operation 712, the Constant Load command is executed, for example, the appropriate Constant value command in pushed on the stack.
The many features and advantages of the present invention are apparent from the written description, and thus, it is intended by the appended claims to cover all such features and advantages of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation as illustrated and described. Hence, all suitable modifications and equivalents may be resorted to as falling within the scope of the invention.
What is claimed is:
Claims
1. A method of creating data structures suitable for use by a virtual machine to execute a Java Load Constant instruction, the method comprising: converting one or more Java bytecodes representing a Java Load
Constant instruction in a single stream, to a represention of the Java Load Constant command in a pair of Java bytecode streams, the pair of Java bytecode streams including: a Java code stream having one or more Java bytecodes representing the Java Load Constant command, and a Java data stream with one or more Java bytecodes representing data associated with the Java Load Constant command in the Java code stream.
2. A method as recited in claim 1, wherein said converting comprises: constructing a Constant Pool index into a Constant Pool associated with the Java Load Constant command; reading the appropriate structures of the Constant Pool index based on the constructed Constant Pool index; determining the corresponding Constant Value; and writing a representation of the determined constant value into one or more Java bytecodes of a stream of Java bytecodes.
3. A method as recited in claim 2, wherein said converting further comprises: fetching a first bytecode of a Constant Pool index associated with the
Java Load Constant command; fetching a second bytecode of the Constant Pool index associated with the Java Load Constant command; and wherein said constructing of the Constant Pool index into a Constant Pool operates to determine an index based on said fetching of the first and the second bytecodes.
4. A method as recited in claim 3, wherein said converting further comprises: writing a representation of the Java Load Constant command into one or more Java bytecodes of a stream of another Java bytecodes.
5. A method as recited in claim 1, wherein the representation of the Java Load Constant command represents a numeric constant value.
6. A method as recited in claim 1, wherein each bytecode can be one or more bytes.
7. In an object oriented programming environment, a data structure for containing a load constant computer executable command and data associated with the load constant computer executable command, the data structure suitable for use by a virtual machine and comprising: a code portion having a load constant computer executable command; and a data stream having data corresponding to the load constant computer executable command.
8. A data structure as recited in claim 7, wherein the code portion does not include any data associated with the load constant computer executable command and the data portion does not include a load constant computer executable command.
9. A data structure as recited in claim 8, wherein the code portion is a Java code stream that includes a Java Load Constant command represented as one or more Java bytecodes, and the data portion is a Java data stream that includes the data associated with the Java Load Constant command represented as one or more bytecodes.
10. A data structure as recited in claim 9, wherein each bytecode can be one or more bytes.
11. In an object oriented programming environment, a method of executing load constant computer instructions on a virtual machine, the method comprising: fetching a load constant command from a stream; fetching from another stream data associated with the load constant command; and executing the load constant command with the associated data after the associated has been fetched.
12. A method as recited in claim 11, wherein the load constant command is a Java Load Constant command.
13. A method as recited in claim 12, wherein the load constant command is a Java Load Constant command; wherein the code stream includes one or more Java bytecodes representing the Java Load Constant command and the data stream includes one or more Java bytecodes representing data associated with the Java Load Constant command in the Java code stream.
14. A method as recited in claim 13, wherein the method further comprises: determining how many bytecodes represent data associated with the Java Load Constant command; incrementing a pointer to the Java code stream; and incrementing a pointer to the Java data stream.
15. A method as recited in claim 14, wherein said execution of the Java Load Constant command operates to push a constant value on a stack.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP01981653A EP1405180A2 (en) | 2000-10-31 | 2001-10-17 | Methods and apparatus for numeric constant value inlining in virtual machines |
AU2002213283A AU2002213283A1 (en) | 2000-10-31 | 2001-10-17 | Methods and apparatus for numeric constant value inlining in virtual machines |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/703,356 US6978456B1 (en) | 2000-10-31 | 2000-10-31 | Methods and apparatus for numeric constant value inlining in virtual machines |
US09/703,356 | 2000-10-31 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2002037274A2 true WO2002037274A2 (en) | 2002-05-10 |
WO2002037274A3 WO2002037274A3 (en) | 2004-02-12 |
Family
ID=24825046
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2001/032306 WO2002037274A2 (en) | 2000-10-31 | 2001-10-17 | Methods and apparatus for numeric constant value inlining in virtual machines |
Country Status (4)
Country | Link |
---|---|
US (1) | US6978456B1 (en) |
EP (1) | EP1405180A2 (en) |
AU (1) | AU2002213283A1 (en) |
WO (1) | WO2002037274A2 (en) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7096466B2 (en) * | 2001-03-26 | 2006-08-22 | Sun Microsystems, Inc. | Loading attribute for partial loading of class files into virtual machines |
US7543288B2 (en) | 2001-03-27 | 2009-06-02 | Sun Microsystems, Inc. | Reduced instruction set for Java virtual machines |
US7406687B1 (en) * | 2004-03-17 | 2008-07-29 | Sun Microsystems, Inc. | Sharing runtime representation of software component methods across component loaders |
US11809839B2 (en) | 2022-01-18 | 2023-11-07 | Robert Lyden | Computer language and code for application development and electronic and optical communication |
Family Cites Families (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4086626A (en) | 1974-10-07 | 1978-04-25 | Fairchild Camera And Instrument Corporation | Microprocessor system |
US4910731A (en) | 1987-07-15 | 1990-03-20 | Hitachi, Ltd. | Switching system and method of construction thereof |
US6285048B1 (en) | 1991-12-13 | 2001-09-04 | Symetrix Corporation | Barium strontium titanate integrated circuit capacitors and process for making the same |
EP0546682A3 (en) | 1991-12-12 | 1993-12-08 | Ibm | Parent class shadowing |
US5694546A (en) | 1994-05-31 | 1997-12-02 | Reisman; Richard R. | System for automatic unattended electronic information transport between a server and a client by a vendor provided transport software with a manifest list |
US6151618A (en) | 1995-12-04 | 2000-11-21 | Microsoft Corporation | Safe general purpose virtual machine computing system |
US5899997A (en) | 1996-04-03 | 1999-05-04 | Transparency Systems, Inc. | Object-oriented query mechanism |
US6151703A (en) | 1996-05-20 | 2000-11-21 | Inprise Corporation | Development system with methods for just-in-time compilation of programs |
US5815718A (en) | 1996-05-30 | 1998-09-29 | Sun Microsystems, Inc. | Method and system for loading classes in read-only memory |
US5920720A (en) | 1997-02-25 | 1999-07-06 | Microsoft Corporation | Efficient computer based virtual machine object structure |
US6003038A (en) | 1997-03-31 | 1999-12-14 | Sun Microsystems, Inc. | Object-oriented processor architecture and operating method |
US6317872B1 (en) | 1997-07-11 | 2001-11-13 | Rockwell Collins, Inc. | Real time processor optimized for executing JAVA programs |
US6442753B1 (en) | 1997-08-28 | 2002-08-27 | International Business Machines Corporation | Apparatus and method for checking dependencies among classes in an object-oriented program |
US6072953A (en) | 1997-09-30 | 2000-06-06 | International Business Machines Corporation | Apparatus and method for dynamically modifying class files during loading for execution |
US6163780A (en) * | 1997-10-01 | 2000-12-19 | Hewlett-Packard Company | System and apparatus for condensing executable computer software code |
EP0941508B1 (en) | 1997-10-02 | 2007-01-17 | Koninklijke Philips Electronics N.V. | Variable instruction set computer |
US6349344B1 (en) | 1997-12-16 | 2002-02-19 | Microsoft Corporation | Combining multiple java class files into a run-time image |
US6081665A (en) * | 1997-12-19 | 2000-06-27 | Newmonics Inc. | Method for efficient soft real-time execution of portable byte code computer programs |
US6704803B2 (en) | 1998-01-26 | 2004-03-09 | International Business Machines Corporation | Method and system for distributing data events over an information bus |
US6330709B1 (en) * | 1998-03-30 | 2001-12-11 | International Business Machines Corporation | Virtual machine implementation for shared persistent objects |
US6096095A (en) | 1998-06-04 | 2000-08-01 | Microsoft Corporation | Producing persistent representations of complex data structures |
US6434694B1 (en) | 1998-06-29 | 2002-08-13 | Sun Microsystems, Inc. | Security for platform-independent device drivers |
US6496871B1 (en) | 1998-06-30 | 2002-12-17 | Nec Research Institute, Inc. | Distributed agent software system and method having enhanced process mobility and communication in a computer network |
US6205578B1 (en) | 1998-08-14 | 2001-03-20 | Ati International Srl | Interpreter for stack-based languages |
US6446084B1 (en) | 1998-09-22 | 2002-09-03 | Sun Microsystems, Inc. | Optimizing symbol table lookups in platform-independent virtual machines |
US6202208B1 (en) | 1998-09-29 | 2001-03-13 | Nortel Networks Limited | Patching environment for modifying a Java virtual machine and method |
GB2343021A (en) | 1998-10-19 | 2000-04-26 | Ibm | Class loading model for object oriented programming |
US6332215B1 (en) | 1998-12-08 | 2001-12-18 | Nazomi Communications, Inc. | Java virtual machine hardware for RISC and CISC processors |
US6338160B1 (en) * | 1998-12-08 | 2002-01-08 | Nazomi Communications, Inc. | Constant pool reference resolution method |
US6571388B1 (en) | 1999-03-09 | 2003-05-27 | Hewlett-Packard Development Company, L.P. | Building a custom software environment including pre-loaded classes |
US6553565B2 (en) | 1999-04-23 | 2003-04-22 | Sun Microsystems, Inc | Method and apparatus for debugging optimized code |
US6393491B1 (en) | 1999-04-26 | 2002-05-21 | Sun Microsystems, Inc. | Method and apparatus for dispatch table construction |
US6557023B1 (en) | 1999-05-28 | 2003-04-29 | Sun Microsystems, Inc. | Method and apparatus for avoiding array class creation in virtual machines |
US6584612B1 (en) | 1999-07-15 | 2003-06-24 | International Business Machines Corporation | Transparent loading of resources from read-only memory for an application program |
US6738977B1 (en) * | 2000-05-31 | 2004-05-18 | International Business Machines Corporation | Class sharing between multiple virtual machines |
FR2918958B1 (en) | 2007-07-18 | 2009-10-16 | Normandie Appats Soc Par Actio | FILLING DEVICE AND METHOD FOR TRAY |
-
2000
- 2000-10-31 US US09/703,356 patent/US6978456B1/en not_active Expired - Lifetime
-
2001
- 2001-10-17 WO PCT/US2001/032306 patent/WO2002037274A2/en active Application Filing
- 2001-10-17 AU AU2002213283A patent/AU2002213283A1/en not_active Abandoned
- 2001-10-17 EP EP01981653A patent/EP1405180A2/en not_active Withdrawn
Non-Patent Citations (2)
Title |
---|
DAHM M: "Byte code engineering" JIT'99. JAVA-INFORMATION-TAG 1999, PROCEEDINGS OF JIT'99: JAVA-INFORMATIONS-TAGE, DUSSELDORF, GERMANY, 20-21 SEPT. 1999, pages 267-277, XP002262007 1999, Berlin, Germany, Springer-Verlag, Germany ISBN: 3-540-66464-5 * |
MEYER J AND DOWNING T: "Java Virtual Machine" [Online] March 1997 (1997-03) , O'REILLY ASSOCIATES XP002262008 ISBN: 1-56592-194-1 Retrieved from the Internet: <URL: www.oreilly.com/catalog/javavm/> [retrieved on 2003-11-19] the whole document * |
Also Published As
Publication number | Publication date |
---|---|
US6978456B1 (en) | 2005-12-20 |
AU2002213283A1 (en) | 2002-05-15 |
WO2002037274A3 (en) | 2004-02-12 |
EP1405180A2 (en) | 2004-04-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7941802B2 (en) | Reduced instruction set for java virtual machines | |
US7644402B1 (en) | Method for sharing runtime representation of software components across component loaders | |
CN107924326B (en) | Overriding migration methods of updated types | |
US11249758B2 (en) | Conditional branch frame barrier | |
US10606614B2 (en) | Container-based language runtime using a variable-sized container for an isolated method | |
US7020874B2 (en) | Techniques for loading class files into virtual machines | |
US7406687B1 (en) | Sharing runtime representation of software component methods across component loaders | |
US6996813B1 (en) | Frameworks for loading and execution of object-based programs | |
US20030079202A1 (en) | Exception handling in java computing environments | |
US6799185B2 (en) | Frameworks for accessing Java class files | |
US6901591B1 (en) | Frameworks for invoking methods in virtual machines | |
US7096466B2 (en) | Loading attribute for partial loading of class files into virtual machines | |
US6948156B2 (en) | Type checking in java computing environments | |
US6957428B2 (en) | Enhanced virtual machine instructions | |
US6978456B1 (en) | Methods and apparatus for numeric constant value inlining in virtual machines | |
EP1481320B1 (en) | Two tier clusters for representation of objects in java programming environments | |
US7181724B2 (en) | Representation of Java® data types in virtual machines | |
US20040015873A1 (en) | Identifying references to objects during bytecode verification | |
US6934726B2 (en) | Storing and retrieving of field descriptors in Java computing environments | |
US6961933B2 (en) | Representation of Java data types in virtual machines | |
US11513954B2 (en) | Consolidated and concurrent remapping and identification for colorless roots | |
WO2003019364A1 (en) | Frameworks for efficient representation of string objects in java programming environments |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2001981653 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
WWP | Wipo information: published in national office |
Ref document number: 2001981653 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: JP |