Runtime profiling of platform-independent software applications

TECHNICAL FIELD

[0001] The present invention relates in general to the profiling of runtime environments. More specifically, the present invention relates to a system and method for the runtime profiling of a software application and the platform-dependent code component(s) used by the software application.

BACKGROUND OF THE INVENTION

[0002] Software development projects are increasingly including a “portability” requirement mandating that the software application function without modification in a variety of different platform environments (e.g. are “platform neutral” or “platform independent”). Some programming languages such as Java and C# were designed to foster platform-independence and thus are “platform neutral.” Java uses an interface known as the “Java virtual machine” between the software application and the underlying technical architecture and operating environment (collectively “platform”) in order to render the platform transparent to the software application. Platform neutral application code components (referred to as “bytecode” in Java applications) leave all platform-dependent processing, information, and cognizance for the virtual machine. A “platform-independent” software application can be distributed across multiple platforms without modification of the software application.

[0003] “Platform independent” software applications need not be limited to Java, C#, or some other programming language that is specifically designated to be “platform neutral.” While other types and categories of programming languages may not have been specifically designed to create “platform neutral” software applications, a wide variety of different programming languages can utilize the Java virtual machine, a different non-Java virtual machine, or some other extra interface layer (collectively “virtual machine interface”) in order to support “platform-independence” in those particular programming languages. The use of a virtual machine interface can transform many different computer programming languages into “platform-independent” programming languages.

[0004] Regardless of the specific characteristics of the virtual machine interface, the flexibility of platform-independent software applications raises challenges with respect to the ability to profile the runtime environments of those software applications. A virtual machine interface typically incorporates computer code written in a variety of different languages, which means that the software application using the virtual machine architecture typically interacts with and utilizes at least one or more computer code components that are written in programming languages different from the programming language of the software application. In a virtual machine or platform-independent application architecture, the execution of a software application requires the use of an extra-layer of computer code residing in the virtual machine interface. It is this extra layer of computer code, with the extra set of code component interactions, that makes profiling difficult.

[0005] The profiling of runtime environments is a prudent and often necessary step in the software development process as well as with regards to the management of existing information systems. For example, software applications that function adequately with only a few users and merely hundreds of rows of data in a testing environment may not function adequately when thousands of users are invoking the application to interact with millions of rows of data on a database. The profiling of the runtime environment of a software application is useful in determining whether that particular software application is scalable to the point where the application can adequately perform in a production environment. Profiling may be particularly important in situations involving “platform neutral” software and architectures because the existence of an additional interface layer such as a virtual machine, results in more interactions between various components of the system because such systems typically utilize a more compartmentalized infrastructure.

[0006] Prior art profiling tools and techniques for platform-independent runtime environments are inadequate. The existing art does not provide a way to profile both the software application and the non-application code components used by the software application in an unobtrusive and dynamic manner. The attributes of an interface such as a virtual machine that provides for platform transparency also interfere with the existing techniques and tools for comprehensive profiling of the runtime environment. Some existing art has attempted to use embedded agents and other forms of intrusive specialized application processing to enhance profiling capabilities, but such intrusive measures alter the runtime environment being profiled, often negating much of the information derived from the embedded profiling agent. It would be desirable to be able to comprehensively profile a runtime environment in a non-intrusive manner.

SUMMARY OF THE INVENTION

[0007] The present invention provides a profiling system for runtime environments that include a software application written in a platform-independent programming language, a non-application-code component invoked by the software application and a profiling tool for generating a runtime metric. The runtime metric includes an application metric and a non-application-code metric. The profiling tool generates the application metric from the software application and the non-application-code metric from the non-application-code component.

[0008] The present invention also provides a method for profiling the runtime environment of an application-code component by executing the application-code component in a runtime environment that includes a non-application code component, running a profiler with respect to the executing application-code component, generating an application-code metric from the application-code component with the profiler, and creating a non-application-code metric from the non-application-code component with the profiler. The application-code metric and the non-application-code metric are preferably generated from one execution of the application-code component in a runtime environment.

[0009] The present invention also provides a profiling tool stored on a medium for storing computer-readable instructions. The profiling tool, when executed, generates a runtime metric, the runtime metric including an application metric and a non-application-code metric. The profiling tool generates the application metric from a software application and the non-application-code metric from a non-application-code component used by the software application.

BRIEF DESCRIPTION OF THE DRAWINGS

P-0010[0010] Certain embodiments of present invention will now be described, by way of examples, with reference to the accompanying drawings, in which:

P-0011[0011]FIG. 1 is a high-level flow diagram illustrating one example of a distributed processing architecture, with separate application, database, and proprietary code base servers.

P-0012[0012]FIG. 2 is a data listing illustrating one example of the runtime metrics generated by a prior art profiler.

P-0013[0013]FIG. 3 is a data listing illustrating one example of the runtime metrics generated by a profiling tool capable of performing comprehensive runtime metrics.

P-0014[0014]FIG. 4 is structural diagram illustrating the progression from enterprise tools, to system tools, to one example of a profiling tool capable of generating application metrics from a software application, virtual machine metrics from a virtual machine, and kernel metrics from a kernel.

P-0015[0015]FIG. 5 is a structural diagram illustrating one example of a profiling system that can generate useful application metrics, including both class and method information, by communicating through the operating system.

P-0016[0016]FIG. 6 is a time-flow diagram illustrating one example of a profiling system being invoked before the execution of a software application.

P-0017[0017]FIG. 7 is a time-flow diagram illustrating one example of a profiling system using an activation signal to comprehensively profile a software application that is executed before the invocation of the profiling system.

P-0018[0018]FIG. 8 is a process-flow diagram illustrating one example of how a method map can be used by a profiling tool.

P-0019[0019]FIG. 9 is a process-flow diagram illustrating the inner workings of the virtual machine after the activation of the profiling mechanism.

P-0020[0020]FIG. 10 is a process-flow diagram illustrating one example of a kernel processing subsystem, and how interactions between the kernel profiling subsystem and a virtual machine can be used to generate comprehensive runtime metrics.

P-0021[0021]FIG. 11 is a process-flow diagram illustrating an example of how various pointers and tables can be used to generate runtime metrics.

