Data processing: software development – installation – and managem – Software program development tool – Testing or debugging
Reexamination Certificate
1999-09-28
2003-07-15
Chaki, Kakali (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Testing or debugging
C717S126000, C717S127000, C714S038110
Reexamination Certificate
active
06594820
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to the field of computer software, and, more specifically, to testing and debugging processes.
Sun, Sun Microsystems, the Sun logo, Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All SPARC trademarks are used under license and are trademarks of SPARC International Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
2. Background Art
One step in software development is testing and verification of a product. The software product is typically executed under a variety of conditions, and any faults are reported for subsequent correction. In some software systems, there are extra operations, such as monitoring or “housekeeping” subprocesses or routines (e.g., garbage collection), that may be carried out at various points (referred to herein as “test points”) in the execution of a process (e.g., an application, program or portion thereof). During ordinary execution, a process may cause or permit execution of these extra operations at any one or more of these test points by intermittently branching to the subprocess handling those extra operations.
Ideally, for exhaustive testing purposes, it is desirable to evaluate the execution of these extra operations at all such test points to verify that each such test point does not have any errors associated with it. However, if executed at every possible test point in a single execution of the main process, these extra operations may entail prohibitive performance cost in the execution of the process or program, particularly for more complicated functions. For example, it may take an inordinate amount of time for a process to execute beyond its initial stages due to frequent branching to a subprocess. Thus, evaluation of test points occurring later in the execution of the main process is undesirably delayed while the earlier portions of the process are exhaustively tested. Also, for time-critical applications, the slow-down in performance may disrupt normal operations, diminishing the effectiveness of such tests.
FIG. 1
is a block diagram illustrating the branching of a main process to a subprocess at one or more test points. Considering an intermittent garbage collection example, executing process
100
represents a program under execution and subprocess
102
represents the system's garbage collector for recovering unused memory resources. Executing process
100
may be a program running on an underlying virtual machine (VM) or operating system, and may contain one or more threads of execution, each of which may contain a plurality of garbage collection points (gc-points) that can be considered test points. During normal execution, executing process
100
may branch to the garbage collector subprocess
102
at any one (or more) of those gc-points to permit recovery of memory resources. Branching may be explicitly performed via direct or indirect branching instructions in the executing process, or branching may be performed by the release of processor or VM execution control by a currently executing thread to enable the execution of a second thread supporting the subprocess (i.e., via cooperative scheduling).
In
FIG. 1
, executing process
100
contains M operations or instructions OP A
1
through OP A(M), interspersed with test points 1−N. Subprocess
102
contains K operations OP B
1
through OP B(K). As indicated by arrow
103
, executing process
100
may branch to the first operation OP B
1
of subprocess
102
from any test point (e.g., from test point
1
) to initiate execution of subprocess
102
. When execution of subprocess
102
is completed (i.e., OP BK has been executed), subprocess
102
returns (arrow
104
) to the operation (e.g., OP A
3
) following the test point from which branching occurred.
If branching occurs at only a limited number of the N test points, the impact of executing the extra instructions of subprocess
102
is acceptable. However, if subprocess
102
is executed at each of the N test points in an exhaustive test execution, the total execution time of process
100
may increase substantially for large values of N. Also, the K increases, the interruption and slow-down of process
100
becomes more prohibitive.
One method for reducing the disruptive nature of test point evaluation is to evaluate (e.g., branch to a subprocess) at a subset of the possible test points, selecting those test points to be evaluated based upon a pseudo-random distribution of test points. An irregular sampling of test points is achieved with less performance cost than the exhaustive technique of evaluating every test point. However, not all test points are tested. Even across multiple executions of the process with different pseudo-random distributions of test points, there is no mechanism for ensuring that all test points are ultimately evaluated. Pseudo-random techniques therefore provide only incomplete evaluation results.
The problem associated with evaluating test points are more clearly understood with reference to an example test point situation. For this purpose, the example of an intermittent garbage collection system is described in more detail below.
Garbage Collection Example of an Intermittent Subprocess
Garbage collection is an important aspect of memory management in most modern computer systems. Garbage collection (GC) refers to the process of reclaiming portions of main memory that are no longer in use by the system or any running applications. The execution of programs in a computer system is typically interrupted intermittently to permit the garbage collection process to run. Ideally, the frequency of these interruptions is kept low to impact the execution of other programs as little as possible.
In an object-oriented system, for example, garbage collection is typically carried out to reclaim memory allocated to objects and other data structures (e.g., arrays, etc.) that are no longer referenced by an application. The reclaimed memory can then be re-allocated to store new objects or data structures. The garbage collection process may be either conservative or extract. Conservative garbage collection involves scanning memory space for stored values that match the address of an object (or other memory structure) that is being considered for collection. If a matching value is not found in the memory being scanned, then no references to the object exist, and the object may be safely collected. If a matching value is found, it is assumed that the value is a reference (e.g., a pointer) to the object under consideration, and the object is not collected.
In exact garbage collection, only true references (pointers) are considered in a scan, so coincidentally matching data values are ignored in the collection process. This means that an object without any associated references is always considered garbage in a scan, and more efficient collection is achieved. However, to perform exact garbage collection, the scanning process must have reliable information regarding which memory locations contain live references (i.e., active, non-null references). Only those memory locations containing live references are scanned to determine reference matches for objects under consideration for collection.
To provide more efficient use of memory space in terms of compaction, “copying” garbage collection is commonly implemented. In copying garbage collection, the memory space is divided into regions and an object transfer is performed. When garbage collection is carried out, objects in a portion of memory referred to an “from” space are copied to a portion referred to as “to” space. Those objects in “from” space that are considered “garbage” by the scan process are not copied to “to” space. The process of copying the objects results in reduced fragmentation of the memory space and better compaction.
The process of performing garbage collection, i.e., the
Chaki Kakali
Gunnison McKay & Hodgson, L.L.P.
McKay Philip J.
Nahar Qamrun
LandOfFree
Method and apparatus for testing a process in a computer system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for testing a process in a computer system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for testing a process in a computer system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3004828