|Publication number||US7406686 B2|
|Application number||US 10/457,977|
|Publication date||Jul 29, 2008|
|Filing date||Jun 9, 2003|
|Priority date||Jun 9, 2003|
|Also published as||US20040250234|
|Publication number||10457977, 457977, US 7406686 B2, US 7406686B2, US-B2-7406686, US7406686 B2, US7406686B2|
|Inventors||James Liu, Raghavender Pillutla, Chien-Hua Yen, Timothy Mac, Yousef Yacoub|
|Original Assignee||Sun Microsystems, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (36), Non-Patent Citations (16), Referenced by (10), Classifications (8), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This invention is also related to U.S. patent application Ser. No. 10/457,848, filed on the same day as this patent application, naming Liu et al. as inventors, and entitled “SYSTEM FOR EFFICIENTLY ACQUIRING AND SHARING RUNTIME STATISTICS.” That application is incorporated herein by reference in its entirety and for all purposes.
This application is also related to U.S. patent application Ser. No. 10/458,508, filed on the same day as this patent application, naming Liu et al. as inventors, and entitled “METHODS AND APPARATUS FOR ENHANCED STATISTICAL PERFORMANCE.” That application is incorporated herein by reference in its entirety and for all purposes.
1. Field of the Invention
The present invention relates generally to computer software. More particularly, the present invention relates to methods and apparatus for performing software performance tuning.
2. Description of Related Art
Software engineers are often under significant time constraints during the generation of a software tool or product. However, even once the software has been generated, the software cannot yet be released or shipped. In fact, one of the most time consuming phases of the software generation process is often the software testing process.
The process of assessing and tuning the current level of performance of software is often referred to as “software performance tuning.” For instance, software performance tuning may be used to test a software application that is run on the underlying computer system or that is a part of the underlying system (e.g., operating system). The resulting data is then analyzed to ascertain the causes of undesirable performance characteristics, such as the speed with which the particular software application is executed.
Software performance tuning has been long considered an art more than a science. Primarily, it typically requires tremendous expertise of its practitioners to both diagnose performance issues and resolve them. Performance issues may be caused by poor software application implementation or algorithms. However, often, performance issues may be caused by idiosyncratic behavior due to hardware, operating environment (e.g., operating system), or even compilers. Accordingly, the mastery of such an art often requires significant breadth and depth of knowledge and experience.
Various monitoring tools are currently available for the purpose of assessing the software performance of a software application being executed. These monitoring tools often generate a significant amount of runtime data. This runtime data is then manually assessed in order to identify undesirable performance characteristics of the software. Software performance tuning has therefore traditionally been a time-consuming process.
Many operating systems are shipped to customers with built-in monitoring tools that are used to assess software performance issues of software being executed on these operating systems. However, since these monitoring tools are designed to run with a particular operating system and each vendor platform varies, a software developer is often unfamiliar with these monitoring tools. As a result, the software developer may have difficulty running the monitoring tool. In addition, the amount of data generated by these monitoring tools is often inappropriate for the purpose needed. For instance, a particular monitoring tool may produce an unnecessarily large amount of data, or an insufficient amount of data. Moreover, it is often difficult to understand the runtime or output data that is generated by these monitoring tools. Software tuning engineers are therefore often needed in order to gain expertise in executing these monitoring tools, as well as analyzing the data that is generated by these monitoring tools.
Another shortcoming of existing monitoring tools is the type and quality of the data that is generated by the monitoring tools. Specifically, often the data that is generated is absolute data (e.g., number of bits) rather than relative or derived data (e.g., number of bits per second). In other words, the data often requires further analysis in order to ascertain the performance (e.g., speed) of the software being tested. In addition, runtime data may be obtained in accordance with a variety of methods, and therefore the data that is generated is often inaccurate.
Existing software monitoring tools are often referred to as “profilers.” These software profiles generally collect runtime performance data during the execution of a particular software application, and then presents the runtime data. Exemplary profilers include the Collector and Analyzer bundled with SunONE Studio software, available from Sun Microsystems, Inc. located in Menlo Park, Calif., the Jprobe Java™ profiler available from Sitraka/Quest located in Irvine, Calif., and OptimizeIt available from Borland located in Scotts Valley, Calif. Through the use of such profilers, it is possible to ascertain those portions of the software functionality that consume the most system resources and/or time.
Some profilers currently available run similarly to many debugging tools. Specifically, it is possible to interactively step through software being executed. However, such a process is often time-consuming. The user then individually and manually identifies those portions of the software that are problematic. In addition, the user has limited control over the testing process. In fact, many software profilers are run in batch mode without enabling the user to control the software testing process. The user is then left to the tedious and time consuming process of analyzing the large amount of data generated. In addition, such profilers typically generate data in a specific manner. Due to the rigid requirements of conventional profilers, it is difficult to customize the software performance tuning process.
In view of the above, it would be desirable to simplify the performance tuning process. Moreover, it would be beneficial if the accuracy of the data generated during software performance tuning process could be improved.
Methods and apparatus for determining a level of performance such as speed of execution of an application are disclosed. The application may be, for example, a user application or system utility. This is accomplished through providing an interactive system that is easily integratable for assisting the user in software performance tuning.
In accordance with one aspect of the invention, methods and apparatus for determining a level of performance of an application are disclosed. A selection of a second one of a plurality of applications (e.g., probes) is received. The second application is then executed, thereby producing data indicating one or more levels of performance of the first application. Documentation is then provided, where the documentation is associated with the second application and indicates at least one of a manner of interpreting data indicating one or more levels of performance of the first application and suggesting one or more of the plurality of applications that can provide additional information to assess one or more levels of performance of the application. The user may then select and execute one of the suggested applications in order to further assess the performance of the application being tested.
In accordance with another aspect of the invention, data associated with the second application (e.g., probe) that has been executed is displayed. For instance, the data may be displayed in a graphical or tabular format. The data that is displayed may be that generated by the second application. Alternatively, the data generated by the second application may be captured (e.g., by a Java wrapper). A portion of the data may therefore be optionally discarded. In addition, one or more arithmetic operations may be performed on at least a portion of the data. In this manner, averaged or derived data (e.g., indicating speed) may be obtained. This modified data may be displayed in addition to, or instead of, the initial data generated by the probe.
The invention, together with further advantages thereof, may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which:
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order not to unnecessarily obscure the present invention.
Various software performance criteria may be analyzed through the use of such a software performance tuning tool. For instance, software characteristics such as speed (e.g., bits/second) may be assessed. Three exemplary types of data may be collected, calculated and/or analyzed by such a software performance tool. First, absolute data such as a cycle count or instruction count may be collected. Second, relative data such as cycle count in the last 5 seconds may be collected. In other words, relative data is absolute data that is relative to other criteria or data, such as time. Third, derived data such as cycle count/instruction count (CPI) may be collected. In other words, derived data is derived from other absolute data. In accordance with various embodiments of the invention, software characteristics may be interactively obtained and assessed.
In order to run a probe, a graphical user interface 114 (i.e., user harness) is provided. Alternatively, a user may wish to run a probe without using the graphical user interface 114, such as through the use of a command line (e.g., UNIX™ Prompt). One or more probes may be executed sequentially or in parallel. Alternatively, a scheduler may be used to automate the lifecycle of one or more probes. The data generated and intercepted by each of these probes may then be stored in a local data archive 116. This data may be displayed as well as analyzed to assess the application being tested, as well as used to identify one or more additional probes to be executed for further analysis of the System Under Test (SUT). The data may be displayed in a variety of formats, such as a tabular or graph format.
A probe list listing one or more available probes (e.g., available for execution by a particular customer or all customers) is then displayed at block 208 from which the user may select one or more probes to execute. The user may wish to view probe specifications associated with the probe at block 210. For instance, the user may wish to read a synopsis of functions performed by the probe, as well as a detailed description of the probe (e.g., functionality, execution instructions, and/or expected output) at block 210. The user may then select one or more probes to execute at block 212.
In accordance with one embodiment, each probe supports Standard Input (STDIN) and Standard Output (STDOUT) for normal logging functions and diagnostic text, if produced. In addition, error and administration messages are sent to Standard Error (STDERR). In addition, one or more probes are optionally invoked through a single command at the shell command line. No additional commands should be required to be executed other than this single command to generate the probe output. In accordance with various embodiments, a property file that defines the runtime environment of the probe(s) is defined by the user prior to invoking the probe(s).
When a probe is executed at block 214, it generates runtime data (e.g., output data). For instance, data may be obtained from a register. The types of data that may be generated and/or calculated by a probe include absolute data, relative data, and derived data. The presentation of the data is in ASCII format. Generally, a probe samples data over a period of time and averaged. This data is intercepted at block 216. The data may be obtained from a log file, which may also include associated diagnostic text. It may be desirable to discard a portion of the data and/or perform one or more arithmetic operations on the data. This may be accomplished, for example, through the use of a Java wrapper, as will be described in further detail below with reference to
Once the documentation is provided, the user may select one or more probes to execute to further test the application. For instance, the user may wish to select one or more probes from the probe list as described above at block 208. The user may also wish to select one or more probes that have been recommended in the documentation presented to the user. These probes may be selected from the probe list or, alternatively, they may be executed at block 212 by clicking on a link (e.g., URL) provided in the documentation. The process ends at block 222.
Each probe is preferably submitted with an associated set of documentation (not shown). As described above, the set of documentation preferably indicates a manner of interpreting the probe results (e.g., data) indicating one or more levels of performance of the application being tested. Specifically, the documentation may explain the probe results as well as methods of interpretation. In addition, the set of documentation preferably suggests execution of one or more probes that can provide additional information to assess one or more levels of performance of the application being tested.
It may be desirable for multiple applications (e.g., probes) to call a single application (e.g., probe or system utility). For instance, multiple probes may wish to call the probe or system utility. However, the underlying hardware may limit the number of processes that may execute simultaneously. Thus, methods and apparatus for acquiring and sharing runtime data and/or statistics are disclosed.
In the described embodiments, an object-oriented system is described. For instance, various described embodiments may be implemented in a Java™ based system that will run independent of an operating system. However, this description is merely illustrative, and alternative mechanisms for implementing the disclosed embodiments are contemplated.
A mechanism for intercepting, storing and distributing this data to the appropriate requesting probe(s) is provided in the form of a buffer object as shown at block 706. The buffer object includes aggregation code that collects the data, stores the data temporarily and/or to a disk 708. The aggregation code distributes the data at the appropriate sampling rate to the probes 710, 712, 714, and 716 provided in the form of a buffer object as shown at block 706. The buffer object includes aggregation code that collects the data, stores the data temporarily and/or stores the data to a disk 708. The aggregation code obtains the data from one or more instances of the application and distributes the data at the appropriate sampling rate to the probes 710, 712, 714, and 716. An exemplary object will be described in further detail below with reference to
In accordance with one embodiment, an output stream is associated with each instance of the application and an input stream is associated with each probe requesting data from the application. Specifically, an input stream is created through instantiating an instance of the InputStream class of the Java.io package and an output stream is created through instantiating an instance of the OutputStream class of the java.io package. Specifically, an instance of a PipedInputStream and an instance of a PipedOutputStream are generated, which inherit the properties of the InputStream class and OutputStream class, respectively. The piped input and output streams implement the input and output components of a pipe. Pipes are used to channel the output from one program (or thread or code block) into the input of another. In other words, each PipedInputStream is connected to a PipedOutputStream.
In order to map the input stream(s) to the output stream(s), a hash table 804 and lookup table 806 are implemented. The hash table 804 tracks the output streams, while the lookup table tracks the input streams 806. As described above with reference to the example of
When data is obtained, it is stored in one or more byte arrays 808-1 and 808-2. For instance, each byte array may correspond to a different output stream or probe. Historical data (e.g., data previously obtained and transmitted to the probe(s)) may be successively stored to disk as new data is stored in the byte arrays.
If the application is not executing, the application is executed such that data provided by the application can be provided to multiple probes. Specifically, the application is instantiated at block 1110. An output stream (e.g., PipedOutputStream) is then instantiated and associated with the instance of the application at block 1112. For instance, an entry may be entered into a hash table such as that described above with reference to
The instance of the application is then executed at block 1116. The data generated by the instance of the application is then stored at block 1118. The address(es) or reference to the appropriate address(es) at which the data is stored may then be stored in the appropriate entry in the hash and lookup tables as described above with reference to
In addition, each probe when it starts up may request the full data generated by an instance or to continue to receive or read data without such initialization at block 1120. Thus, if the probe has requested the full data, the historical data stored in the disk and/or byte array(s) is obtained provided to the probe at block 1122. In addition, the most current data stored in the byte array(s) continues to be obtained and provided to the probe. The data is preferably obtained and provided to the probe according to the desired sampling rate using a set of aggregation code as described above. Otherwise, the process continues at block 1124 to intercept and obtain the data (e.g., from the byte array(s)), which is preferably sampled according to the desired sampling rate. The data may therefore be provided to the probe in accordance with the desired sampling rate at block 1126.
It may be determined at block 1108 that the application (e.g., instance of the application) is already executing. In other words, two or more probes call the application or request data from the application. When it is ascertained that the application is executing, data produced by the application is provided to this additional probe if data provided by the application can be shared by the requesting probes. In other words, at block 1128, it is determined whether the instance of the application that is executing produces the desired data. For instance, the format of the data may be checked against that requested. In addition, the sampling interval of the executing application is preferably less than or equal to that desired (e.g., requested by the probe). In other words, the rate at which data is provided by the application is greater than or equal to that desired.
If data provided by the executing application cannot be shared by the probes, the application is executed such that data provided by the application can be provided to the probes and the data produced by the application is distributed to the probes (e.g., by the aggregation code). For instance, the application is executed such that the sampling rate or rate at which data is provided is greater than or equal to that of data requested by the probes. Specifically, the application is instantiated at block 1130 with the desired sampling rate. The previous output stream is preferably associated with the instance of the application (e.g., kstat) at block 1132, thereby replacing the old instance with the new instance. Thus, if a new probe requests data from the same underlying system utility that is already executing, that system utility may be restarted with the new “least common denominator.” Alternatively, a new output stream may be instantiated as described above and associated with the new instance of the application. For instance, a new key associated with the new instance of the application may be stored in the hash table as described above with reference to
If data provided by the executing application can be shared by the probes, the input stream associated with the new probe (e.g., newly executing probe) is associated with the executing instance of the application (e.g., kstat) at block 1136. For instance, the appropriate key and memory location may be stored in a lookup table as described above with reference to
As described above, the aggregation code provides data produced by the application to two or more probes. For instance, the aggregation code determines a sampling rate or rate at which data is requested by each of the two or more probes. Data produced by the application is then provided to each of the two or more probes at the sampling rate or rate at which data is requested by the corresponding one of the two or probes. As one example, the data may be sampled at the highest rate required by the probes. In other words, the data is sampled at the smallest time interval. The data may then be stored as well as distributed to those probes requesting a higher sampling rate (i.e., smaller sampling interval).
The probes requesting data (e.g., runtime statistics) from the same application may be executed simultaneously. However, execution of the probes may not be initiated simultaneously. In other words, they may request data from the application at different times. As a result, one or more instances of the application may be instantiated as necessary at different times. Accordingly, initiation of execution of the instances of the application need not be performed simultaneously.
Typically, runtime data is generated through the sampling of data and averaging of the sampled data. As a result, the accuracy of the runtime data that is generated depends upon the sampling rate and the time periods during which the data is sampled. However, the underlying hardware may limit the number of processes that may execute simultaneously. Thus, methods and apparatus for alternating multiple processes to obtain the desired data are disclosed. Moreover, the degree of accuracy of the data obtained by a single process (as well as multiple processes) may be increased.
As shown in
Each of the applications may be a probe or system utility, as described above. For instance, the system utility may be an operating system utility and/or a statistics gathering utility.
The sampling rate for each of the two or more applications is then increased at block 1406. In order to increase the sampling rate, the total number of samples to be obtained may be increased. In addition, the sampling time interval may be reduced. The sampling rate need not be identical for the applications. However, the increased sampling rate may correspond to the number of columns of data that are generated. For instance, the sampling rate may be divided by two for two columns of data, divided by three for three columns, etc. The sampling time interval will therefore be reduced (e.g., from 5 to 1 second), and will preferably be the same for all of the applications.
The sampling of data by the two or more applications is then alternated at block 1408 at the increased sampling rate over a period of time. For instance, the period of time that sampling has been requested may be multiplied by the number of applications to ascertain a total sampling time for all of the applications. This total sampling time may then be divided into time intervals over which sampling of data will be alternated among the applications.
Each of the applications (e.g., probes) may sample data from a different data source as well as the same data source. For instance, the applications may sample data stored in hardware registers. As another example, data generated by other applications may be sampled.
After or during the sampling of data, the data that is sampled by the two or more applications is stored as shown at block 1410. For instance, the data may be stored to disk and/or to temporary storage (e.g., byte array(s)) as described above. The data that is sampled by each of the applications may then be averaged at block 1412 such that an average sampled value is obtained for each of the applications.
In accordance with one embodiment, a wrapper such as a Java™ wrapper is generated for one or more of the applications at the increased sampling rate. Each Java wrapper executes one or more of the applications over non-sequential segments of time during the period of time at the increased sampling rate. In other words, the non-sequential segments of time are smaller time intervals than that specified by any one of the applications. In addition, the Java wrapper may average the data that is sampled by the one or more of the applications such that an average sampled value is obtained for each of the one or more of the applications.
The present invention may be implemented on any suitable computer system.
Computer system 1530 or, more specifically, CPUs 1532, may be arranged to support a virtual machine, as will be appreciated by those skilled in the art. The computer system 1502 includes any number of processors 1504 (also referred to as central processing units, or CPUs) that may be coupled to memory devices including primary storage device 1506 (typically a read only memory, or ROM) and primary storage device 1508 (typically a random access memory, or RAM). As is well known in the art, ROM acts to transfer data and instructions uni-directionally to the CPUs 1504, while RAM is used typically to transfer data and instructions in a bi-directional manner. Both the primary storage devices 1506, 1508 may include any suitable computer-readable media. The CPUs 1504 may generally include any number of processors.
A secondary storage medium 1510, which is typically a mass memory device, may also be coupled bi-directionally to CPUs 1504 and provides additional data storage capacity. The mass memory device 1510 is a computer-readable medium that may be used to store programs including computer code, data, and the like. Typically, the mass memory device 1510 is a storage medium such as a hard disk which is generally slower than primary storage devices 1506, 1508.
The CPUs 1504 may also be coupled to one or more input/output devices 1512 that may include, but are not limited to, devices such as video monitors, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, or other well-known input devices such as, of course, other computers. Finally, the CPUs 1504 optionally may be coupled to a computer or telecommunications network, e.g., an internet network or an intranet network, using a network connection as shown generally at 1514. With such a network connection, it is contemplated that the CPUs 1504 might receive information from the network, or might output information to the network in the course of performing the above-described method steps. Such information, which is often represented as a sequence of instructions to be executed using the CPUs 1504, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave.
Although illustrative embodiments and applications of this invention are shown and described herein, many variations and modifications are possible which remain within the concept, scope, and spirit of the invention, and these variations would become clear to those of ordinary skill in the art after perusal of this application. However, the present invention may be implemented in a variety of ways. Moreover, the above described process blocks are illustrative only. Therefore, the implementation may be performed using alternate process blocks as well as alternate data structures. Moreover, it may be desirable to use additional servers, such as a HTTP web server, in order to perform various processes (e.g., setup).
Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4885654||Nov 28, 1986||Dec 5, 1989||Budyko Viktor A||Device for arcless switching of electrical circuits|
|US5530964 *||Sep 19, 1994||Jun 25, 1996||International Business Machines Corporation||Optimizing assembled code for execution using execution statistics collection, without inserting instructions in the code and reorganizing the code based on the statistics collected|
|US5797019||Oct 2, 1995||Aug 18, 1998||International Business Machines Corporation||Method and system for performance monitoring time lengths of disabled interrupts in a processing system|
|US5835765||Oct 4, 1995||Nov 10, 1998||Mitsubishi Denki Kabushiki Kaisha||Computer operation management system for a computer operating system capable of simultaneously executing plural application programs|
|US5848274 *||May 10, 1996||Dec 8, 1998||Supercede, Inc.||Incremental byte code compilation system|
|US6026236 *||Jun 3, 1997||Feb 15, 2000||International Business Machines Corporation||System and method for enabling software monitoring in a computer system|
|US6216197 *||Jul 1, 1996||Apr 10, 2001||Sun Microsystems, Inc.||Method and apparatus for extending printer memory using a network file system|
|US6263488 *||Mar 8, 1995||Jul 17, 2001||International Business Machines Corporation||System and method for enabling software monitoring in a computer system|
|US6357039 *||Mar 3, 1998||Mar 12, 2002||Twelve Tone Systems, Inc||Automatic code generation|
|US6539396||Aug 31, 1999||Mar 25, 2003||Accenture Llp||Multi-object identifier system and method for information service pattern environment|
|US6546548 *||Oct 7, 1999||Apr 8, 2003||International Business Machines Corporation||Method and system for compensating for output overhead in trace data using initial calibration information|
|US6606744||Nov 22, 1999||Aug 12, 2003||Accenture, Llp||Providing collaborative installation management in a network-based supply chain environment|
|US6671876||Oct 28, 1999||Dec 30, 2003||Lucent Technologies Inc.||Monitoring of software operation for improving computer program performance|
|US6763395||Apr 10, 2000||Jul 13, 2004||National Instruments Corporation||System and method for connecting to and viewing live data using a standard user agent|
|US6772411 *||Dec 1, 2000||Aug 3, 2004||Bmc Software, Inc.||Software performance and management system|
|US6801940||Jan 11, 2002||Oct 5, 2004||Networks Associates Technology, Inc.||Application performance monitoring expert|
|US6823507 *||Jun 6, 2000||Nov 23, 2004||International Business Machines Corporation||Detection of memory-related errors in computer programs|
|US6954923 *||Jul 7, 1999||Oct 11, 2005||Ati International Srl||Recording classification of instructions executed by a computer|
|US6957424 *||Mar 1, 2002||Oct 18, 2005||International Business Machines Corporation||Method for optimizing performance of software applications within a computer system|
|US6968545 *||Sep 11, 2000||Nov 22, 2005||Agilent Technologies, Inc.||Method and apparatus for no-latency conditional branching|
|US6986130 *||Jul 28, 2000||Jan 10, 2006||Sun Microsystems, Inc.||Methods and apparatus for compiling computer programs using partial function inlining|
|US6996804 *||Jun 1, 2001||Feb 7, 2006||International Business Machines Corporation||Adapting polymorphic inline caches for multithreaded computing|
|US7007270 *||Mar 5, 2001||Feb 28, 2006||Cadence Design Systems, Inc.||Statistically based estimate of embedded software execution time|
|US7010779||Aug 15, 2002||Mar 7, 2006||Knowledge Dynamics, Inc.||Parser, code generator, and data calculation and transformation engine for spreadsheet calculations|
|US7013456 *||Jun 16, 1999||Mar 14, 2006||Ati International Srl||Profiling execution of computer programs|
|US7017153 *||Dec 13, 2001||Mar 21, 2006||Hewlett-Packard Development Company, L.P.||Uninstrumenting in-line code instrumentation via stack unwinding and cleanup|
|US7020697||Nov 3, 2000||Mar 28, 2006||Accenture Llp||Architectures for netcentric computing systems|
|US7117261||Aug 16, 2002||Oct 3, 2006||Infrastructure Innovations, Llc.||Auto control of network monitoring and simulation|
|US7143133 *||Nov 1, 2002||Nov 28, 2006||Sun Microsystems, Inc.||System and method for appending server-side glossary definitions to transient web content in a networked computing environment|
|US7194732||Jun 26, 2003||Mar 20, 2007||Hewlett-Packard Development Company, L.P.||System and method for facilitating profiling an application|
|US20030093772||Jun 12, 2001||May 15, 2003||Stephenson David Arthur||Method and system for instrumenting a software program and collecting data from the instrumented software program|
|US20040003375||Jun 28, 2002||Jan 1, 2004||George Jini S.||Method and system for combining dynamic instrumentation and instruction pointer sampling|
|US20040117760||Dec 11, 2002||Jun 17, 2004||Microsoft Corporation||Reality-based optimization|
|US20040250235||Jun 9, 2003||Dec 9, 2004||Sun Microsystems, Inc.||Methods and apparatus for enhanced statistical performance|
|US20050021655||Jun 9, 2003||Jan 27, 2005||Sun Microsystems, Inc.||System for efficiently acquiring and sharing runtime statistics|
|US20060277509||Jun 5, 2006||Dec 7, 2006||Tung Tung-Sun||System and method for analyzing power consumption of electronic design undergoing emulation or hardware based simulation acceleration|
|1||"Class java.io.PipedInputStream" http://stein.cshl.org/jade/distrib/docs/java.io.PipedInputStream.html downloaded from the Internet on Oct. 5, 2004.|
|2||"Class java.io.PipedOutputStream" http://publib.boulder.ibm.com/infocenter/wsphelp/topic/com.sun.api.doc/java/io/PipedOut... downloaded from the Internet on Oct. 5, 2004.|
|3||"Package java.io" http://java.sun.com/j2se/1.4.2/docs/api/java/io/package-summary.html downloaded from the internet on Oct. 5, 2004.|
|4||"Servertec IO Object" http://www.servertec.com/products/iscript/docs/IO.html downloaded from the Internet on Oct. 5, 2004.|
|5||"Using Input and Output Streams," http://scv.bu.edu/Doc/Java/tutorial/java/io/streampairs.html downloaded from the Internet on Oct. 5, 2004.|
|6||Beach et al., "An Integrated Manufacturing Data Management System", IEEE, pp. 306-311, Oct. 1990.|
|7||Haddox et al., "An Approach for Understanding and Testing Third Party Software Components", IEEE, pp. 239-299, 2002.|
|8||*||Hondroudakis et al, "An empirically derived framework for classifiying parallel program performance tuning problems", ACM SPDT, pp. 112-123, 1998.|
|9||Huang et al., Software Rejuvenation: Analysis, Module and Applications, IEEE, pp. 381-390, Jun. 1995.|
|10||Kevin Kline, Baya Pavliashvili, "Application Performance Tuning," Jul. 12,2002, http://188.8.131.52/search?q=cache:9wGa6HQnYAsJ:www.informit.com/content/index... downloaded from the Internet on Oct. 5, 2004.|
|11||Linda Schneider, "Sun Java System Message Queue Software Performance Tuning: An Overview," http://developers.sun.com/sw/docs/articles/integration/tuning<SUB>-</SUB>overview.html downloaded from the Internet on Oct. 5, 2004.|
|12||Randall et al., "Adaptable Technique for Collecting MWD Density Logging Research Data Using Windows Software", IEEE, vol. 1, pp. 633-635, Oct. 1992.|
|13||*||Sharma et al, "Architecture based analysis of performance reliability and security of software systems", ACM WOSP pp. 217-227, 2005.|
|14||*||Singhal et al, Architectural support for performance tuning a case study on SPARCenter 2000, IEEE, pp. 48-59, 1994.|
|15||*||Wu et al, "Performance modeling from software components", ACM WOSP, pp. 290-301, 2004.|
|16||*||Zheng et al, "Fast estimation of probabilities of soft deadlines misses in layered software performance models", ACM WOSP pp. 181-186, 2005.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7603404 *||Dec 20, 2004||Oct 13, 2009||Sap Ag||Grid parallel execution|
|US7739667 *||Oct 19, 2005||Jun 15, 2010||Cray Inc.||Parallelism performance analysis based on execution trace information|
|US8327325 *||Jan 14, 2009||Dec 4, 2012||International Business Machines Corporation||Programmable framework for automatic tuning of software applications|
|US8621052 *||Aug 20, 2010||Dec 31, 2013||International Business Machines Corporation||Performance tuning for software as a performance level service|
|US9235390 *||Mar 31, 2008||Jan 12, 2016||Symantec Corporation||Application optimization for use based on feature popularity|
|US20060101416 *||Oct 19, 2005||May 11, 2006||Callahan Charles D Ii||Parallelism performance analysis based on execution trace information|
|US20060136883 *||Dec 20, 2004||Jun 22, 2006||Alexander Gebhart||Grid parallel execution|
|US20070168742 *||Nov 18, 2005||Jul 19, 2007||Microsoft Corporation||Isolating code modules|
|US20100180255 *||Jan 14, 2009||Jul 15, 2010||International Business Machines Corporation||Programmable framework for automatic tuning of software applications|
|US20120047240 *||Aug 20, 2010||Feb 23, 2012||International Business Machines Corporation||Performance Tuning for Software as a Performance Level Service|
|U.S. Classification||717/151, 717/127, 714/E11.207, 717/155|
|International Classification||G06F9/44, G06F9/45|
|Jun 9, 2003||AS||Assignment|
Owner name: SUN MICROSYSTEMS, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LIU, JAMES;PILLUTLA, RAGHAVENDER;MAC, TIMOTHY;AND OTHERS;REEL/FRAME:014165/0671
Effective date: 20030606
|Sep 21, 2011||FPAY||Fee payment|
Year of fee payment: 4
|Dec 16, 2015||AS||Assignment|
Owner name: ORACLE AMERICA, INC., CALIFORNIA
Free format text: MERGER AND CHANGE OF NAME;ASSIGNORS:ORACLE USA, INC.;SUN MICROSYSTEMS, INC.;ORACLE AMERICA, INC.;REEL/FRAME:037303/0336
Effective date: 20100212
|Jan 13, 2016||FPAY||Fee payment|
Year of fee payment: 8