P-0022[0022]FIG. 12 is one example of a messaging protocol that be used by the profiling tool.

P-0023[0023] Throughout the drawings, identical reference numbers indicate similar, but not necessarily identical, elements.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

P-0024[0024] I. Introduction and Definitions

P-0025[0025] The present invention is a method and system for comprehensively profiling a runtime environment of a software application in a non-intrusive manner. FIG. 1 illustrates one of many potential embodiments of a profiling system (or simply “the system”) <b>20</b> in a distributed processing environment. The profiling system <b>20</b> can be incorporated in a wide variety of different embodiments, and can include a wide variety of different interfaces, software applications, operating systems, programming languages, object libraries, function libraries, computer hardware, architecture configurations, processing environments, operating systems, and other environmental characteristics. The profiling system <b>20</b> can be applied to potentially any component in FIG. 1.

P-0026[0026] A. The Runtime Environment

P-0027[0027] The runtime environment of a software application profiled by the system <b>20</b> includes two primary types of software or computer code components, application-code components and non-application-code components.

P-0028[0028] 1. Application-code Components

P-0029[0029] The first type of code component that can be profiled by the system <b>20</b> is the software application (“application-code” component). In many embodiments of the system <b>20</b>, the application code will be an application or applet (collectively “application code”) written in the platform-independent programming language of JAVA®. JAVA is a registered trademark of Sun Microsystems, Inc., located in Mountain View, Calif. However, the invention is not limited to profiling JAVA application code only. For example, the present invention can be applied to any platform-independent software application.

P-0030[0030] A “platform-independent” software application means that the application code is “platform neutral” (e.g. that it can be distributed and run across different technical platforms). “Platform-independent” is synonymous with “platform neutral” with respect to the types of software applications that can be profiled by the system <b>20</b>. An example of platform neutral application-code is “bytecode” in the Java programming language. Alternative embodiments of the system <b>20</b> may utilize other platform-independent programming languages, and/or platform-independent techniques (such as virtual machines or other interfaces) not related to the programming language of Java or similar languages such as C#. An example of the latter is the PA-RISC application emulation environment provided by the Aries runtime environment on HP-UX running on the Itanium processor family.

P-0031[0031] As discussed above, virtual machines and other forms of interfaces (collectively “virtual machine interfaces”) between a software application and the underlying technical architecture and operating environment (collectively “platform”) can render the software application “neutral” to any particular platform. Virtual machine interfaces can transform a computer programming language not known for high portability and platform neutrality, into a “platform-independent programming language.” Other alternative embodiments of the system <b>20</b> do not require the use of a virtual machine interface.

P-0032[0032] Platform-independent programming languages and techniques typically facilitate platform neutrality and portability by positioning an interface layer between the software application and the underlying technical platform, rendering the underlying technical platform transparent to the software application. The software application can thus interact with the highly abstract and generic virtual machine interface, instead of a particular platform with platform specific characteristics. Thus, it is not uncommon for a virtual machine interface to incorporate code components written in a variety of different languages. This means that the software application using the virtual machine interface typically interacts with and utilizes computer code components that are written in one or more programming languages that are different from the programming language of the software application itself. In a virtual machine interface, the executing of a software application utilizing the virtual machine necessarily invokes computer code components within the virtual machine that enable the virtual machine to function as a virtual machine.

P-0033[0033] One common example of a virtual machine is the “Java virtual machine” (“JVM”) that is typically used in conjunction with software applications and applets (collectively “applications”) written in Java. However, the Java virtual machine can be configured or extended to operate for other programming languages rendering those languages potentially “platform independent.” Similarly, other virtual machines designed with a particular application language in mind can be configured to allow utilization by application code components of a different type. For example, a C++ virtual machine could render C++ “platform independent.”

P-0034[0034] There are many different combinations and environments that can utilize one or more different embodiments of the profiling system <b>20</b>. However, platform neutral architectures and interfaces tend to present greater profiling challenges than other architectures and platforms due to the different language combinations, the nature of virtual machines, and the greater number of code components that typically need to interact with each other when platform neutral techniques are used. Despite the difficulties associated with such environments, the system <b>20</b> can comprehensively profile platform-independent runtime environments as well as environments based on more traditional structures and languages, in a non-intrusive manner. The system <b>20</b> does not need to utilize embedded agents to obtain profiling information (e.g. “runtime metrics”). Moreover, use of the profiling system <b>20</b> does not require any special preparation of the software application. The profiling system <b>20</b> can be invoked either before or after the software application to be profiled is executed. Use of the profiling system <b>20</b> does not require any cognizance of the profiling system <b>20</b> or a known or expressed intention by a human user or automated system utility (collectively “invocation interface”) to profile the software application, at the time in which the software application is executed.

P-0035[0035] 2. Non-application-code Components

P-0036[0036] The second type of code component includes all types of code components not included in the application code component. The second type of code component can be referred to as “support code,” “environmental code,” or simply “non-application-code.” Non-application-code includes any code component that does not reside within the application code component, but is needed by the application code in order for the application code to function properly. Categories of non-application-code can include libraries of reusable functions (written in programming languages that are either identical, similar, or different than the software application), libraries of reusable objects, databases, network communication tools, code used for the functioning of the virtual machine, the operating system, and assembly language communications to the underlying hardware on the system <b>20</b>.

P-0037[0037] a. External Instrumentation Code

P-0038[0038] Amongst other non-application-code components, the system <b>20</b> includes an “external instrumentation” subsystem of external instrumentation code (“instrumentation code”) that can perform CPU (central processing unit) sampling and that can provide a communication facility to incorporate “traces” generated by the application code. Traces are described in greater detail below. As described below, the external instrumentation subsystem used by the system <b>20</b> is non-invasive to the software application. Typically, the external instrumentation subsystem will function through the operating system, and thus can be referred to as a “kernel profiling” subsystem that includes “kernel code” components. Alternative embodiments may utilize other forms of external instrumentation. Kernel instrumentation is used in a preferred embodiment because instrumentation processing is closely related to core operating system functionality, and can be used to monitor operating system functions such as launching applications and allocating system resources. Regardless of the specific type of external instrumentation, the external instrumentation subsystem includes instrumentation points that allow runtime measurements, optimizations, and extensions to be included in the runtime metrics generated by the system <b>20</b>.

