Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1999-02-05
2001-01-09
Hafiz, Tariq R. (Department: 2762)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C707S793000, C717S152000, C717S152000
Reexamination Certificate
active
06173442
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention is directed to compiling and interpreting computer programs. It particularly concerns synchronization between execution threads.
FIG. 1
depicts a typical computer system
10
. A microprocessor
11
receives data, and instructions for operating on them, from on-board cache memory or further cache memory
12
, possibly through the mediation of a cache controller
13
, which can in turn receive such data from system read/write memory (“RAM”)
14
through a RAM controller
15
, or from various peripheral devices through a system bus
16
.
The RAM
14
's data and instruction contents will ordinarily have been loaded from peripheral devices such as a system disk
17
. Other sources include communications interface
18
, which can receive instructions and data from other computer systems.
The instructions that the microprocessor executes are machine instructions. Those instructions are ultimately determined by a programmer, but it is a rare programmer who is familiar with the specific machine instructions in which his efforts eventually result. More typically, the programmer writes higher-level-language “source code” from which a computer software-configured to do so generates those machine instructions, or “object code.”
FIG. 2
represents this sequence. FIG.
2
's block
20
represents a compiler process that a computer performs under the direction of compiler object code. That object code is typically stored on the system disk
17
or some other machine-readable medium and by transmission of electrical signals is loaded into RAM
14
to configure the computer system to act as a compiler. But the compiler object code's persistent storage may instead be in a server system remote from the machine that performs the compiling. The electrical signals that carry the digital data by which the computer systems exchange the code are exemplary forms of carrier waves transporting the information.
The compiler converts source code into further object code, which it places in machine-readable storage such as RAM
14
or disk
17
. A computer will follow that object code's instructions in performing an application
21
that typically generates output from input. The compiler
20
is itself an application, one in which the input is source code and the output is object code, but the computer that executes the application
21
is not necessarily the same as the one that performs the compiler process.
The source code need not have been written by a human programmer directly. Integrated development environments often automate the source-code-writing process to the extent that for many applications very little of the source code is produced “manually.” As will be explained below, moreover, the “source” code being compiled may sometimes be low-level code, such as the byte-code input to the Java™ virtual machine, that programmers almost never write directly. (Sun, the Sun Logo, Sun Microsystems, and Java are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries.) Moreover, although
FIG. 2
may appear to suggest a batch process, in which all of an application's object code is produced before any of it is executed, the same processor may both compile and execute the code, in which case the processor may execute its compiler application concurrently with—and, indeed, in a way that can be dependent upon—its execution of the compiler's output object code.
So the sequence of operations by which source code results in machine-language instructions may be considerably more complicated than one may infer from FIG.
2
. To give a sense of the complexity that can be involved, we discuss by reference to
FIG. 3
an example of one way in which various levels of source code can result in the machine instructions that the processor executes. The human application programmer produces source code
22
written in a high-level language such as the Java programming language. In the case of the Java programming language, a compiler
23
converts that code into “class files.” These predominantly include routines written in instructions, called “byte codes”
24
, for a “virtual machine” that various processors can emulate under appropriate instructions. This conversion into byte codes is almost always separated in time from those codes' execution, so that aspect of the sequence is depicted as occurring in a “compile-time environment”
25
separate from a “run-time environment”
26
, in which execution occurs.
Most typically, the class files are run by a processor under control of a computer program known as a virtual machine
27
, whose purpose is to emulate a machine from whose instruction set the byte codes are drawn. Much of the virtual machine's action in executing these codes is most like what those skilled in the art refer to as “interpreting,” and
FIG. 3
shows that the virtual machine includes an “interpreter”
28
for that purpose. The resultant instructions typically involve calls to a run-time system
29
, which handles matters such as loading new class files as they are needed and performing “garbage collection,” i.e., returning allocated memory to the system when it is no longer needed.
Many virtual-machine implementations also actually compile the byte codes concurrently with the resultant object code's execution, so
FIG. 3
depicts the virtual machine as additionally including a “just-in-time” compiler
30
. It may be that the resultant object code will make low-level calls to the run-time system, as the drawing indicates. In any event, the code's execution will include calls to the local operating system
31
.
It is not uncommon for a virtual-machine implementation both to compile and to interpret different parts of the same byte-code program. And, although the illustrated approach of first compiling the highlevel code into byte codes is typical, the Java programming language is sometimes compiled directly into native machine code. So there is a wide range of mechanisms by which source code—whether high-level code or byte code—can result in the actual native machine instructions that the hardware processor executes. The teachings to be set forth below can be used in all of them, many of which, as was just explained, do not fit neatly into either the compiler or interpreter category. So we will adopt the term compiler/interpreter to refer to all such mechanisms, whether they be compilers, interpreters, hybrids thereof, or combinations of any or all of these.
In actual operation, the typical computer program does not have exclusive control over the machine whose operation it directs; a typical user concurrently runs a number of application programs. Of course, a computer that is not a multiprocessor machine can at any given instant be performing the instructions of only one program, but a typical multi-tasking approach employed by single-processor machines is for each concurrently running program to be interrupted from time to time to allow other programs to run, with the rate of such interruption being high enough that the programs' executions appear simultaneous to the human user.
The task of scheduling different applications programs' executions typically falls to the computer's operating system. In this context, the different concurrently running programs are commonly referred to as different “processes.” In addition to scheduling, the operating system so operates the computer that the various processes' physical code, data, and stack spaces do not overlap. So one process cannot ordinarily interfere with another. The only exceptions to this rule occur when a process specifically calls an operating-system routine (“makes a system call”) intended for inter-process communication.
The operating system's scheduling function can be used to divide processor time not only among independent processes but also among a single process's different “threads of execution.” Different execution threads are like different processes in that the
Agesen Ole
Detlefs David L.
Garthwaite Alex
Knippel Ross C.
Ramakrishna Y. Srinivas
Cesari and McKenna LLP
Hafiz Tariq R.
Nguyen-Ba Hoang-Vu Antony
Sun Microsystems Inc.
LandOfFree
Busy-wait-free synchronization does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Busy-wait-free synchronization, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Busy-wait-free synchronization will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2550872