Java hardware accelerator using thread manager

Details Java hardware accelerator using thread manager Java hardware accelerator using thread manager

2001-05-25

2004-11-30

Khatri, Anil (Department: 2124)

Data processing: software development, installation, and managem

Software program development tool

Translation of code

C717S118000, C717S147000

Reexamination Certificate

active

06826749

ABSTRACT:

BACKGROUND OF THE INVENTION
Java™ is an object-orientated 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.
Java's 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 translates 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 bytecode 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.
The disadvantage of using bytecodes is execution speed. System specific programs that run directly on the hardware from which they are compiled, run significantly faster that Java bytecodes, which must be processed by the Java Virtual Machine. The processor must both convert the Java bytecodes into native instructions in the Java Virtual Machine and execute the native instructions.
One way to speed up the Java Virtual Machine is by techniques such as the “Just in Time” (JIT) interpreter, and even faster interpreters known as “Hot Spot JITs” interpreters. The JIT versions all result in a JIT compile overhead to generate native processor instructions. These JIT interpreters also result in additional memory overhead.
The slow execution speed of Java and overhead of JIT interpreters have made it difficult for consumer appliances requiring local-cost solutions with minimal memory usage and low energy consumption to run Java programs. The performance requirements for existing processors using the fastest JITs more than double to support running the Java Virtual Machine in software. The processor performance requirements could be met by employing superscalar processor architectures or by increasing the processor clock frequency. In both cases, the power requirements are dramatically increased. The memory bloat that results from JIT techniques, also goes against the consumer application requirements of low cost and low power.
The Java Virtual Machine has two options to support multi-threaded execution of Java programs: Native threads (one to one threads), which use the operating systems support for multi-threading, and Green threads (many to one threads) which are managed entirely within the Java Virtual Machine entirely outside the operating system purview. The implementation of Green threads is done in one of two ways; in the first a thread gets control of the Java Virtual Machine until it gives it up, this type of threading requires that all threads be “well behaved” i.e. they give up control at various point in their execution if there is any other work waiting. The second approach lets each thread execute a number of bytecodes then the Java Virtual Machine switches to another thread if one is waiting, i.e. the thread doesn't need to be “well behaved”.
It is desired to have an improved system for implementing Java programs that provides a low-cost solution for running Java programs for consumer appliances.
SUMMARY OF THE INVENTION
The present invention comprises a thread lifetime unit in the hardware unit of a Java hardware accelerator system. The thread lifetime unit keeps track of when the current thread should halt processing in the system. Some implementation of green threads allocates to each thread a number of bytecodes to execute. The thread lifetime unit allows hardware unit to keep track of the number of bytecodes remaining in the active thread.
The present invention preferably uses a register to store the number of bytecodes to run for each thread. This value can be loaded into a counter which is decremented as instructions are issued. When the decrementing counter reaches zero or a negative value, the hardware accelerator passes control to the thread manager portion of Java Virtual Machine. In one preferred embodiment, the values in the CPU register file are cleared and written out to the memory. These include any operand stack values stored in the register file and the like. When the transfer of control is given to the Java Virtual Machine, the Java Virtual Machine is loaded into the CPU which loads into the system. In one embodiment, once the thread bytecode count reaches zero or below, the hardware accelerator implements microcode that causes the storing of the value stored in the CPU register file and the loading of the Java Virtual Machine.
In one embodiment, a single step-unit of the hardware unit allows for the production of debugger indications along bytecode boundaries. In one embodiment, a debugger indication, such as a soft interrupt, is produced after each group of register-based instruction(s) translated from a single bytecode. Instruction level parallelism is can be inhibited during single-step operations. Preferably, debugger indications are also inserted after a jump in the CPU program counter.


REFERENCES:
patent: 4524416 (1985-06-01), Stanley et al.
patent: 4587612 (1986-05-01), Fisk et al.
patent: 4631663 (1986-12-01), Chilinski et al.
patent: 4763255 (1988-08-01), Hopkins et al.
patent: 4783738 (1988-11-01), Li et al.
patent: 4860191 (1989-08-01), Nomura et al.
patent: 4961141 (1990-10-01), Hopkins et al.
patent: 5077657 (1991-12-01), Cooper et al.
patent: 5113522 (1992-05-01), Dinwiddie, Jr. et al.
patent: 5136696 (1992-08-01), Beckwith et al.
patent: 5142681 (1992-08-01), Driscoll et al.
patent: 5163139 (1992-11-01), Haigh et al.
patent: 5193180 (1993-03-01), Hastings
patent: 5201056 (1993-04-01), Daniel et al.
patent: 5218711 (1993-06-01), Yoshida
patent: 5241636 (1993-08-01), Kohn
patent: 5313614 (1994-05-01), Goettelmann et al.
patent: 5333296 (1994-07-01), Bouchard et al.
patent: 5335344 (1994-08-01), Hastings
patent: 5355460 (1994-10-01), Eickemeyer et al.
patent: 5430862 (1995-07-01), Smith et al.
patent: 5481684 (1996-01-01), Richter et al.
patent: 5490256 (1996-02-01), Mooney et al.
patent: 5535329 (1996-07-01), Hastings
patent: 5542059 (1996-07-01), Blomgren
patent: 5574927 (1996-11-01), Scantlin
patent: 5577233 (1996-11-01), Goettelmann et al.
patent: 5619666 (1997-04-01), Coon et al.
patent: 5634118 (1997-05-01), Blomgren
patent: 5650948 (1997-07-01), Gafter
patent: 5659703 (1997-08-01), Moore et al.
patent: 5668999 (1997-09-01), Gosling
patent: 5692170 (1997-11-01), Isaman
patent: 5748964 (1998-05-01), Gosling
patent: 5761477 (1998-06-01), Wahbe et al.
patent: 5764908 (1998-06-01), Shoji et al.
patent: 5768593 (1998-06-01), Walters et al.
patent: 5774868 (1998-06-01), Cragun et al.
patent: 5778178 (1998-07-01), Arunachalam
patent: 5781750 (1998-07-01), Blomgren et al.
patent: 5784584 (1998-07-01), Moore et al.
patent: 5805895 (1998-09-01), Breternitz, Jr. et al.
patent: 5809336 (1998-09-01), Moore et al.
patent: 5838165 (1998-11-01), Chatter
patent: 5875336 (1999-02-01), Dichol et al.
patent: 5889996 (1999-03-01), Adams
patent: 5898850 (1999-04-01), Dickol et al.
pa

Affiliated with

Also associated with

Rating

Java hardware accelerator using thread manager does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Java hardware accelerator using thread manager, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Java hardware accelerator using thread manager will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3280194