P-0039[0039] b. Virtual Machine Code (“VM Code”)

P-0040[0040] Code components relating to the virtual machine can be referred to as “virtual machine code components” or “virtual machine code.” Code components written in a programming language different than the language of the software application can be referred to as “native code components” or “native code.” In a typical Java environment, the terms “virtual machine code” and “native code” are generally synonymous because the code making up the virtual machine is typically written in a non-Java language such as C or C++. Use of the profiling system <b>20</b> does not require the embedding of “agents” into the support code or environmental code being profiled.

P-0041[0041] C. Other Types of Non-application Code

P-0042[0042] There are numerous other types of non-application code components. These include platform specific libraries of reusable functions (written in programming languages that are either identical or similar to, or different from, the software application), libraries of reusable objects, the operating system, and assembly language communications to the underlying hardware on the system <b>20</b>. Operating systems are computer programs with their own code components and processing. Many other types of non-application code relate to particular devices or communication protocols. The system <b>20</b> is capable of generating runtime metrics for many such non-application-code components.

P-0043[0043] B. Runtime Metrics

P-0044[0044] The profiling system <b>20</b> analyzes the runtime environment of the application-code-component and the non-application-code component(s) used by that software application to support the running of the application-code component. A runtime metric can be any characteristic or attribute relating to the runtime environment of the software application. A time-stamped compilation log of the software application is one example of a runtime metric. Many embodiments of the system <b>20</b> will generate multiple runtime metrics relating to the runtime environment, each capturing a different aspect of the system under measurement. There are a wide variety of different runtime metrics that can be tracked and reported by the system <b>20</b>. Some runtime metrics relate to the overall use of an application (“aggregate runtime metrics”). For example, one runtime metric may be the number of assembly level hits to the operating system that resulted from the execution of the software application. Other aggregate runtime metrics can include the length of operating system time consumed by the assembly level hits, the compilation time of the software application, kernel timing clocks (“KTC”), and a time-stamped compilation log. Alternative embodiments may utilize a wide variety of different runtime metrics.

P-0045[0045] Runtime metrics can also relate to a particular function, routine, object or file (“component runtime metrics”). One example of a component runtime metric is the percentage of KTC time that was consumed by a particular process, method, or function (collectively “instruction”). Other examples of component runtime metrics include assembly level hits resulting from the particular component, the time consumed by the assembly level hits by the particular component, the order in which the routines were accessed, the filenames accessed by the particular routine, and the communications passed between routines. Alternative embodiments can include other forms of class, method, process, or function information.

P-0046[0046] Runtime metrics can also be referred to in relation to the particular structural component. For example, a kernel metric is a category of one or more runtime metrics generated by the profiling system <b>20</b> that relate to the external instrumentation (e.g. kernel). Similarly, a native-code metric is a category of one or more runtime metrics generated by the profiling system <b>20</b> from the native-code components in a native-code library. An application metric is a category of one or more runtime metrics generated by the profiling system <b>20</b> from the application-code components in the software application. The application metric can include both class (e.g. object) information and method (e.g. process) information, in addition to information relating to data structures and particular variables. An operating system metric is a category of one or more runtime metrics generated by the profiling system <b>20</b> that relate to the operating system. In many embodiments, operating system metric is synonymous with kernel metric. A virtual machine metric is a category of one or more runtime metrics generated by the profiling system <b>20</b> that relate to the virtual machine. Thus, in many circumstances, virtual machine metric is synonymous with native-code metric.

P-0047[0047] Runtime metrics can also provide information relating to the compilation of various components, especially when those components are compiled at runtime. A compilation metric is a category of one or more runtime metrics generated by the profiling system <b>20</b> that relate to the compiling of a code component used by the software application. The compilation metric can include a compiler log that tracks the order and date/time of compilation or de-compilation. With certain programming languages such as Java, methods and routines can be re-compiled in a dynamic (i.e., non-static) manner at runtime. Different embodiments of the system <b>20</b> can focus different levels of attentiveness on different categories of runtime metrics.

P-0048[0048] C. Hardware Configuration

P-0049[0049] Returning to FIG. 1, the profiling system <b>20</b> can be invoked by means of a client computer (“client”) <b>22</b>. The invocation of the profiling system <b>20</b> can be through a user accessing the client <b>22</b> through a user interface, which is a type of invocation interface for the system <b>20</b>. Other types of invocation interfaces can exist for the system <b>20</b>. For example, the profiling system <b>20</b> can also be automatically invoked by a particular event (such as a failure or error) or an elapsed period of time. Thus, the profiling system <b>20</b> can be configured to activate periodically in an automated fashion by the client <b>22</b> or some other computer, without any human intervention.

P-0050[0050] The client <b>22</b> can be any type of device capable of communicating with another device, including but not limited to a desktop computer, laptop computer, work station, mainframe, mini-computer, terminal, personal digital assistant, satellite pager, or cell phone. The software application can be executed from a different client than the client <b>22</b> used to invoke the profiling system <b>20</b>.

P-0051[0051] The application/web server <b>24</b> typically houses the software application profiled by the profiling system <b>20</b>. As described above, the software application may require the use of a native-code library at runtime. The native-code library can reside in: the application/web server <b>24</b>; a proprietary code base server <b>28</b>; partially in the application/web server <b>24</b> and partially in the proprietary code base server <b>28</b>; or in some other server or combinations of servers. Any device capable of running a software application and communicating with other devices can potentially serve as an application/web server <b>24</b>. In many embodiments, the application/web server <b>24</b> will possess greater computing power than a client <b>22</b> because the application/web server <b>24</b> will often need to support numerous clients <b>22</b>. The client <b>22</b> can communicate with the application/web server <b>24</b> in a wide variety of different ways. The client <b>22</b> and application/web server <b>24</b> can be connected by a Local Area Network (“LAN”), a Wide Area Network (“WAN”), the Internet, an extranet, an intranet, a wireless network, or any other form of device-to-device communication. In many embodiments of the system <b>20</b>, the invocation interface invoking the profiling system, the profiling system <b>20</b>, and the software application will each reside in different devices and thus are remote from each other. It may be the case that some or each of various locations is protected and separated by a firewall. The system <b>20</b> can still be launched and fully utilized in such an environment, despite the remote location and the existence of one or more firewalls, so long as the software application can itself be accessed remotely through a user session. Moreover, the profiling system <b>20</b> does not interfere or modify the flow of control in the software application.

