Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
2000-01-20
2002-01-08
Powell, Mark R. (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S152000, C717S152000, C717S152000, C709S241000
Reexamination Certificate
active
06338160
ABSTRACT:
BACKGROUND OF THE INVENTION
Java™ is an object oriented programming language developed by Sun Microsystems. The Java language is small, simple and portable across platforms and operating systems, both at the source and at the binary level. This makes the Java programming language very popular on the Internet.
Platform independence and code compaction are the most significant advantages of Java over conventional programming languages. In conventional programming languages, the source code of a program is sent to a compiler which interprets the program into machine code or processor instructions. The processor instructions are native to the system's processor. If the code is compiled on an Intel-based system, the resulting program will only run on other Intel-based systems. If it is desired to run the program on another system, the user must go back to the original source code, obtain a compiler for the new processor, and recompile the program into the machine code specific to that other processor.
Java operates differently. The Java compiler takes a Java program and, instead of generating machine code for a particular processor, generates bytecodes. Bytecodes are instructions that look like machine code, but aren't specific to any processor. To execute a Java program, a bytecode interpreter takes the Java bytecode converts them to equivalent native processor instructions and executes the Java program. The Java byte code interpreter is one component of the Java Virtual Machine.
Having the Java programs in bytecode form means that instead of being specific to any one system, the programs can run on any platform and any operating system as long a Java Virtual Machine is available. This allows a binary bytecode file to be executable across platforms.
Most computer languages, such as C, are compiled languages. All references to objects are resolved before running of the program. Because Java is run from the Virtual Machine, it is possible to operate without having all of the references resolved. The advantage of this arrangement is that it allows for operation of the program or the program is completely downloaded from another location, such as off the Internet.
For example, a Java instruction that invokes ‘ABC’ may be run when the Class ‘ABC’ is not loaded into memory. The Invoke instruction must cause the reference to be resolved. This can take a considerable amount of time to resolve the reference each time that the instruction is run. Instructions that reference the constant pool, such as invoke instructions, often can have this problem.
One version of a Java Virtual Machine can reduce this problem with the use of quick variants of bytecodes. The quick variants of bytecodes are not officially part of the Java Virtual Machine specification and are invisible outside specific Java Virtual Machine implementations. When the quick optimization is turned on, each non-quick bytecode resolves the specified item in the constant pool, signals if an item in the constant pool could not be resolved for some reason, turns itself into the quick variant of itself, and then performs its intended operation. Thus, the bytecode is written over by the quick bytecode variant. The next time the code is run, the system assumes that the item in the constant pool has already been resolved, and that this resolution did not produce any errors. The system can then simply performs the intended operation on the resolved item. A discussion of such a system is described in Gosling, U.S. Pat. No. 5,367,685 incorporated herein by reference.
This optimization cannot be run from read-only memory (ROM) because the optimization requires writing over the normal bytecode with its quick variant. Running a program from read-only memory could be quite useful in some circumstances particularly for embedded systems. It is desired to have an improved method of resolving the constant pool references to avoid some of the problems of the prior art.
SUMMARY OF THE INVENTION
The present invention, a Resolution Data Field, is used in the constant pool entries. When a reference to the constant pool is done by a bytecode, the data in the resolution data field acts as an index to a jump table to determine the native code to be run next. The first time a bytecode, which references the constant pool, is run, the data in the resolution data field causes the system to jump to code to resolve the reference. This resolution code could search for the object reference bytecode within the memory. If the object is not within the memory, the system can load the object into memory and then operate in the normal bytecode operation. This system also sets the resolution data field, so as to indicate that the reference has been resolved. An indication of the location of the resolved object is also stored within the constant pool entry. The next time the bytecode is operated on, the data in the resolution data field acts as an index to the jump table which causes a jump to operation code that assumes that the resolution has been resolved. In this way, after the first operation of the bytecode, searching for the object in memory need not be done.
The advantage of the present invention is that it is not required to write the bytecode over with another value, such as a quick bytecode. Thus, the bytecode could be run from read-only memory. The advantage of using a jump table in the preferred embodiment is that the data in the resolution data field need only be added to a base value rather than compared to a value. In most current processors, the add step can be done quicker than a compare step. In an alternate embodiment, a comparison of the data in the resolution data field could be done.
REFERENCES:
patent: 5265206 (1993-11-01), Shakelford et al.
patent: 5307492 (1994-04-01), Benson
patent: 5313614 (1994-05-01), Goettelmann et al.
patent: 5367685 (1994-11-01), Gosling
patent: 5584026 (1996-12-01), Knudsen et al.
patent: 5740441 (1998-04-01), Yellin et al.
patent: 5903899 (1999-05-01), Steele, Jr.
patent: 5920720 (1999-07-01), Toutonghi et al.
patent: 5953736 (1999-09-01), O'Connor et al.
patent: 5966542 (1999-10-01), Tock
patent: 6052526 (2000-04-01), Chatt
patent: 6067577 (2000-05-01), Beard
patent: 6071317 (2000-06-01), Nagel
patent: 6085198 (2000-07-01), Skinner et al.
patent: 6151702 (2000-11-01), Overturf et al.
patent: 6275984 (2001-08-01), Morita
L. Lemay and C. L. Perkins, “Teach Yourself JAVA 1.1 in 21 Days,” second edition, pp. 621-675 (1997).
Dasgupta Chitrabhanu
Patel Mukesh K.
Burns Doane , Swecker, Mathis LLP
Das Chameli Chaudhuri
Nazomi Communications Inc.
Powell Mark R.
LandOfFree
Constant pool reference resolution method does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Constant pool reference resolution method, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Constant pool reference resolution method will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2843391