Patent Grant
7007269
This invention relates generally to profiling tools for analyzing the execution path or characteristics of a software application, and more particularly to a method and apparatus for providing open access to application profiling data across a network.
Profiling tools are used to evaluate applications for a variety of purposes including, for example, “trouble shooting”, “application tuning”, and “resource utilization optimization”. It is known in the prior art to use profiling tools that analyze a software execution path in a specific execution environment, language or operating system. However, where the application consists of more than one process or more than one language (e.g. a simple client-server networked application where the client is written in Java and the server has C stored procedures in an Relational Database Management System (RDBMS)), the client profiling tool traces only the single client activity, and is not capable of tracing the execution path across the network.
To further compound these problems, prior art profiling tools incorporate vendor specific or proprietary data collection engines and data exchange formats. Consequently, it is difficult to correlate execution traces detected by different vendor profiling tools in a distributed system incorporating diverse execution environments, languages and/or operating systems. Each profiling tool requires a specific or proprietary collection agent for each execution environment.
In the prior art model of application profiling, each application is assumed to be written in one programming language and executed on one computing machine in one execution environment. The profiling traces are composed of trace events, which occur sequentially, and which are stored in large files for later transport to profiling tools. The transmission of such large files can be a significant stress on a communication system. In addition, real time or near real time profiling of application is very difficult in such a system.
The advent of computer networking, and more recently the Internet, has, however, changed and expanded what constitutes an application. Over the Internet, an application may have a number of parts, written in a number of different programming languages, distributed on a number of different computer machines, and operated in a number different execution environments (herein referred to as “distributed environment”). The machines, languages, and environments of such an application are typically from a number of different vendors.
It is exceedingly difficult to develop a profiling tool that is able to interface with all of the products that may be available from various vendors in this environment. This is assuming that the vendors are prepared to disclose their application programming interfaces (APIs) to profiling tool vendors who may be competitors. Further, any change to the APIs may cause operability problems to the profiling tools. There are significant problems with developing and maintaining profiling tools, which are able to interface with products of a number of vendors (distributed access).
Additionally, prior art profiling tools obtain and store trace events in sequential form. In a distributed environment, trace events are not sequential especially as between different machines. There is no capability to correlate trace events between different machines or processes.
Recently, the Java programming language has been expanded to define a Java Virtual Machine Profiling Tool (JVMPI) for profiling hooks in a Java virtual machine. JVMPI is a two-way function call interface between the Java virtual machine and an in-process profiler or collection agent. On the one hand, the virtual machine notifies the collection agent of various events, corresponding to, for example, heap allocation, method calls, etc. The collection agent then communicates with a front-end analysis client, which may or may not run in the same process as the collection agent. On the other hand, the collection agent issues control requests to the Java virtual machine through the JVMPI. For example, the collection agent can turn on/off a specific event notification, based on the needs of the analysis client. The client may reside in a different process on the same machine, or on a remote machine connected via a network using vendor specific wire protocol suitable to the analysis client.
Although profiling tools based on JVMPI are useful for obtaining a variety of information performance data, the prior art problems relating to lack of distributed access and correlation capabilities remain.
A portion of the disclosure of this patent document contains material, which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The essential problem with the prior art application profiling model is the lack of a consistent data exchange format between collection engines and analysis portions of profiling tools of different vendors. For each execution environment, the analysis portions remain essential unchanged, but each of the vendors has to modify their collection engines accordingly. The inventors have discovered that an open data exchange format may be adapted for application profiling data that allows a single collection agent in an execution environment to provide the profiling data to any number of profiling tools from different vendors. Thus, vendors are able to focus on the development of the analysis portions of their profiling tools and allow other parties, such as vendors of the execution environments, to provide the collection agents.
Conversely, the open data exchange format also allows a profiling tool to obtain analysis data from more than one collection agent using only one standard interface. Thus, a profiling tool is able to profile an application executing on more than one machine and execution environment where the data exchange format provides attributes to correlate the trace events.
The open data exchange format thus has a number of advantages including allowing application vendors to retain confidentiality and revision options for their internal APIs without affecting the profiling tools; and reducing development and maintenance costs for profiling tool vendors.
According to the present invention, an open data structure is provided for exchanging profiling data in the form of trace elements between collection agents and analysis agents in a profiling tool. The data structure accommodates transmission of the profiling data in fragments across a network for storage in a database repository or receipt by one or more analysis agents. Each of the fragments comprises one or more trace elements defining trace events. The data structure of trace elements includes attributes, which define a logical hierarchy between the trace elements. More particularly, correlation attributes are provided with each trace element to enable the analysis clients to correlate the trace elements. Each of the trace elements defines a relationship to each of the other trace elements in a trace, and is not just a sequence of collated trace elements. Thus, for example, a profiling tool is able to correlate a method call to an object.
The data structure according to the present invention facilitates distributed access to profiling data across a network. Also, only a single collection agent is required per execution environment, thereby overcoming the prior art requirement for multiple vendor-specific proprietary collection agents.
According to the preferred embodiment, the data structure for the profiling data conforms to XML (Extensible Markup Language). Thus, the load on the network to transport the profiling data is more evenly distributed as the data is sent in XML fragments instead of large files.
A detailed description of the preferred embodiment is set forth herein below, with reference to the accompanying drawing, in which:
Referring to
The collection agents 102 are stored on computer readable mediums 150 such as, for example, diskettes, zip drives, CDs, and hard drives.
As discussed above, the preferred embodiment is described herein with reference to a Java application environment, with XML being used for implementation of the data structure. However, it is contemplated that the principles of the invention may be extended to other application environments and the data structures may be implemented using other languages, such as other mark-up languages (SGML, etc.). It is further contemplated that principles of the invention may be extended to programming languages other than object orientated languages such as Java.
The collection agent 102 uses the following command line syntax to attach itself to the JVM 100:
java -XrunpiAgent [:<option=value[,option=value]*]
[-Xbootclasspath:<location of picb.jar>,<location of rt.jar>] <Java class>
The JVM 100 attempts to locate the profiler agent library called ipAgent in the Java library directory. Once located, the JVM 100 loads the profiler agent library and hooks for the entry point in a well-known manner. The options supported in the first argument to the invocation command do not form part of the present invention. The collection agent 102 obtains a function call interface by issuing a GetEnv call on the JavaVM pointer in a well known manner. The GetEnv function returns a pointer to a JVMPI_Interface. The JVMPI_Interface returned by GetEnv has all the functions set up except for NotifyEvent. The collection agent 102 must set up the NotifyEvent function pointer.
The JVM 100 sends an event, through the JVMPI 120, to the collection agent 102 by calling NotifyEvent with a JVMPI_Interface data structure as the argument. The JVMPI_Event structure contains the event type, the pointer of the current thread, and other event-specific information, all of which is well known according to the JVMPI specification.
The event-specific information of a trace event is received by the collection agent 102 and is then converted to a data structure in the format of trace elements, which, as discussed above, define or represent trace events of object oriented programming languages.
The trace elements of a trace are emitted to Analysis Clients 104 as XML fragments, where each XML fragment comprises one or more trace elements. Alternatively, the trace elements may be collected and emitted to the Analysis Clients 104 as XML document. The trace elements are formatted as text in compliance with the XML standard.
According to the present embodiment of the invention, the trace elements represent logic components of object oriented programming languages. The logic components include, for example, threads, methods, objects, and classes. Trace elements further include elements to provide context information about a trace as a whole such as, for example, a node trace element to identify the JVM 100 that a trace event is from.
Each of the trace elements contains at least one correlation attribute. A number of different correlation attributes are defined according to this invention. The correlation attributes include other trace elements, reference numbers, time information, and counter information. The primary correlation attribute for associating a trace element to a parent element is by referring to the parent trace element and parent reference number. In particular, each parent trace element or identifier (Id) has a reference number attribute. All parent events are represented by trace elements (or Ids) and are further assigned unique identifying reference numbers. All related or associated trace elements reference parent trace elements (or Ids) and their reference numbers in a nested logical hierarchy. Trace elements in combination with reference numbers uniquely identify instances of certain components of the application.
According to the present embodiment of the invention, the trace elements for defining tracing events of object oriented programming languages are listed in Table 1 in the Id (identifier) column. Each Id has a defining element and an undefining element as shown in Table 1. A defining element provides the information related to an Id. For example, the defining element for a thread Id (see below) contains, among other entries, the name of the thread.
An Id is valid until its undefining element arrives. Where a defining element is enabled, the defining element is sent before the Id appears in other elements. An undefining element invalidates the Id. There are two kinds of Ids; transient Ids and non transient Ids. Both have the same logical lifetime as prescribed by their defining and undefining elements. However, transient Id values may be reused after they have been undefined, and in fact may be reused as a different type of Id. The value of a transientThreadId, for example, may be redefined as a transientClassId after a thread ends. Non transient Ids are unique within the scope of a trace.
Identifiers (Ids) and identifier references (IdRef) define a logical hierarchy between the various trace elements. Thus, as discussed in greater detail below with reference to
Many of the trace elements share the same attributes. The following attributes appear in more than one element:
In accordance with the best mode of the invention at the time of filing this application, descriptions will now be provided of the various trace elements formatted in compliance with the XML standard:
As indicated above, traceRoot is the root element for a valid trace XML document as shown in
A string containing the name of the object reference.
This element is used to associate a name with an transientObjId.
The code element is used to insert textual lines of code into the XML file. Thus, in the event that lines of code are to be preserved when the XML file is parsed, such lines are inserted into the code element with the result that the parser extracts the lines of code exactly as they appear in the element.
The name of the tag.
The tag element contains the information that is associated with a specific tag, expressed as name value pairs.
Trace Behaviour
The name of the machine on which the instrumented JVM is running.
The option string that was passed to the agent on the -XrunpiAgent parameter.
This element indicates that the execution of the process has been suspended.
The foregoing element indicates that the execution of the process has resumed.
A collection agent 102 may be assigned any number of agent-specific key/value pair options. In addition to the agent performing the specific action as specified by the option, the agent echoes the option through the option element.
The class filter is set by a client 104. Filters control which classes are traced using the profiling tool of the present invention. Filters are provided in blocks where a new block of filters completely replaces the current filter definitions. Matching is done by querying the active block of filters until the first match is found based on the supplied pattern. The class is then either included or excluded from the trace based on the mode. If the entire block of filters is traversed and no match is found, then the class is included in the trace. It should be noted that some classes are included in the trace even if they have been filtered out. This occurs if a reference is made to the class from a class that has not been filtered out. For example, the methodCall element can cause this to occur.
Threads
The elements which provide information about threads are set forth in
This element indicates the end of the thread identified by the transientThreadIdRef or threadIdRef value.
Classes
The hierarchical relationship of the class elements is set forth in
Although technically part of the classDef event, the methodDef element is broken out into a separate element so that it can be optionally output only when referenced.
The hierarchical relationship of the object elements is set forth in
Size in number of bytes expressed as an unsigned 32-bit value in string format.
This element traces storage allocation. It can be used in conjunction with other elements such as the methodEntry element to identify an associated object.
Methods and Values
The methodEntry and methodExit elements are output when a method is entered, and when the method returns respectively. The methodCall and methodReturn elements are output when a method is about to be called, and after a method returns. It is not necessary for an agent to produce both methodEntry/Exit and methodCall/Return for a each method invocation. The semantics associated with the generation of these elements is agent specific. The hierarchical arrangement of these elements is set forth in
The current depth of the stack including the current method being executed.
Note: the optional nested value elements represent parameter values.
The current depth of the stack including the current method being executed.
Size in number of bytes expressed as an unsigned 32-bit value in string format.
The objDef element holds identity information for an object, which can be referred to by elements associated with the object, such as the value element.
An optional parameter name associated with the value.
An optional reference name associated with the value. For example, a variable name.
The value element is used to reference a data value, either for parameter values in a methodCall, or for the return value of a methodReturn.
The methodCount element tracks the number of times a particular method has been invoked. This element is designed to aid in collecting code coverage information. A methodCount element is produced for every method for every class loaded by the application. The count includes all method invocations regardless of whether tracing has been enabled or not. In other words, the data is collected even before a traceStart and even after a traceEnd. The elements are produced just prior to the agentDestroy element being produced. In addition, an agent may be requested to produce the methodCount elements at any arbitrary time before the agentDestroy element is produced.
Lines
These elements are designed to capture line coverage type information. The hierarchical arrangement of these elements is set forth in
This element is produced for each Coverage Block that is executed.
Memory Management
The gcStart, objFree, classUnload, objMove, and gcFinish elements (along with objAlloc) are for tracing storage management. The hierarchical arrangement of these elements is set forth in
This element is produced when garbage collection (GC) is about to start.
This element is produced when an object is freed.
The new object id. See transientObjId for more information
This element is produced when an object is moved in the heap, and is always sent between a pair of gcStart and gcFinish elements. When an object is moved, its transientObjId is changed. All future references to this object use the new transientObjId value. To avoid having to map and track these changes, it is much simpler to use the objId to refer to the object, as this id does not change. Note: Because objId, classId, objIdRef and classIdRef are provided, it is anticipated that objMove need not be traced by a client unless low level memory analysis is required.
Number of used objects on the heap expressed as a 32-bit unsigned value in string format.
The throw and catch elements encapsulate the exception behavior of an application. The hierarchical arrangement of these elements is set forth in
When an exception is thrown, a throw element is generated for each unfiltered stack frame that processes the exception. Processing the exception includes simply letting the exception percolate to the next stack frame. A throw element is also generated for the stack frame that catches the exception.
A catch element is generated when the exception reaches an unfiltered stack frame that defines a catch clause for the exception.
Runtime
These elements track the initialization and shutdown of the program runtime. The hierarchical arrangement of these elements is set forth in
The runtimeInitDone element is produced when the program runtime environment initialization is complete (e.g., for Java it is produced when the JVM initialization is done).
The runtimeShutdown element is produced when the program runtime environment terminates (e.g., for Java it is produced when the JVM being traced is shutting down).
Turning to
Variations and modifications of the invention are contemplated. For example, the specific XML code fragments set forth herein are provided for the purpose of establishing a best mode of the invention. A person of ordinary skill in the art may conceive of other modes of expressing the functionality inherent in the disclosed code. Such a person may also conceive of further alternative embodiments of the invention, all of which are believed to fall within the sphere and scope of the invention as defined by the appended claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2340991 | Mar 2001 | CA | national |
| 2350735 | Jun 2001 | CA | national |
| Number | Name | Date | Kind |
|---|---|---|---|
| 6343287 | Kumar et al. | Jan 2002 | B1 |
| 6446136 | Pohlmann et al. | Sep 2002 | B1 |
| 6470332 | Weschler | Oct 2002 | B1 |
| 6484203 | Porras et al. | Nov 2002 | B1 |
| 6513155 | Alexander et al. | Jan 2003 | B1 |
| 6546548 | Berry et al. | Apr 2003 | B1 |
| 6651243 | Berry et al. | Nov 2003 | B1 |
| 6728949 | Bryant et al. | Apr 2004 | B1 |
| 6728955 | Berry et al. | Apr 2004 | B1 |
| 6732153 | Jakobson et al. | May 2004 | B1 |
| 6735758 | Berry et al. | May 2004 | B1 |
| 6751663 | Farrell et al. | Jun 2004 | B1 |
| 6754890 | Berry et al. | Jun 2004 | B1 |
| 6757720 | Weschler, Jr. | Jun 2004 | B1 |
| 6813731 | Zahavi et al. | Nov 2004 | B1 |
| 6839680 | Liu et al. | Jan 2005 | B1 |
| 20020128925 | Angeles | Sep 2002 | A1 |
| 20030067542 | Monroe | Apr 2003 | A1 |
| 20040098449 | Bar-Lavi et al. | May 2004 | A1 |
| 20040194025 | Hubert et al. | Sep 2004 | A1 |
| 20040205473 | Fisher et al. | Oct 2004 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20040210877 A1 | Oct 2004 | US |