P-0052[0052] The profiling system <b>20</b> can also include additional components such as a database <b>26</b> and/or a proprietary code base <b>28</b>. The database <b>26</b> can be located on a separate server reserved exclusively for the database. The configuration of the database <b>26</b> is largely dependent on the software applications using the database. The database can reside in a wide range of different types of devices, just as the client <b>22</b> and application/web server <b>24</b> described above.

P-0053[0053] The proprietary code base <b>28</b> can contain libraries of reusable functions, libraries of reusable objects, the code components making up the virtual machine, native-code components, and virtually any other code component that is not application code. The proprietary code base can reside in a wide range of different types of devices, just as the client <b>22</b>, application/web server <b>24</b>, and database <b>26</b>, as described above.

P-0054[0054] In most embodiments, the various hardware components in FIG. 1 can all communicate directly with each other. Different embodiments can utilize different degrees of distributed processing techniques and structures.

P-0055[0055] II. Runtime Metrics

P-0056[0056]FIG. 2 is an example of a runtime metric listing generated by a prior art profiling tool. The runtime metrics illustrated in the FIG. 2 exemplify one of the weaknesses in prior art profiling tools, the inability to comprehensively profile both the software application and the non-application-code components that are necessary for the functioning of the software application. The particular example illustrated in FIG. 2 relates to a software application written in the programming language of Java. The example in FIG. 2 is widely applicable to other platform-independent programming environments that utilize virtual machines and similar interfaces.

P-0057[0057] At the top of the profile is an indication that the runtime metric relates to a user portion <b>30</b> of the profile. “User” in this context refers to non-privileged mode execution of code, a feature supported by most existing operating systems. FIG. 2 reveals both a header section <b>31</b> containing a series of “aggregate runtime metrics” and a detail section <b>33</b> listing runtime metrics relating to particular instructions (e.g. “component runtime metrics”). The aggregate runtime metrics are displayed at the top of the listing and the component runtime metrics are displayed in the rows of data under the column headers of percentage, hits, seconds, address, routine name, and filename.

P-0058[0058] The runtime metrics include useful data such as the total number of “assembly level hits” (6,220 hits), the amount of processing time consumed by those “assembly level hits” (62.20 seconds), and the kernel timing clocks (KTC) components (61.247 seconds). The prior art profiler is significantly less successful in its attempt to provide metrics relating to application-code components (“application metric”). This inability to profile the internal components/instructions of the software application is evidenced by the first row of data in the detail section <b>33</b>. For the purpose of highlighting this important row, the data is displayed in bold. The first row of component runtime metrics <b>33</b> aggregates all of the application metrics into a single row, failing to identify any of the objects, routines, or other information internal to application-code components. The 83% at 32 reveals the percentage of assembly level hits that resulted from all application-code components, in the aggregate. Thus, the address information of “0x6d400000” is meaningless because the various components of the software application actually reside at different memory locations. Similarly, the routine name at 34 of “Self-generated code” does not identify any of the routines and correspondingly, no filenames are indicated. “2152 unique instructions” fails to reveal any information about any particular filename or routine. The inability to distinguish between different application-code components is an example of prior art limitations with respect to the profiling of runtime environments. In contrast, the system <b>20</b> has the ability to distinguish between different application code components in generating runtime metrics.

P-0059[0059]FIG. 3 illustrates the runtime metrics of the profiling system <b>20</b> according to principles of the present invention. The data from FIG. 3 can be contrasted with the data listing in FIG. 2 to illustrate the improved functionality of the profiling system <b>20</b>, and the runtime metrics that can be generated. A user profile <b>36</b> in the profiling system <b>20</b> is able to profile both application-code components as well as non-application-code components in a comprehensive and specific manner, without any embedded agents. There can be aggregate runtime metrics <b>37</b> in FIG. 3 that were not captured as aggregate runtime metrics <b>31</b> in FIG. 2 because the inability to accurately profile application components to generate application metrics affects the ability to generate aggregate runtime metrics. Thus, the ability to the system <b>20</b> to obtain information relating to individual instructions, objects, functions, and other information that exists within application-code components, also serves to make the system <b>20</b> a better generator of aggregate runtime metrics, kernel runtime metrics, and compiler runtime metrics than prior art profiling tools.

P-0060[0060] Some of the distinctions between the component runtime metrics <b>33</b> in FIG. 2 and the component runtime metrics <b>39</b> in FIG. 3 are also illustrated in FIG. 3. The first row in FIG. 3 looks substantially different the first row in FIG. 2 because the application-code components are broken down into the various routines and objects of the software application. The percentage of 10% at <b>38</b> is much less than the 83% on FIG. 2 because the application-code components are broken down into individual components. Similarly, the number of hits (704), number of seconds (7.04), and address location (0x6dc2b4a0) relate to a particular routine name (longStaticBTree) and a particular filename (specjbb.infra.collections). The system <b>20</b> provides the ability to generate a detailed breakdown of runtime metrics relating to specific application-code components. This is in sharp contrast to being limited to a single runtime metric that lumps together in a single “bucket,” all runtime metrics relating to the application-code components.

P-0061[0061] The runtime metrics in FIG. 3 are only one example of an embodiment of the system <b>20</b>. There are numerous other potential embodiments with a wide range of different runtime metrics that can be generated by the system <b>20</b>.

P-0062[0062] III. System Components

P-0063[0063] The profiling system <b>20</b> can be embodied in a wide variety of different platforms, with a wide variety of different application programs written in a wide variety of different programming languages. Incorporating the profiling system <b>20</b> into an existing architecture may require changes to the existing architecture, depending on the capabilities of the existing architecture, in particular, the capabilities related to profiling and platform independent application support.

