Data processing: software development – installation – and managem – Software program development tool – Testing or debugging
Reexamination Certificate
2001-08-09
2004-10-05
Zhen, Wei (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Testing or debugging
C714S045000
Reexamination Certificate
active
06802054
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention is directed to an improvement in computing systems and in particular to an improved system for the generation of runtime execution traces of applications and for problem determination for such applications.
2. Description of the Related Art
The complexity of current software products creates difficulties for end users, and software developers, in performing problem determination when a failure occurs in a software product. Not only is the cause of a failure potentially difficult to determine at the component level, problem determination may be sometimes difficult at the product level, when multiple software products are used at the time of the failure.
Software developers and users rely on known techniques for carrying out problem determination for computer applications. Typically, a given software component or product will be designed to generate an execution trace at runtime (sometimes referred to as “product instrumentation”). An execution trace is typically used by the component developer during the development cycle and by the end user during product usage. The trace of an application is potentially valuable in component debugging and fine-tuning, performance analysis, and for first failure data capture needed at a runtime crash. Execution traces for an object-oriented product may typically include information such as class name, method name, method entry/exit events, entry/exit parameter values for methods, thread identifiers, and hostname information. The type of information to be captured in a trace is usually left up to the product developer, but such information should be detailed enough to help in problem determination and source identification should unexpected behaviour, or a crash, occur.
While it is possible to generate runtime traces by inserting trace code in an application to be traced, it is also desirable to automate the instrumentation process so that no code need be inserted in the application source code itself.
In applications designed using Sun Microsystems Inc.'s Java™ language, the problem of automating instrumentation has typically been addressed in two ways. The first is by instrumenting a specific Java virtual machine (VM) at a specific JDK (Java Developer Kit) level, and the second is by post-processing compiled Java byte code.
The first approach is used where a given Java VM includes a trace switch that can be used to enable/disable tracing at runtime. When a Java application is run on such a VM the VM will generate a runtime trace as specified by that VM's trace functionality. Although the approach does provide Java applications with the capability of producing trace files, this type of instrumentation is VM specific. It is necessary to run the application using the specific instrumented VM to be able to generate the execution trace.
Such an approach is not well suited to distributed applications. Such applications running on different VMs cannot be traced consistently unless the VMs are similarly instrumented. Where the instrumentation of the different VMs is not identical, consistency of the trace becomes an issue. If the different VMs are instrumented using different architectures, then there is a difficulty in merging the different traces together.
A second approach to automating instrumentation of Java applications is the post-processing of compiled Java byte code. This approach uses byte code manipulation libraries that enable the insertion and modification of byte code in a Java .class file so that the Java code generates an execution trace at runtime. This approach has the following two disadvantages. Firstly, modifying byte code potentially creates Java security problems. When a JAR file (Java archive file) is signed using JDK software tools, each file in the archive is given a digest entry in the archive's manifest. The digest values are hashes or encoded representations of the contents of the files as they were at the time of signing, and they will change if the file itself changes. Verifying a signed JAR file means that the digests of each of its files is to be re-computed and then compared with the digests recorded in the manifest to ensure that the contents of the JAR file haven't changed since it was signed. Hence, byte code modification will result in difficulties where the application to be traced is in a signed JAR file. The application will not pass the security verification step as a result of the modification to the byte files made for tracing purposes.
In addition, modifying the byte code means that the resulting code can no longer be easily debugged. Debuggers expect a certain match between Java source files and their corresponding compiled .class files. When the byte code in a .class file is modified, there is no longer a match between the source code line numbers and the new .class files.
Thus, as may be seen from the above description, there are significant limitations inherent in the prior art approaches to generating a runtime trace for Java applications.
A further aspect of problem determination relates to the ability, given a runtime trace of an application, to perform problem analysis in order to determine the cause of a failure. It is desirable to have an approach to problem determination that may be effective across multiple products and thus be able to provide information to a developer or user where more than one product is involved at the time the software failure occurred.
Although various problem determination tools exist, they are usually limited to analysing a specific trace of a specific product, and are not capable of dealing with multiple products. Also, they are not usually designed to be implemented in a plugable architecture and there is therefore a limited ability to reuse the same analysis product for different application products.
It is therefore desirable to have a mechanism for generating VM-independent traces of Java applications without byte-code manipulation, the mechanism having a problem determination tool able to be used with different applications.
SUMMARY OF THE INVENTION
According to one aspect of the present invention, an improved system is provided for the generation of execution traces of applications and for problem determination for applications.
According to another aspect of the present invention, a computer system is provided for generating application execution trace data, the computer system including a monitor for launching one or more virtual machines, the monitor defining the functional characteristics of each of the virtual machines prior to the launch of each of the virtual machines, each of the virtual machines being enabled by the monitor to generate event data on the occurrence of specified events during application execution on each of the virtual machines, the monitor further including means to receive the event data from each of the virtual machines and including means to forward the event data to a logging services component, and the logging services component including means for receiving event data and for generating trace data for storage in a trace file.
According to another aspect of the present invention, there is provided the above computer system in which the virtual machines are Java language virtual machines and in which the monitor enables the virtual machines to generate event data using application program interfaces supplied by the Java Platform Debug Architecture.
According to another aspect of the present invention, the means to receive the event data of the above computer system comprises an event queue in the monitor to which each of the virtual machines is enabled to write the event data and from which the monitor may read the event data.
According to another aspect of the present invention, monitor of the above computer system further comprises an interface to permit a user to selectively launch one or more of the virtual machines using a Java connector object.
According to another aspect of the present invention, the monitor further comprises a fi
Doudnikoff Gregory M.
International Business Machines - Corporation
Zhen Wei
LandOfFree
Generation of runtime execution traces of applications and... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Generation of runtime execution traces of applications and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Generation of runtime execution traces of applications and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3284118