|Publication number||US8176286 B2|
|Application number||US 10/781,867|
|Publication date||May 8, 2012|
|Filing date||Feb 20, 2004|
|Priority date||Mar 26, 2003|
|Also published as||US20040193828|
|Publication number||10781867, 781867, US 8176286 B2, US 8176286B2, US-B2-8176286, US8176286 B2, US8176286B2|
|Inventors||Edward Colles Nevill|
|Original Assignee||Edward Colles Nevill|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (62), Non-Patent Citations (52), Classifications (7), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
The present invention relates memory recycling processes or “garbage collection” in computer systems.
2. Description of the Prior Art
Many modern programming languages allow the programmer to dynamically allocate and reclaim memory. Dynamically allocated storage is often automatically managed during execution of a computer program using a process known as garbage collection. A particular example of a programming language that uses garbage collection is Java. Java is an object-oriented programming language. In object-oriented programming systems a “class” can provide a template for the creation of “objects” (i.e. data items) having characteristics of that class. Objects are typically created dynamically (in Java, using an operator called the “new” operator) during program execution. Methods associated with a class typically operate on objects of the same class.
Java source code is compiled to produce runtime code known as bytecode. However the bytecode is not the binary code of any existing computer. Rather, Java bytecode is an architecture-neutral machine code that can be interpreted to run on any specific computer. A Java program is executed by running an interpreter program called a Java Virtual Machine (JVM). The JVM reads the bytecode program and interprets or translates it to the native instruction set of the computer on which it is installed. The bytecode will run on any computer platform on which a JVM is installed without any need for recompilation of the source code. A process called “bytecode verification” is used as part of the linking of a Java program, prior to execution. The verification process ensures that the bytecode adheres to a set of rules defining well-formed Java class files. For example, if the verifier fails to confirm that a method in a class file pushes two integers onto an operand stack before executing an “iadd” (i.e. integer addition) instruction, the verifier will reject that class file.
Java allows multi-threaded execution of processes. A thread (abbreviation for “thread of control”) is a sequence of execution within a process. A thread is a lightweight process to the extent that it does not have its own address space but uses the memory and other resources of the process in which it executes. There may be several threads in one process and the JVM manages the threads and schedules them for execution. Threads allow switching between several different functions executing simultaneously within a single program. When the JVM switches from running one thread to another thread, a context switch within the same address space is performed.
Garbage collection relieves programmers from the burden of explicitly freeing allocated memory and helps ensure program integrity by reducing the likelihood of incorrectly deallocating memory. However, a potential disadvantage of garbage collection is that at unpredictable times, a potentially large amount of garbage collection processing will be initiated when there is a need for more memory. In Java this problem is sometimes ameliorated by the multi-threaded nature of the system, which can allow the garbage collection to run in parallel with the user code. A garbage collection algorithm must perform two basic functions. Firstly, it must determine which objects are suitable for reclamation as garbage and secondly it must reclaim the memory space used by the garbage objects and make it available to the program. Garbage is defined as memory no longer accessible to the program.
The first stage of this process is typically performed by defining a set of “roots” and determining reachability from those roots. Objects that are not reachable via the roots are considered to be garbage since there is no way for the program to access them so they cannot affect the future course of program execution.
In the JVM the set of roots is implementation-dependent but will always include any object references in the local variables. The JVM comprises four basic components: registers; stack memory; heap memory; and a method area. All Java objects reside in heap memory and it is heap memory that is garbage-collected. Different pieces of storage can be allocated from and returned to the heap in no particular order. Memory allocated with the “new” operator in Java comes from the heap. The heap is shared among all of the threads. The method area is where the bytecodes reside. A program counter, which points to (i.e. contains the address of) some byte in the method area is used to keep track of the thread of execution. The Java stack is used to: store parameters for and results of bytecode instructions; to pass parameters to and return parameters from methods; and to keep the state of each method invocation. The JVM has few registers because the bytecode instructions operate primarily on the stack. The stack is so-called because it operates on a last-in-first-out basis. The state of a method invocation is called its “stack frame”. Each method executing in a thread of control allocates a stack frame. When the method returns the stack frame is discarded.
In short, in the JVM all objects reside on the heap, the local variables typically reside on the stack and each thread of execution has its own stack. Each local variable is either an object reference or a primitive type (i.e. non-reference) such as an integer, character or floating point number. Therefore the roots include every object reference on the stack of every thread.
There are many known garbage collection algorithms including reference counting, mark and sweep and generational garbage collection algorithms. Details of these and other garbage collection algorithms are described in “Garbage Collection, Algorithms for Automatic Dynamic Memory Management” by Richard Jones and Raphaels Lins, published by John Wiley & Sons 1996.
Garbage collection algorithms may be categorised as either precise (exact) or imprecise (conservative) in how they identify and keep track of reference values in sources of references such as stacks. An imprecise garbage collector knows that a particular region of memory (e.g. a slot in a stack frame) may contain a reference but does not know where a given value stored in that particular region is a reference. The imprecise garbage collector must therefore keep any potential reference object alive. A disadvantage of this known technique is that a primitive type may be erroneously identified as a reference by the imprecise garbage collector if the variable value happens to coincide with a memory address. This means that a garbage object will be wrongly considered to be “live” by the imprecise collector, because an object-reference lookalike (i.e. the primitive type) referred to it.
Precise garbage collectors, on the other hand, can discriminate between a genuine object-reference and a primitive-type masquerading as a reference. Accordingly, precise garbage collectors alleviate the problem suffered by imprecise collectors of failure to garbage collect objects corresponding to object-reference lookalikes. To perform precise garbage collection, the system must be able to clearly distinguish between references and non-references. For objects, a “layout map” can be produced for each object describing which data fields of the object contain references. Reference identification for objects is relatively simple since the layout map will be invariant for the entire lifetime of the object and all objects of the same type have identical layout maps. However, the reference identification process is more complex for stack frames because the layout of a stack frame is likely to change during its lifetime. For example a given stack frame slot could be uninitialised at the start of the method, contain an integer for one block of the method and a reference for another block of the method.
There are currently two known methods for storing the information required for implementing precise garbage collection. The first involves building a series of stack maps during the bytecode verification stage. A “stack map” is a data structure that, for each execution point at which garbage collection may occur, represents a snapshot in time of the stack frame indicating the stack frame slots that contain references. Stack maps must be stored for a plurality of execution points in every verified method therefore this method is intensive on Random Access Memory (RAM).
The second involves keeping track of each stack write operation during execution of the verified bytecode and tagging each stack slot to which a reference is written and clearing the stack tag whenever a non-reference value is written to that stack location. This requires that the reference values and non-reference values written to the stack are self-describing i.e. each value has one or more bits used to indicate whether that value is a reference. The tag data itself may be stored either by widening the existing stack to include a tag field or by keeping a parallel stack. This stack-tagging process slows down execution of the program since both the stack and the variable must be marked as a reference or non-reference for each value written to stack.
Accordingly, it will be desirable to provide a precise garbage collection method that is less memory intensive and has less impact on program execution than known methods.
Viewed from one aspect the present invention provides a method of controlling execution of a processing task within a data processing system, said method comprising the steps of:
executing said processing task including allocating memory areas for data storage; and
suspending an actual execution path of said processing task at an execution point to perform memory management, said memory management comprising the steps of:
identifying one or more data items occurring in the course of execution and accessible to said processing task at said execution point which specify reference values pointing to respective ones of said memory areas;
determining a correlation between reference values corresponding to identified data items and memory areas allocated during said execution up to said execution point; and
performing a memory management operation on allocated memory areas in dependence upon said correlation.
To effectively reclaim memory space it is necessary to accurately identify which data items accessible to the processing task are reference values and which data items are non-reference values. Known memory recycling techniques either perform the analysis required to identify references at a verification stage prior to execution of the processing task or continuously monitor data write operations and log whether or not each written data item is a reference value. The invention recognises that the process of reference identification can be made less memory intensive and less processor intensive by performing the reference identification after execution of the processing task has commenced (i.e. post-verification) but only as and when required. The invention employs a technique whereby references are identified dynamically at the execution point at which garbage collection is initiated and does not rely upon previously stored information.
Although the process of identifying operand stack data items which specify reference values could be performed by exhaustively searching all possible execution paths up to the current execution point to find the actual execution path. Preferred embodiments of the invention recognize this is not necessary and operate such that any possible data path, for example the first encountered data path leading to the current execution point, is used to identify which operand stack entries correspond to references. This expedites the path-finding algorithm yet allows stack slots containing references to be reliably identified for any programming language that conforms to relevant constraints on instruction execution.
It will be appreciated that the memory management operation performed by embodiments of the invention could involve for example a tagging operation, a copying operation or a re-allocation operation. However, for preferred embodiments in which the data items are data items of the operand stack, the memory management operation comprises marking all memory areas that are accessible to the processing task either directly or indirectly through the identified data items which specify reference values. Any unmarked memory areas are then collected for re-allocation during subsequent execution of the processing task. Since the references are identified only as and when required, at the execution point at which the memory management operation is performed, such preferred embodiments offer more efficient memory recycling functionality than known garbage collection algorithms.
Although unmarked memory areas could be directly re-allocated during subsequent execution of the programming task, performing compaction of the unmarked memory areas prior to releasing them for re-allocation has the advantage of making available larger contiguous areas of memory to the processing task for re-allocation.
In identifying data items accessible to the processing task which specify references, where those data items represent local variables any local variable associated with a reference along any one of a plurality of possible execution paths could be categorised as a reference value, but its usage is imprecise. However, in preferred embodiments, local variables which are associated with different data types along different execution paths (and hence are of indefinite type) are distinguished from local variables of definite type by scanning the program instructions and categorizing variables as multiple-type, and therefore non-reference. All then possible execution paths up to the current execution point are simulated for each multiple-type variable in turn and the data type(s) at each program instruction for each of the execution paths is determined. The determined data type is then checked for the current execution point and the memory management operation is performed in dependence upon the result of this check. This has the advantage that memory areas associated with multiple-type variables having indefinite type at the current execution point can be effectively claimed for reallocation during the memory management operation. The identification of variables of indefinite type is significantly simplified by first identifying variables of multiple-type and subsequently performing a full data-flow analysis for only the subset of local variables categorised as multiple-type variables.
It will be appreciated that the present invention could be applied to a processing task associated with any computer programming language in which memory is dynamically allocated. However, preferred embodiments perform the processing task in an object-oriented programming language such as Smalltalk or Java. Particularly preferred embodiments perform the processing task in Java. Advantageously, the specification of the Java Virtual Machine means that the program code must adhere to rules which can be directly exploited to considerably simplify the algorithms used to identify which data items, such as local variables or operand stack values, correspond to references.
Viewed from another aspect the present invention provides a data processing apparatus operable to control execution of a processing task within a data processing system, said data processing apparatus comprising:
execution logic operable to execute said processing task including allocating memory areas for data storage; and
task suspension logic operable to suspend an actual execution path of said processing task at an execution point to perform memory management;
reference identifying logic operable to identify one or more data items occurring in the course of execution and accessible to said processing task at said execution point which specify reference values pointing to respective ones of said memory areas;
correlation logic operable to determine a correlation between reference values corresponding to identified data items and memory areas allocated during said execution up to said execution point; and
memory management logic operable to perform a memory management operation on allocated memory areas in dependence upon said correlation.
Viewed from a further aspect the present invention provides a computer program product bearing a computer program for controlling a computer to control execution of a processing task within a data processing system, said computer program comprising:
execution code operable to execute said processing task including allocating memory areas for data storage; and
suspending code operable to suspend an actual execution path of said processing task at an execution point to perform memory management;
reference identifying code operable to identify one or more data items occurring in the course of execution and accessible to said processing task at said execution point which specify reference values pointing to respective ones of said memory areas;
correlating code operable to determine a correlation between reference values corresponding to identified data items and memory areas allocated during said execution up to said execution point; and
memory management code operable to perform a memory management operation on allocated memory areas in dependence upon said correlation.
The above, and other objects, features and advantages of this invention will be apparent from the following detailed description of illustrative embodiments which is to be read in connection with the accompanying drawings.
As shown in
The values that a program can access directly are: those held in processor registers, those held on the program stack (including local variables and temporaries) and those held in global variables. The roots 210 of the computation are those directly accessible values that hold references (such as pointers or handles to a memory address) to heap 220 memory areas. Note that primitive types such as integers are not roots, only references can be roots. The roots 210 represent objects that are always accessible to the program. Root objects may themselves contain reference fields so a chain of references may be formed from each root. An object is considered to be live if any field in another live object references it. All objects that are reachable via the roots are considered live.
Referring back now to the flow chart of
The method according to the present technique differs from known precise garbage collectors in that the reference values are identified by dynamic creation of a separate map corresponding to a snapshot in time at the execution point at which the garbage collection is initiated. Known precise garbage collectors form a plurality of such maps (stack maps) at the verification stage, all of which must be retained in RAM for subsequent use during program execution. There is significant redundancy in this known approach because the stored stack maps that are actually used will depend on the execution point at which garbage collection is initiated by the system. The present technique differs from the known technique in which reference flags are set in the objects themselves and the stack is marked for every write operation during program execution. In particular, although in both techniques the references are identified after execution of the processing task has commenced, according to the present technique the references are identified only as required at the execution points at which garbage collection is initiated.
Garbage collection according to the present technique focuses on more reliable and accurate identification of roots and live objects. This is achieved by performing two distinct strands of analysis: one strand involving finding references in the operand (or expression) stack and another strand involving finding references in a variable array and identifying multiple-type variables. We shall now consider each of these two strands in turn.
The operand stack analysis according to the present technique exploits the following two rules, which are laid down in the JVM specification for Java:
Since the reference table is created dynamically at the point of initiation of the garbage collection algorithm, there is no information available about the actual execution path followed to arrive at the current execution point. Due to the possibility of if/else branches in the method code, there may well be a plurality of possible execution paths via which a current execution point could be arrived at. In general, whether a given stack frame slot contains a reference at a given point in a method execution depends not only on the current execution point but on the control path followed to arrive at that execution point. For example, along one control path a given stack frame slot could be assigned an integer value whereas along another control path that same stack slot could be assigned a reference.
However, applying the above two rules of the JVM specification it can be deduced that it is not essential to determine the actual execution path in order to identify which slots of the stack will contain references. In fact, it is sufficient to find any of the plurality of possible execution paths that lead to the current execution point and use the found path, which is not necessarily the actual execution path, to generate a stack reference table. The execution path should begin at a bytecode index of zero and terminate at the bytecode index corresponding to the current execution point. The stack reference tables (in which stack slots corresponding to references are tagged) for each of the possible execution paths should be identical provided that rules I and II (see above) of the JVM are adhered to.
Referring now to the flow chart of
There is a problem in categorizing certain variables as references or non-references due to the fact that some variables can be of indeterminate type. This situation can arise for example when there are at least two different control paths leading to a common execution point and the variable is assigned an integer value along one control path but a reference value along the alternative control path. According to rule I above, each instruction must only be executed with the appropriate number and type of arguments in the local variable array, regardless of the execution path that leads to invocation of the instruction. It follows that any local variable that is of indeterminate type at the current execution point is not counted as a reference.
In principle, it is possible for a given variable to be used as a non-reference for one block of a method but as a reference value for another block of the same method. This suggests that a step by step analysis through all control paths may be necessary, tracking the type of each variable for each step of program execution. However, the present technique recognises that multiple-type use of a variable is relatively rare in practice, for example, 5% of variables may be of multiple-type. The fact that the fraction of method variables having multiple-type is small is exploited by performing a two-stage variable analysis. The first stage of variable analysis involves a one-pass scan of all bytecodes of the method to determine which variables are identifiable as multiple-type variables. The second stage of variable analysis involves performing a full data-flow analysis but only for the small proportion of variables identified during the first stage as being multiple-type, the preference being that of checking one variable at a time.
Referring to the flow chart of
The method of identifying references in a variable array according to the present technique has the advantage that it prevents variables having indeterminate type at the current execution point being erroneously marked as live objects, i.e. this technique effectively provides precise garbage collection.
The Java Virtual Machine specification states that “heap storage for objects is reclaimed by an automatic storage management system”. The JVM assumes no particular type of automatic storage management system, and the storage management technique may be chosen according to the system requirements of the implementor. However, all popular implementations of Java (such as those by Sun® and Microsoft®) use garbage collection.
Garbage collection is typically run automatically by the JVM, although it may be possible to turn off garbage collection by starting Java with a particular option. If garbage collection is turned off in a program that may run for an extended period, the program is likely to fail with memory exhaustion before execution is complete. The JVM typically provides the user with the option to explicitly call a garbage collection method so that garbage collection can be performed at any point in the code execution specified by the user.
Although particular embodiments of the invention have been described herein, it will be apparent that the invention is not limited thereto, and that many modifications and additions may be made within the scope of the invention. For example, various combinations of the features of the following dependent claims could be made with the features of the independent claims without departing from the scope of the present invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US3889243||Oct 18, 1973||Jun 10, 1975||Ibm||Stack mechanism for a data processor|
|US4236204||Mar 13, 1978||Nov 25, 1980||Motorola, Inc.||Instruction set modifier register|
|US4587632||May 27, 1980||May 6, 1986||At&T Bell Laboratories||Lookahead stack oriented computer|
|US4922414 *||Sep 8, 1987||May 1, 1990||Symbolics Inc.||Symbolic language data processing system|
|US4969091||Aug 4, 1988||Nov 6, 1990||Mueller Otto||Apparatus for stack control employing mixed hardware registers and memory|
|US5136696||Jun 27, 1988||Aug 4, 1992||Prime Computer, Inc.||High-performance pipelined central processor for predicting the occurrence of executing single-cycle instructions and multicycle instructions|
|US5355483||Jul 18, 1991||Oct 11, 1994||Next Computers||Asynchronous garbage collection|
|US5455775||Jan 25, 1993||Oct 3, 1995||International Business Machines Corporation||Computer design system for mapping a logical hierarchy into a physical hierarchy|
|US5619665||Apr 13, 1995||Apr 8, 1997||Intrnational Business Machines Corporation||Method and apparatus for the transparent emulation of an existing instruction-set architecture by an arbitrary underlying instruction-set architecture|
|US5638525||Feb 10, 1995||Jun 10, 1997||Intel Corporation||Processor capable of executing programs that contain RISC and CISC instructions|
|US5644709 *||Apr 21, 1994||Jul 1, 1997||Wisconsin Alumni Research Foundation||Method for detecting computer memory access errors|
|US5659703||Jun 7, 1995||Aug 19, 1997||Patriot Scientific Corporation||Microprocessor system with hierarchical stack and method of operation|
|US5740461||Oct 22, 1996||Apr 14, 1998||Advanced Risc Machines Limited||Data processing with multiple instruction sets|
|US5742802||Feb 16, 1996||Apr 21, 1998||International Business Machines Corporation||Method and system for efficiently mapping guest instruction in an emulation assist unit|
|US5752035||Jun 7, 1995||May 12, 1998||Xilinx, Inc.||Method for compiling and executing programs for reprogrammable instruction set accelerator|
|US5784584||Jun 7, 1995||Jul 21, 1998||Patriot Scientific Corporation||High performance microprocessor using instructions that operate within instruction groups|
|US5809336||Jun 7, 1995||Sep 15, 1998||Patriot Scientific Corporation||High performance microprocessor having variable speed system clock|
|US5838948||Dec 1, 1995||Nov 17, 1998||Eagle Design Automation, Inc.||System and method for simulation of computer systems combining hardware and software interaction|
|US5873097 *||Dec 17, 1996||Feb 16, 1999||Apple Computer, Inc.||Update mechanism for computer storage container manager|
|US5875336||Mar 31, 1997||Feb 23, 1999||International Business Machines Corporation||Method and system for translating a non-native bytecode to a set of codes native to a processor within a computer system|
|US5892966||Jun 27, 1997||Apr 6, 1999||Sun Microsystems, Inc.||Processor complex for executing multimedia functions|
|US5925123||Jan 23, 1997||Jul 20, 1999||Sun Microsystems, Inc.||Processor for executing instruction sets received from a network or from a local memory|
|US5926832||Sep 26, 1996||Jul 20, 1999||Transmeta Corporation||Method and apparatus for aliasing memory data in an advanced microprocessor|
|US5937193||Nov 27, 1996||Aug 10, 1999||Vlsi Technology, Inc.||Circuit arrangement for translating platform-independent instructions for execution on a hardware platform and method thereof|
|US5953741||Nov 27, 1996||Sep 14, 1999||Vlsi Technology, Inc.||Stack cache for stack-based processor and method thereof|
|US6003126||Jul 1, 1997||Dec 14, 1999||International Business Machines||Special instruction register including allocation field utilized for temporary designation of physical registers as general registers|
|US6009499||Mar 31, 1997||Dec 28, 1999||Sun Microsystems, Inc||Pipelined stack caching circuit|
|US6009509||Oct 8, 1997||Dec 28, 1999||International Business Machines Corporation||Method and system for the temporary designation and utilization of a plurality of physical registers as a stack|
|US6014723||Jan 23, 1997||Jan 11, 2000||Sun Microsystems, Inc.||Processor with accelerated array access bounds checking|
|US6021469||Jan 23, 1997||Feb 1, 2000||Sun Microsystems, Inc.||Hardware virtual machine instruction processor|
|US6026485||Jan 23, 1997||Feb 15, 2000||Sun Microsystems, Inc.||Instruction folding for a stack-based machine|
|US6031992||Jul 5, 1996||Feb 29, 2000||Transmeta Corporation||Combining hardware and software to provide an improved microprocessor|
|US6038643||Jan 23, 1997||Mar 14, 2000||Sun Microsystems, Inc.||Stack management unit and method for a processor having a stack|
|US6070173||Nov 26, 1997||May 30, 2000||International Business Machines Corporation||Method and apparatus for assisting garbage collection process within a java virtual machine|
|US6088786||Jun 27, 1997||Jul 11, 2000||Sun Microsystems, Inc.||Method and system for coupling a stack based processor to register based functional unit|
|US6122638||Nov 26, 1997||Sep 19, 2000||International Business Machines Corporation||Object-oriented processor and method for caching intermediate data in an object-oriented processor|
|US6125439 *||Jan 23, 1997||Sep 26, 2000||Sun Microsystems, Inc.||Process of executing a method on a stack-based processor|
|US6148391||Mar 26, 1998||Nov 14, 2000||Sun Microsystems, Inc.||System for simultaneously accessing one or more stack elements by multiple functional units using real stack addresses|
|US6149318 *||Apr 15, 1997||Nov 21, 2000||Samuel C. Kendall||Link-time and run-time error detection, and program instrumentation|
|US6167535||Apr 14, 1998||Dec 26, 2000||Sun Microsystems, Inc.||Object heap analysis techniques for discovering memory leaks and other run-time information|
|US6212612 *||Jul 15, 1998||Apr 3, 2001||Intelect Communications Inc.||System and method for synchronized, multi-channel data management with dynamically configurable routing|
|US6249793||Jun 10, 1999||Jun 19, 2001||Sun Microsystems, Inc.||Mostly concurrent compaction in a garbage collection system|
|US6286016||Jun 9, 1998||Sep 4, 2001||Sun Microsystems, Inc.||Incremental heap expansion in a real-time garbage collector|
|US6298434||Oct 1, 1998||Oct 2, 2001||U.S. Philips Corporation||Data processing device for processing virtual machine instructions|
|US6317872||Apr 6, 1998||Nov 13, 2001||Rockwell Collins, Inc.||Real time processor optimized for executing JAVA programs|
|US6338134||Dec 29, 1998||Jan 8, 2002||International Business Machines Corporation||Method and system in a superscalar data processing system for the efficient processing of an instruction by moving only pointers to data|
|US6349377||Sep 28, 1998||Feb 19, 2002||U.S. Philips Corporation||Processing device for executing virtual machine instructions that includes instruction refeeding means|
|US6374286||Apr 6, 1998||Apr 16, 2002||Rockwell Collins, Inc.||Real time processor capable of concurrently running multiple independent JAVA machines|
|US6427154||Aug 2, 2000||Jul 30, 2002||International Business Machines Corporation||Method of delaying space allocation for parallel copying garbage collection|
|US6442751 *||Dec 14, 1998||Aug 27, 2002||International Business Machines Corporation||Determination of local variable type and precision in the presence of subroutines|
|US6606743||Nov 13, 1997||Aug 12, 2003||Razim Technology, Inc.||Real time program language accelerator|
|US6910213||Nov 18, 1998||Jun 21, 2005||Omron Corporation||Program control apparatus and method and apparatus for memory allocation ensuring execution of a process exclusively and ensuring real time operation, without locking computer system|
|US20010042074||Jan 29, 2001||Nov 15, 2001||Takuji Kawamoto||Garbage collection apparatus and a garbage collection method|
|US20020052926 *||Oct 22, 2001||May 2, 2002||Sun Microsystems, Inc.||Thread suspension system and method using trapping instructions|
|US20030177152 *||Feb 7, 2001||Sep 18, 2003||Stephen Darnell||Reduced size object headers|
|US20040039758 *||Aug 22, 2002||Feb 26, 2004||Xiaofeng Li||Methods and apparatus for concurrent enumeration of an object reference root set|
|JP2000047931A||Title not available|
|JP2000099351A||Title not available|
|JP2001209572A||Title not available|
|JPH11312097A||Title not available|
|WO2000029937A2||Mar 16, 1999||May 25, 2000||Insignia Solutions Plc||Computer system, computer-readable storage medium and method of operating same, and method of operating that system|
|WO2001050270A2||Jan 2, 2001||Jul 12, 2001||Sun Microsystems, Inc.||Methods and apparatus for improving locality of reference through memory management|
|1||A. Wolfe, "First Java-specific chip takes wing" EETimes-1997.|
|2||A. Wolfe, "First Java-specific chip takes wing" EETimes—1997.|
|3||A. Yonezawa et al, "Implementing Concurrent Object-Oriented Languages in Multicomputers" Parallel and Distributed Technology (Systems and Applications) May 1993, pp. 49-61.|
|4||C. Chung et al, Proceedings of the '98 International Conference on Parallel and Distributed Systems, "A Dual Threaded Java Processor for Java Multithreading" pp. 693-700, Dec. 1998.|
|5||C. Glossner et al, "Delft-Jaya Link Translation Buffer", Aug. 1998.|
|6||C. Glossner et al, "Parallel Processing" Euro-Par 1997: Passau, Germany, Aug. 1997.|
|7||C. Glossner et al, "The Delft-Java Engine: An Introduction", Aug. 1997.|
|8||C. Hsueh et al, "Java Bytecode to Native Code Translation; The Caffeine Prototype and Preliminary Results" IEEE/ACM International Symposium on Microarchitecture, Dec. 1996, pp. 90-97.|
|9||D. Ungar et al, "Architecture of SOAR: Smalltalk on a RISC" The 11th Annual International Symposium on Computer Architecture, Jun. 1984, pp. 188-197.|
|10||Espresso-The High Performance Java Core Specification, Oct. 2001, pp. 1-33, Aurora VLSI, Inc.|
|11||Espresso—The High Performance Java Core Specification, Oct. 2001, pp. 1-33, Aurora VLSI, Inc.|
|12||H. McGhan et al, PicoJava A Direct Execution Engine for Java Bytecode, Oct. 1998, pp. 22-26.|
|13||H. Stone, Chapter 12-"A Pipeline Push-Down Stack Computer", 1969, pp. 235-249.|
|14||H. Stone, Chapter 12—"A Pipeline Push-Down Stack Computer", 1969, pp. 235-249.|
|15||*||Hosoya et al. "Garbage Collection via Dynamic Type Inference-A Formal Treatment-" in Types in Compilation: Second International Workshop in Lecture Notes in Computer Science. Mar. 1998. Springer Berlin / Heidelberg. vol. 1473. pp. 215-239.|
|16||*||Hosoya et al. "Garbage Collection via Dynamic Type Inference—A Formal Treatment—" in Types in Compilation: Second International Workshop in Lecture Notes in Computer Science. Mar. 1998. Springer Berlin / Heidelberg. vol. 1473. pp. 215-239.|
|17||I. Kazi et al, "Techniques for Obtaining High Performance in Java Programs" Sep. 2000, pp. 213-240.|
|18||J. Davis; "Rockwell Produces Java Chip" Sep. 1997, CNET News.Com, pp. 1 of 3.|
|19||J. Gosling, "Java Intermediate Bytecodes" 1995, pp. 111-118.|
|20||J. O'Connor et .al, "PicoJava I Microprocessor Core Architecture" Oct. 1996, pp. 1-8, Sun Microsystems.|
|21||J. O'Connor et al,. "PicoJava-I: The Java Virtual Machine in Hardware" IEEE Micro A Case for Intelligent RAM, Mar./Apr. 1997, pp. 45-53.|
|22||Japanese Office Action dated Aug. 26, 2011 in corresponding JP application.|
|23||K. Andrews et al, "Migrating a CISC Computer Family Onto RISC Via Object Code Translation" 1992, pp. 213-222.|
|24||K. Buchenrieder et al, "Scalable Processor Architecture for Java With Explicit Thread Support" Electronics Letters vol. 33, No. 18, pp. 1532+, Aug. 1997.|
|25||K. Ebcioglu et al, "A Java ILP Machine Based On Fast Dynamic Compilation", Jan. 1997, pp. 1-13.|
|26||K. Inui, "RealTime Java, Real-time Garbage Collector and Scheduler for RealTime Java" Omron Technics, vol. 38, No. 1, pp. 50-55, Mar. 20, 1998.|
|27||L. Chang et al, "Stack Operations Folding in Java Processors" IEEE Proc.-Comput. Digit. Tech., vol. 145, No. 5, pp. 333-340 Sep. 1998.|
|28||L. Chang et al, "Stack Operations Folding in Java Processors" IEEE Proc.—Comput. Digit. Tech., vol. 145, No. 5, pp. 333-340 Sep. 1998.|
|29||L. Ton et al, Proceedings of the '97 International Conference on Parallel and Distributed Systems, "Instruction Folding in Java Processor", pp. 138-143, Dec. 1997.|
|30||List of Cited References issued by Japanese Patent Office Apr. 14, 2009 in corresponding JP application.|
|31||List of Cited References issued by Japanese Patent Office Nov. 10, 2009 in corresponding JP application.|
|32||M. Berekovic et al, "Hardware Realization of a Java Virtual Machine for High Performance Multimedia Applications", pp. 479-488, 1997.|
|33||M. Ertl, "Implementation of Stack-Based Languages on Register Machines" Apr. 1996, pp. 1-4.|
|34||M. Ertl, "Stack Caching for Interpreters" 1994, pp. 1-10.|
|35||M. Ertl; "A New Approach to Forth Native Code Generation" 1992.|
|36||M. Ertl; "Stack Caching for Interpreters" 1995, pp. 1-13.|
|37||M. Ibrahim et al.; "Signal Processing Systems (SIPS 97) Design and Implementation"; 1997 IEEE Workshop, Nov. 1997.|
|38||M. Maierhofer et al, "Optimizing Stack Code" 1997, p. 1-9.|
|39||M. Mrva et al, "A Scalable Architecture for Multi-Threaded JAVA Applications" Design Automation and Test in Europe, Feb. 1998, pp. 868-874.|
|40||N. Vijaykrishnan et al, "Object-Oriented Architectural Support for a Java Processor" 1998, pp. 330-355.|
|41||O. Steinbusch, "Designing Hardware to Interpret Virtual Machine Instructions" Feb. 1998, pp. 1-59.|
|42||P. Deutsch, "Efficient Implementation of the Smalltalk-80 System" 1983, pp. 297-302.|
|43||P. Koopman, Jr. "Stack Computers The New Wave" 1989, pp. 1-234.|
|44||R. Kapoor et al, "Stack Renaming of the Java Virtual Machine" Dec. 1996, pp. 1-17.|
|45||R. Kieburtz, "A RISC Architecture for Symbolic Computation" 1987, pp. 146-155.|
|46||Sun Microsystems PicoJava Processor Core Data Sheet, Dec. 1997, pp. 1-11.|
|47||*||Wilson, Paul R. "Uniprocessor garbage collection techniques" in Proc. of Interantional Workshop on Memory Management in Lecture Notes on Computer Science. Sep. 1992. Springer-Verlag. vol. 637. pp. 1-67. http://citeseer.ist.psu.edu/wilson92uniprocessor.html.|
|48||Y. Matsumoto, "Ruby" TransTECH, Aug. 1999, pp. 47-59.|
|49||Y. Pan, Introduction to Computing Systems From Bits and Gates to C and Beyond, 1999, pp. 1-517.|
|50||Y. Patt et al, Introduction to Computing Systems from Bits and Gates to C and Beyond, 2001, pp. 1-16, 91-118 & 195-209.|
|51||Y. Patt et al, Introduction to Computing Systems From Bits and Gates to C and Beyond, 2001, pp. 1-526.|
|52||Y. Patt; Introduction to Computing Systems From Bits and Gates to C and Beyond, 1999, pp. 10-12 & 79-82.|
|U.S. Classification||711/170, 707/816|
|International Classification||G06F12/00, G06F12/02, G06F9/44|
|Feb 20, 2004||AS||Assignment|
Owner name: ARM LIMITED, UNITED KINGDOM
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NEVILL, EDWARD COLLES;REEL/FRAME:015010/0602
Effective date: 20040131
|Oct 21, 2015||FPAY||Fee payment|
Year of fee payment: 4