P-0064[0064]FIG. 4 is a structural diagram of the profiling system <b>20</b> being used to profile the runtime environment of a software application <b>52</b> written in the programming language of Java. Alternative embodiments can employ different programming languages with different structures. The system <b>20</b> can be implemented in a wide variety of different embodiments, with each embodiment incorporating different management and information tools into the system <b>20</b>.

P-0065[0065] On the left side of the diagram in an enterprise tool <b>42</b>. Enterprise tools <b>42</b> are used to find a particular system, and to manage various components and communications across numerous different large systems. An enterprise view of information technology is a high level and comprehensive view of the information technology for an entire enterprise (e.g. company, government, or other organization). One example of commercially available enterprise tools is OpenView. OpenView is an enterprise-wide tool for managing large systems and networks. OpenView is a product of Hewlett-Packard Company, headquartered in Palo Alto, Calif. The profiling system <b>20</b> can be integrated with such enterprise tools, or other types and variations of such tools in order to maximize the benefit of runtime metrics generated by the system <b>20</b>. In alternative embodiments, the profiling system <b>20</b> can be built with the same functionality of enterprise tools <b>42</b>, removing the desirability of interfacing with other software products. The profiling system <b>20</b> does not need to incorporate enterprise tools <b>42</b> in order for the system <b>20</b> to function.

P-0066[0066] Moving towards the right side of the diagram, the various components become more specific to particular types of software components. The enterprise tool(s) <b>42</b> may interface with a system tool <b>44</b>. The function of a system tool <b>44</b> is to monitor or profile an entire system, not the profiling of a particular runtime environment at the routine-level. For example, one type of system tool <b>44</b> may exist to support all of the accounting software systems used by a particular enterprise. In some embodiments, the profiling system <b>20</b> can also perform all of the functions of the system tool <b>44</b>. This can be accomplished by interfacing with a commercially available system tool <b>44</b> such as Glance, or by incorporating the desired functionality directly into the profiling system <b>20</b>. Glance is system level monitoring tool that provides information regarding the number of system calls and a wide variety of other operating system metrics. Glance is a commercially available product of the Hewlett-Packard Company, headquartered in Palo Alto, Calif.

P-0067[0067] A profiler or profiling tool <b>45</b> can be integrated with the enterprise tools <b>42</b> and system tools <b>44</b> described above. However, the integration or interfacing of the profiling system <b>20</b> with enterprise tools <b>42</b> and/or system tools <b>44</b> is not required for the functioning of the profiling system <b>20</b>. Such functionality can be implemented directly into the profiling system <b>20</b>. Moreover, such functionality is not required for the profiling system <b>20</b> to generate runtime metrics.

P-0068[0068] In some embodiments of the system <b>20</b>, the profiler or profiling tool <b>45</b> used by the system <b>20</b> can simultaneously incorporate the functionality of one or more specialist profilers. An application profiler <b>46</b> is responsible for profiling the application code component. In an embodiment with a Java software application <b>52</b>, the application profiler <b>46</b> is a Java profiler. Some Java embodiments of the system <b>20</b> incorporate customized and modified versions (the modifications are discussed below) of existing commercially available application profilers such as HPjmeter by Hewlett-Packard. In alternative Java embodiments of the system <b>20</b>, the application profiling tool <b>46</b> does not interface with any other profiling tool, and all functionality is created within the application profiling tool <b>46</b> itself. In non-Java embodiments, the application profiler <b>46</b> is specific to the category or type of programming language used to write the software application <b>52</b>.

P-0069[0069] The profiling tool <b>45</b> can also include a native-code profiling tool <b>48</b>. In a Java embodiment of the system <b>20</b>, much of the native-code will be in the form of the Java virtual machine <b>54</b>. In non-Java embodiments, the native-code <b>54</b> being profiled can be the code for a virtual machine or some other form of interface. The existence of a native-code profiler <b>48</b> is not required by the system <b>20</b> if there is no native-code <b>54</b> to profile.

P-0070[0070] The profiling tool <b>45</b> can also include a kernel profiling tool <b>50</b> (or other form of external instrumentation tool) for profiling the kernel <b>56</b> of the runtime environment. The kernel is the core of an operating system, the portion of the operating system that manages memory, files, and periphery devices. The kernel is also the part of the operating system that launches applications and allocates system resources in a runtime environment. Some embodiments of the system <b>20</b> will incorporate modified versions of existing native code profilers <b>48</b> and kernel profiling tools <b>50</b>. Other embodiments of the system <b>20</b> will provide all profiling functionality internally. In some embodiments, an operating system profiling tool is used in place of the kernel profiling tool, and the metric generated is called an operating system runtime metric.

P-0071[0071] Regardless of whether the profiling tool <b>45</b> used by the system <b>20</b> interfaces with other profiling tools or houses all profiling functionality internally, the profiling tool <b>45</b> used by the system <b>20</b> operates through the kernel <b>56</b> (or more generally, the operating system) to obtain the runtime metrics, including runtime metrics not relating to the operating system or kernel, such as application-code metrics. As described below, kernel instrumentation information and a method map can be used by the system <b>20</b> to provide comprehensive and non-intrusive profiling of the runtime environment of the software application. The system <b>20</b> can also incorporate other instrumentation external to the application-code components, to obtain external or kernel metrics.

P-0072[0072]FIG. 5 is a block diagram illustrating one example of an embodiment of the structure that can be incorporated into the system <b>20</b>. At the top of the diagram is the software application <b>52</b>. The software application <b>52</b> includes the executable application code component, and any other application-code components that can be utilized by the software application. In a Java embodiment of the system <b>20</b>, the application code <b>52</b> is written in Java, and the application is either a Java applet or application (collectively “application”).

P-0073[0073] Underneath the software application is a native interface <b>60</b> and a virtual machine <b>62</b>. In a Java embodiment of the system <b>20</b>, the native interface <b>60</b> is a Java native interface (“JNI”) and the virtual machine is a Java virtual machine (“JVM”). Java Native Interface <b>60</b> is a standard programming interface for writing Java native methods and embedding the Java virtual machine <b>62</b> into native (non-Java) software applications. One primary goal is interface compatibility of native method libraries across all Java virtual machine implementations. The Java virtual machine (JVM) <b>62</b> is a virtual computer, typically implemented in software on top of an actual hardware platform and operating system, that runs compiled Java programs. The Java virtual machine <b>62</b> facilitates portability and platform independence, as discussed above. In non-Java embodiments, the native interface <b>60</b> and virtual machine <b>62</b> perform essentially the same functions as they do in the Java embodiments, although more customization may be required in such embodiments. Moreover, even non-Java embodiments can use a Java virtual machine <b>62</b>. In a non-Java embodiment, native-code components are supporting code components that are written in a programming language that is different from the programming language used to write the software application <b>52</b> and other application-code components.

P-0074[0074] Beneath the virtual machine <b>62</b> is a native library <b>64</b>. In many embodiments, the virtual machine <b>62</b> will include non-application-code components written in a different language than the software application <b>52</b>. The code components used to run the virtual machine can require the use of reusable functions and other code components. Such code components can be stored as native-code components in the native library <b>64</b>.

P-0075[0075] Underneath the native interface <b>60</b> and the native library <b>64</b> is an operating system <b>66</b>, which includes a kernel for core operating system functions such as launching (executing) software applications, allocating system resources, managing memory, managing files, and managing periphery devices. The system <b>20</b> can be embodied with a wide variety of different operating systems such as Unix, Linux, Windows, and other commercially available and/or proprietary operating systems.

P-0076[0076] In many embodiments of the system <b>20</b>, a profiling tool <b>45</b> obtains runtime metrics through the operating system <b>66</b> as illustrated in FIG. 6. Between the profiler <b>45</b> and the block of code including the application <b>52</b>, the native interface <b>60</b>, the virtual machine <b>62</b>, and the native library <b>64</b>, is the operating system <b>66</b>. The interactions between the profiling tool <b>45</b> and the operating system <b>66</b> are described in greater detail below.

P-0077[0077] The profiling tool <b>45</b> produces a comprehensive set of runtime metrics including class and method information internal to the software application <b>52</b>. As discussed above, the comprehensive information illustrated in FIG. 3 is in contrast to the “self-generated code” listing in FIG. 2.

P-0078[0078] IV. Use of the Profiling Tool

P-0079[0079] The profiling tool <b>45</b> used by the system <b>20</b> can be applied before the software application <b>52</b> is executed or after the software application is executed. At the moment in which the invocation interface triggers the execution of the software application <b>52</b>, the system <b>20</b> need not be cognizant of any intention relating to the profiling of the runtime environment for that software application <b>52</b> at the time that the software application <b>52</b> is executed. The system <b>20</b> does not require the use of embedded agents, and is designed to facilitate comprehensive profiling without intrusive measures to the software application (external instrumentation such as kernel profiling is non-intrusive). Nor does the system <b>20</b> require any special form of preparation or modification of the software application <b>52</b> in order to perform comprehensive profiling of the software application <b>52</b>.

P-0080[0080]FIG. 6 is timeline diagram illustrating the invocation of the profiling tool <b>45</b> before the invocation of the virtual machine <b>62</b> or the software application <b>52</b>. In such an embodiment, the profiling begins from the initialization of the virtual machine <b>62</b>. The entire life cycle of the software application <b>52</b> can be profiled. At <b>67</b>, the passing of class and method information to the kernel can begin. In many Java embodiments of the system <b>20</b>, a command line flag at 67 is used to enable the passing of class and method information to the kernel (or other form of external instrumentation) so that the profiling tool can then generate runtime metrics, including but not limited to kernel metrics (or other form of external instrumentation metrics).

P-0081[0081]FIG. 7 is a timeline diagram illustrating the invocation of the profiling tool <b>45</b> after the software application <b>52</b> has been running for some time. Such a use of the system <b>20</b> uses a method map <b>70</b> in the runtime environment and a signal mechanism <b>71</b> to activate the communication between the runtime environment and the kernel profiling interface. The profiling tool <b>45</b> can asynchronously attach to the running application <b>52</b>.

P-0082[0082] The method map <b>70</b> is tied to the particular virtual machine <b>62</b>, so the method map <b>70</b> should be part of the runtime environment for software applications <b>52</b> profiled by the system <b>20</b>. In many Java runtime embodiments of the system <b>20</b>, the method map is a data structure with the attributes of a hash table data structure. The first_instruction of each entry in the method map is the hash table key. Each hash table slot corresponds to a subspace of memory that holds a finite group of platform specific versions of application code methods. Each slot chain in the method map <b>70</b> can hold the method map entries in the corresponding memory subspace. Each slot chain can be ordered by the first_instruction for the entries within that chain. The method map is described in greater detail below. The signal mechanism <b>71</b> can be used to indicate when the profiling time commences, and also when the profiling time is to expire, and the profiling system <b>20</b> is to cease processing. Profiling can also be silently discontinued by terminating the profiler <b>45</b>. As illustrated in FIG. 7, the profiler tool <b>45</b> can cease processing before the software application <b>52</b> terminates.

P-0083[0083] V. The Method Map

P-0084[0084] The method map <b>70</b> is used by the system <b>20</b> to correlate the runtime metrics at the individual routine or “instruction” level. FIG. 8 is an illustration of the how the method map <b>70</b> can be used by the system <b>20</b>. The execution of a particular instruction, method, thread, routine, or process (collectively “instruction”) in the runtime environment is recorded in a data structure by the profiling system <b>20</b>, so that runtime metrics can be generated that include application metrics relating to the various instructions.

P-0085[0085] In a Java runtime embodiment, a runtime compiler creates platform specific versions of instructions (e.g. compiled code <b>72</b> ) that are executed by the application. The runtime compiler can be instructed to generate platform specific versions of all instructions, or can be limited to generate platform specific versions of only a few selection instructions. A method map table can be instantiated to act as a repository of information about instructions that currently have platform specific versions. The method map table can capture such information as the application server <b>24</b> on an instruction-by-instruction basis as the runtime compiler processes these routines to generate platform specific versions. In non-Java embodiments, other objects, data structures, and/or files can be used to fulfill the same functionality. The memory used to hold the platform specific versions of the routines can be logically partitioned into various subspaces <b>74</b>, with each subspace holding a finite collection of the routines. The size of such subspaces can be arrived through consideration of the various tradeoffs, and alternative embodiments may utilize subspaces that vary widely in storage capacities.

P-0086[0086] The method map <b>70</b> can have a hash table data structure to minimize the time and resource consumed for adding entries, deleting entries, and searching entries on the table <b>70</b>. The method map <b>70</b> can have virtually as many slots as are needed, up to N slots, where N can represent the number of application code instructions invoked in the runtime environment during the profiling of the software application <b>52</b>. Each slot on the method map should preferably correspond to a memory subspace <b>74</b>. The component runtime metrics correlators are loaded into the method map <b>70</b>. The first_instruction of each entry is the hash table key. Each slot can hold the method map entries whose first_instruction is in the corresponding memory subspace <b>74</b>. Each slot chain can be ordered by the first_instruction for the particular entry. The types of links data formats used by the method map can vary widely in a wide variety of different embodiments.

P-0087[0087] A header table <b>79</b> can be used to further optimize the process of adding or deleting content from the method map <b>70</b>. In the header table, _low <b>80</b> is the instruction_start for a first_entry <b>84</b> in the slot, _high <b>81</b> is the instruction_start for a last_entry <b>88</b> in the slot, _first <b>81</b> designates a first_entry <b>82</b>, and_last <b>83</b> designates a last_entry <b>88</b>. The first_entry <b>84</b> though last_entry <b>88</b> (including all entries <b>86</b> in between the first_entry <b>84</b> and the last_entry <b>88</b>) in the slot can further contain method map entries (MethodMapEntries) such as the example displayed in Table A. In non-Java embodiments, the equivalent entry can be created. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE A</entry></row><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>MethodMapEntries</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><tbody valign="top"><row><entry /><entry>EntryType</entry><entry>_type</entry></row><row><entry /><entry>MethodMapEntry</entry><entry>*_next</entry></row><row><entry /><entry>Address</entry><entry>first_instruction</entry></row><row><entry /><entry>Address</entry><entry>last_instruction</entry></row><row><entry /><entry>Int</entry><entry>frame_size</entry></row><row><entry /><entry>MethodInfo</entry><entry>*_methodDescriptor</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

P-0088[0088] Runtime metrics can be generated as a part of the process of adding or deleting entries from the method map <b>70</b>. The runtime metrics can act as a correlator or “meta data” that helps the profiler in the system <b>20</b> generate application code metrics from samples observed by the profiler through the utilization of the kernel processing subsystem. If runtime metric collection is activated dynamically through the use of the signal mechanism, all the entries generated from the beginning of the application run are communicated to the profiler by traversing the method map table. The aggregate runtime metrics are generated by either aggregating the various component runtime metrics, and/or by using some of the additional tools and components described in FIG. 4.

P-0089[0089]FIG. 9 is a process flow diagram illustrating the inner workings of the virtual machine <b>62</b> after a profiling activation <b>89</b>. A runtime compiler <b>90</b> generates the compiled code <b>72</b> and sends the relevant information to the method map <b>70</b>. The interactions between the method map <b>70</b> and the compiled code <b>72</b> are described in greater detail above. The method map <b>70</b> communicates with the external instrumentation (such as the kernel) through an interface (such as a kernel instrumentation interface <b>91</b> ). Thus, in a preferred embodiment of the system <b>20</b>, the data contained in the header table <b>79</b> of the method map <b>70</b> is sent to the kernel through the kernel instrumentation interface <b>91</b>. Examples of external instrumentation subsystems such as the kernel profiling subsystem are described in greater detail below.

P-0090[0090] VI. External Instrumentation Subsystem

P-0091[0091] As discussed above, the system <b>20</b> uses an external instrumentation subsystem to capture traces generated by the application code <b>52</b> and to perform CPU sampling. In a preferred embodiment the system <b>20</b>, the external instrumentation subsystem is a kernel profiling subsystem because instructions are ultimately performed at the operating system level. Regardless of the exact nature of the external instrumentation, external instrumentation provides a useful way for the system <b>20</b> to generate runtime metrics in a comprehensive and non-intrusive manner. Using kernel instrumentation, dynamic updates of compiled method information can be generated by the system <b>20</b>. Use of kernel instrumentation requires minimal overhead to the running software application <b>52</b>. Kernel instrumentation does not occupy any application resources such as a network port or a file descriptor on any client <b>22</b> or any other computer housing software code components in the runtime environment. Moreover, the entire kernel profiling subsystem does not occupy a single port on the client <b>22</b> or any other computer housing software code components used in the runtime environment. Kernel instrumentation can also be turned off if the profiling system <b>20</b> is not being used. The kernel profiling subsystem updates the compiled method data record in a dynamic manner.

P-0092[0092]FIG. 10 illustrates one embodiment of how the kernel and the virtual machine interface interact to enable the system <b>20</b> to provide comprehensive runtime metrics in a non-intrusive manner. The virtual machine <b>62</b> as described above is the interface between the software application <b>52</b> that is written in a platform-independent programming language. The underlying platform includes the operating system <b>66</b> and the kernel. The virtual machine <b>62</b> interacts with the kernel on behalf of the software application and the various code components used to support the software application in a runtime environment.

P-0093[0093] The virtual machine <b>62</b> can invoke the kernel instrumentation interface to generate a kernel instrumentation trace <b>92</b> to provide runtime environment information (e.g. the raw data that will ultimately be used by the system <b>20</b> to generate runtime metrics) to a kernel instrumentation buffer <b>78</b>. Instrumentation buffers can be used to find out how many events of a given type happened to the kernel during the execution of the application-code components <b>52</b>. A “trace” is the observance of potentially any type of “event” in the kernel that reflects the type of processing requiring profiling by the system <b>20</b>. Information about an event can be stored in the kernel instrumentations buffer <b>96</b>, which can be an object, an array, or some other data structure. The kernel instrumentations buffer <b>96</b> can also receive profiling information from a plurality of kernel instrumentations points <b>94</b>. Kernel instrumentation points <b>94</b> are various “points” or address locations in the kernel where raw data is captured by the system <b>20</b> for ultimate use in generating runtime metrics. Kernel instrumentation points <b>94</b> include virtually any machine code instruction in the kernel. Events can occur at a particular kernel instrumentation point <b>94</b>. Examples of such events include but are not limited to scheduler events, scheduler lock, scheduler unlock, rescheduling, thread operations, interrupts, time slicing, mutux operations, binary semaphore operations, counting semaphore operations, clock ticks and interrupts, and other types and categories of events.

P-0094[0094] The kernel instrumentations buffer <b>96</b> incorporates the information relating to the virtual machine <b>62</b> obtained through the kernel instrumentation user trace <b>92</b> and the kernel instrumentation points <b>94</b>. The buffer <b>96</b> combines all of the information into the format of kernel instrumentation data <b>98</b> which can then exported to the profiler <b>45</b> for parsing, formatting, correlation, and analysis so that runtime metrics can be organized and displayed in efficient and usable ways. Kernel instrumentation data <b>98</b> can be sent to the profiler <b>45</b> in the form of a kernel instrumentation data record.

P-0095[0095]FIG. 11 is a diagram illustrating how some raw information is processed by aspects of the kernel profiling subsystem in some of the Java embodiments of the kernel profiling subsystem. Java symbols are obtained at <b>100</b> from the Java virtual machine <b>62</b> via the kernel instrumentations user trace <b>92</b>. This process is described in greater detail above. The Java symbols represent raw unformatted information that can be used to generate runtime metrics by the system <b>20</b>. The Java symbols at <b>100</b> are sent to the pseudo symbol string table at <b>102</b> and the pseudo ELF symbol table at <b>104</b>. The pseudo symbol string table at <b>102</b> is used to connect raw Java symbols from step <b>100</b> into more user accessible string messages located on the pseudo symbol string table at <b>102</b>. The pseudo ELF symbol table at <b>104</b> contains the information needed to correctly identify the Java code functional units. The raw information generated by the kernel profiling subsystem becomes mere text after it is captured. The pseudo ELF symbol table at <b>104</b> can be used to distinguish between various data types, objects, functions, etc. Thus, an arrow from the pseudo ELF symbol table at <b>104</b> leads to the pseudo symbol string table at <b>102</b>, because the “string messages” stored at <b>102</b> will need to incorporate the intelligence relating to what various symbols mean.

P-0096[0096] At <b>106</b> is a pointer to the symbol table. Of all of the processing in FIG. 10, the step at <b>106</b> occurs closest to the occurrence of a kernel “event” as described above. The pointer to the symbol table at <b>106</b> is used to map actual hits to the symbols at <b>108</b>. Such “hit” information becomes part of the runtime metric, as described above. The pointer at <b>106</b> is also sent to the symbol table at <b>104</b>, to begin the process that ends with a user-accessible formatted text message at <b>102</b>. The pointer at <b>106</b> is not a global pointer in the sense that its function is limited to linking Java symbols with substantive runtime metric information relating to those symbols.

P-0097[0097] Examples of two global pointers that can be used by the system <b>20</b> in a Java embodiment are a Slot **methodmap_table, a pointer to the Java method map hash table (or alternatively array), and a JVMData *methodmap_data, a pointer to the collected unwound data in the Java virtual machine stack. The system <b>20</b> can incorporate a wide variety of different techniques for utilizing pointers and tables to generate runtime metrics. The diagram in FIG. 11 refers to some of the tables as “pseudo” tables because these tables are created by the profiler <b>45</b> from the data passed to it from the virtual machine <b>62</b> and masquerade as real ELF symbols and ELF string tables that the profiler <b>45</b> could load from an ELF disk file.

P-0098[0098]FIG. 12 is an example of a code listing in a Java embodiment of the system <b>20</b>. A messaging protocol is disclosed in the Figure, although a wide variety of different messaging protocols can be incorporated into the system <b>20</b>. The disclosed messaging protocol is used to communicate compilation and de-compilation information the system <b>20</b> to facilitate the generation of compilation metrics. As disclosed in FIG. 12, a binary blob can be used to store certain fields (e.g. <bit-field><bit-field><addr<b>1</b>><addr<b>2</b>>) in a preferred embodiment of the system <b>20</b>.

P-0099[0099] VII. NON-Java and other Alternatrve Embodiments

P-0100[0100] Many of the code examples and illustrations used above relate in some way to the Java programming language. However, use of the system <b>20</b> is not limited to Java, platform-independent programming languages, or even object-oriented programming languages. The use and functionality of an method map can be supported by a wide variety of different categories of programming languages. Other programming languages can support data structures or objects resembling the method map table 72 described above. Similarly, the functionality of the kernel profiling subsystem can also be supported by a wide variety of different programming languages and platforms. Differences between the programming language of the software application <b>52</b> and the underlying native code library <b>64</b> may make use the system <b>20</b> especially advantageous in profiling runtime environments utilizing virtual machines <b>62</b>, but even virtual machine <b>62</b> embodiments are not limited to the Java programming language. Virtual machines <b>62</b> can be used to facilitate platform-independence in non-Java languages. For example, a virtual machine could be created to support programming languages including but not limited to C++, Curl, COBOL, C, BASIC, JavaScript, Visual Basic, FORTRAN, and others. Moreover, a Java virtual machine <b>62</b> could be modified to facilitate use by non-Java languages. The system <b>20</b> described above is not limited to any particular technology, programming language, or other environmental limitation and should be viewed as expansively as possible. For example, future programming languages and architectures may be developed in the future that will be superior to Java and other currently existing languages. The system <b>20</b> can be utilized in such future environments, as well as other currently existing embodiments.

P-0101[0101] It should be understood that various alternatives to the embodiments of the invention described herein may be employed in practicing the invention. It is intended that the following claims define the scope of the invention and that the method and apparatus within the scope of these claims and their equivalents be covered thereby. It is anticipated and intended that future developments will occur in programming languages and information technology systems, and that the invention will be incorporated into such future embodiments.