Idle transitions sampling with execution context

Abstract

A process generates a sample based on an event. The process identifies, with a dispatch monitor, a next dispatched monitored thread that is dispatched by a current processor. The process sets a processor affinity of the next dispatched monitored thread such that the next dispatched monitored thread runs only on the current processor without being able to migrate to a different processor. The process also retrieves, with a sampled thread that runs on the current processor, a next dispatched monitored thread call stack after the processor affinity of the next dispatched monitored thread has been set to the processor. The process restores the processor affinity of the next dispatched monitored thread after the next dispatched monitored thread call stack has been obtained.

Description

BACKGROUND

1. Field

This disclosure generally relates to a computing environment. More particularly, the disclosure relates to sampling technology.

2. General Background

Either time-based or hardware event-based sampling technology is typically utilized in application profiling tools to determine the specific usage of resources. A current approach is to periodically generate an interrupt to take a sample. When the interrupt is taken, sample data is collected and recorded. Examples of the sample data are the interrupted process/thread, the instruction being executed or, optionally, the data address being accessed at the time of the sample. At a later time the collected data is aggregated, and reports are generated showing sample distribution by address, symbol, process, etc. A variety of tools are based on this technology. The full execution context of the sample is not typically recorded and not available in reports.

Attempts have been made to improve this technology by getting call stacks at the time of the sample. The existing set of tools may either attempt to walk the call stack directly or invoke functions on a separate (sampler) thread to obtain the interrupted thread's call stack. Attempting to walk the call stack at the interrupt level is not ideal, because some applications may have stacks that have been paged out. In addition, stack walking code typically does memory allocations, which are not allowed at the interrupt level. As a result, a user-mode sampling thread may be employed to walk the call stacks when requested. On multiprocessor systems, requesting that a separate thread gather the interrupted thread's call stack may allow the interrupted thread to migrate to a different processor and make forward progress, i.e., continue execution, while the call stack is being gathered. The gathered call stack will not reflect the state of the thread at the time it was interrupted.

SUMMARY

In one aspect of the disclosure, a computer program product is provided. The computer program product includes a computer useable medium having a computer readable program. The computer readable program when executed on a computer causes the computer to generate a sample based on an event. Further, the computer readable program when executed on the computer causes the computer to identify, with a dispatch monitor, a next dispatched monitored thread that is dispatched on a current processor. In addition, the computer readable program when executed on the computer causes the computer to set a processor affinity of the next dispatched monitored thread such that the next dispatched monitored thread runs only on the current processor without being able to migrate to a different processor. The computer readable program when executed on the computer also causes the computer to retrieve, with a sampler thread that runs on the current processor, a next dispatched monitored thread call stack after the processor affinity of the next dispatched monitored thread has been set to the current processor. In addition, the computer readable program when executed on the computer causes the computer to restore the processor affinity of the next dispatched monitored thread after the next dispatched monitored thread call stack has been obtained. The computer readable program when executed on the computer causes the computer to record the call stack for the next dispatched monitored thread.

In another aspect of the disclosure, a process is provided. The process generates a sample based on an event. Further, the process identifies, with a dispatch monitor, a next dispatched monitored thread that is dispatched by a current processor. In addition, the process sets the processor affinity of the next dispatched monitored thread such that the next dispatched monitored thread runs only on the current processor without being able to migrate to a different processor. The process also retrieves, with a sampler thread that runs on the current processor, a next dispatched monitored thread call stack after the processor affinity of the next dispatched monitored thread has been set to the current processor. In addition, the process restores the processor affinity of the next dispatched monitored thread after the next dispatched monitored thread call stack has been obtained. The process also records the call stack for the next dispatched monitored thread.

In yet another aspect of the disclosure, a system is provided. The system includes a current processor that generates a sample based on an event. Further, the system includes an operating system that (i) identifies, with a dispatch monitor, a next dispatched monitored thread that is dispatched by the current processor and (ii) sets the processor affinity of the next dispatched monitored thread such that the next dispatched monitored thread runs only on the current processor without being able to migrate to a different processor. In addition, the system includes a profiler that (i) retrieves, with a sampler thread that is configured to run only on the current processor, a next dispatched monitored thread call stack after the processor affinity of the next dispatched monitored thread has been set to the current processor, (ii) restores the processor affinity of the next dispatched monitored thread after the next dispatched monitored thread call stack has been obtained, and (iii) records the call stack for the next dispatched monitored thread.

In another aspect of the disclosure, a computer program product is provided. The computer program product includes a computer useable medium having a computer readable program. The computer readable program when executed on a computer causes the computer to generate a sample based on an event. Further, the computer readable program when executed on the computer causes the computer to identify, with a dispatch monitor, a last dispatched monitored thread that is dispatched by a current processor. In addition, the computer readable program when executed on the computer causes the computer to set the processor affinity of the last dispatched monitored thread such that the last dispatched monitored thread runs only on the current processor without being able to migrate to a different processor. The computer readable program when executed on the computer also causes the computer to retrieve, with a sampler thread that runs on the current processor, a last dispatched monitored thread call stack after the processor affinity of the last dispatched monitored thread has been set to the current processor. In addition, the computer readable program when executed on the computer causes the computer to restore the processor affinity of the last dispatched monitored thread after the last dispatched monitored thread call stack has been obtained. The computer readable program when executed on the computer also causes the computer to record the call stack for the last dispatched monitored thread.

DRAWINGS

The above-mentioned features of the present disclosure will become more apparent with reference to the following description taken in conjunction with the accompanying drawings wherein like reference numerals denote like elements and in which:

FIG. 1 illustrates a sampling system that samples idle transitions according to an embodiment of the present invention.

FIG. 2A illustrates a process that may be utilized by the interrupt handler for a to_idle_thread according to an embodiment of the present invention.

FIG. 2B illustrates a process that may be utilized by the interrupt handler for a from_idle_thread according to an embodiment of the present invention.

FIG. 3A illustrates a process that may be utilized by the dispatch monitoring code in the scheduler for a to_idle_thread according to an embodiment of the present invention according to an embodiment of the present invention.

FIG. 3B illustrates a process that may be utilized by the dispatch monitoring code in the scheduler for a from_idle_thread according to an embodiment of the present invention.

FIG. 4 illustrates a process for notifying the profiler according to an embodiment of the present invention.

FIG. 5 illustrates a process for the interrupt back-end queued in the process block according to an embodiment of the present invention.

FIG. 6 illustrates a process that is performed by the profiler after being woken up as a result of process block according to an embodiment of the present invention.

FIG. 7 illustrates a process for the profiler to inform the operating system that the sample has completed according to an embodiment of the present invention.

FIG. 8A illustrates a process that may be utilized for idle transitions sampling for a from_idle_thread according to an embodiment of the present invention.

FIG. 8B illustrates a process that may be utilized for idle transitions sampling for a to_idle_thread according to an embodiment of the present invention.

FIG. 9 illustrates a block diagram of a system that samples idle transitions according to an embodiment of the present invention.

DETAILED DESCRIPTION

A method and system utilizes sampling technology to determine why one or more processors are not being fully utilized. Determining why an application running on the processor or processors does not scale can be very difficult. In some environments, especially those supporting transaction processing, it is important to determine the maximum transaction rate and to drive the system to fully utilize all processing resources. When the maximum transaction rate is reached, but not all processors are being fully utilized, there is some type of bottleneck preventing the full utilization. By determining the context for the last thread that was executing before a processor has gone idle, i.e., the to_idle_thread, and/or the context for the first thread executed after the processor has work to do, i.e., the from_idle_thread, information may be obtained to help to determine the cause of the bottleneck.

One approach is to gather call stacks for those threads that may have contributed to a bottleneck. That is, for example, the sampling code may simply get call stacks for only those threads that most recently ran on the processor that is idle at the time of the sample. This involves keeping track of which thread has run on which processor, in order to gather the call stacks for the right threads. However, those threads may migrate and execute on other processors while call stacks are being gathered.

Keeping all processors busy, other than the one on which the call stack will be gathered, may prevent thread migration. This could be accomplished by having sampler threads spin on those processors until the call stack is obtained for the thread of interest, but this may impair overall application performance.

Instead, by preventing the thread of interest from migrating to a different processor, which may be done in an embodiment, by setting its processor affinity to restrict it to only running on one processor, the other processors do not have to be spun so that the other processors are free to continue running the application. Thus, by preventing thread migration, there is minimal application performance degradation. Instead of severely affecting the performance of the application being profiled by waking up all sampler threads, i.e., one per processor, and having the sampler threads spin until the call stacks are retrieved, a method, system, and computer program product may set processor affinity to prevent thread migration with minimal performance impact to the application being profiled and also allow for sampling idle transitions. In one embodiment, for call stacks that have already been seen, only an occurrence count is incremented.

Either or both to_idle processing and/or from_idle processing may be utilized to set the processor affinity to prevent thread migration. A sampling approach is utilized.

FIG. 1 illustrates a sampling system 100 that samples idle transitions according to an embodiment of the present invention. The sampling system 100 includes an application 102 that interacts with a profiler 104 that profiles the application 102. The profiler 104 interacts with an operating system 106. The profiler 104 helps make the determination as to why a processor is being underutilized, i.e., what is causing a processor to be idle instead of performing useful work. The processing is based on sampling when the processors are idle. Since call stacks are gathered at the time of the sample, the code that is potentially contributing to the idle state is exactly determined. The location of the code and the calling sequence that led to the code being there is determined.

Concurrent with sampling, the scheduler 108 monitors thread dispatches via dispatch monitoring code. This code is either part of the operating system or is added via a device driver or kernel extension. Information regarding the to_thread and/or from_thread may also be stored. Asynchronously from each other, a few things occur. The dispatch monitoring code is monitoring thread dispatches. Further, samples are being generated by the processors at a constant rate, i.e., time-based or at every n occurrences of an event, i.e., event-based. Also, sampler threads are listening for commands to cause them to retrieve the call stack of a thread of interest, which is performed by the profiler 104. A sampler thread is a profiler thread. Many sampler threads may be utilized as a plurality of processors may be utilized. Each sampler thread has an affinity to a single processor. Sampler threads may be very high priority threads so that they run immediately when signaled to do work such as retrieving a target thread's call stack. The target thread is the thread whose call stack is to be obtained. Further, a target processor is the processor on which the target thread was running and on which affinity is set so that the target thread remains on that processor until its call stack is obtained.

Once a determination is made as a result of sampling either to_idle or from_idle, a target thread's call stack is to be obtained. The target thread is prevented from making any forward progress during that time, unless forward progress is required in order to allow the call stack to be retrieved. In other words, the target thread is kept where it is until the call stack is gathered. Afterward, the target thread may resume. Since call stacks are gathered by profiler sampler threads, the target thread could potentially begin running on another available processor. By the time the sampler thread begins gathering the call stack, the target thread may no longer be at the point where it was sampled, and the call stack would not accurately reflect where the target thread was at the time of the sample.

Instead of significantly hindering application performance by “boxing out” the target thread from processors other than the target processor (i.e., giving all the other processors busy work that is not useful to make them spin so that they are not available for the target thread to run on), the set of processors on which the target thread may run are restricted to the target processor. In other words, the remaining processors do not spin and may continue to do real work. Only the target processor is affected while the target thread's call stack is being retrieved. Once the target's call stack is retrieved, the target thread is allowed to run on any available processor again. The processor affinity is set so that the target thread can run only on the one processor to which it has affinity to.

The sampling system 100 may have a plurality of processors. For example, the sampling system 100 may have a first processor 112, a second processor 114, . . . , and an nth processor 116. Only one thread can run on each processor at a given time. However, that thread can potentially run on a different processor and at a different time. In the sampling system 100, one or more processors generate interrupts, either time-based or event-based. An interrupt may initiate a sample. Accordingly, each of the processors may generate an interrupt irrespective of the status of each of the other processors, e.g., being idle or not being idle. The interrupt for each processor is generated by hardware and handled by an interrupt handler 110, which determines if the processor on which the interrupt occurred is idle, i.e., if no thread is running on the particular processor, or is not idle. The interrupt handler 110 initiates the gathering of call stacks. Further, the interrupt handler may notify or signal a profiler sampler thread. In one embodiment, if the interrupt handler 110 determines that a particular processor is idle, the interrupt handler 110 may send a flag such as a deferred processing flag to a scheduler 108, which then may or may not schedule a sampler thread to be run on that particular processor to sample the target thread. To avoid thread migration during sampling, the processor affinity of a thread to a particular processor may be established. For a from_idle thread, the scheduler 108 sets the processor affinity. For a to_idle thread, the interrupt handler 110 or the profiler 104 may set the processor affinity.

During from_idle processing, a notification may be sent from the scheduler 108 to the profiler 104. The first interesting monitored thread that wakes up and runs after a processor is idle is likely to be the thread causing the bottleneck. As the system runs, the dispatch monitoring code is waiting to be told to save the next interesting thread to run, e.g., watching the setting of the deferred processing flag. The sampling code tells the dispatch monitoring code to do this by sending/setting a deferred processing flag after a sample on which the processor is idle. The dispatch monitoring code will save the first interesting/monitored thread that runs after the processor was detected to be idle in a previous sample. At the same time, as samples occur, a determination is made as to whether the processor is idle or not. If the processor is busy, nothing is done. If the processor is idle, the deferred processing flag is set for the dispatch monitoring code to begin monitoring thread dispatches and to save the next interesting/monitored thread to be scheduled on the processor. The dispatch monitoring code then clears the deferred processing flag. The sample is then completed.

The same processing may happen on more than one processor at a time. For example if two processors are idle and happen to be dispatching interesting threads at approximately the same time, then two sampler threads may retrieve call stacks at the same time.

Further, a to_idle notification may be sent from the interrupt handler 110 to the profiler 104. The last interesting/monitored thread to run on a processor before it goes to idle is likely to be affected by some resources contention. For example, the thread may not continue because it is waiting on some contended resource. No other threads are available to run after a to_idle thread. As the system runs, the dispatch monitoring code remembers the last interesting thread to run on each processor. Since the thread that is now being remembered may have been previously remembered on a different processor, it is removed from the other processors' remembered list. At the same time, periodic samples are occurring that are either time based or event based. At each sample, a determination is made as to whether the processor is idle or not. If the processor is busy, nothing is done. If the processor is idle, then a determination is made as to whether an interesting monitored thread last ran on the processor. If an interesting thread last ran on the processor, then the thread's processor affinity is set to the current processor.

In one embodiment, only the from_idle_thread is utilized. In an alternative embodiment, only the to_idle_thread is utilized. In yet another alternative embodiment, both the from_idle_thread and the to_idle_thread are utilized.

In another embodiment, a component such as a dispatch monitor may be utilized in conjunction with the scheduler 108. The dispatch monitor may be part of the operating system 106 or may be added as part of a kernel extension or device driver. In another embodiment, a component such as an interrupt back-end worker, offlevel processing worker, interrupt backend worker, or the like may be added as part of a kernel extension or device driver. The component is needed because the set of actions that can be performed at interrupt level is limited and some of the work must be deferred until a subsequent time, after the interrupt handler has completed.

The profiler 104 may retrieve the call stack, i.e., the execution context. Further, the profiler 104 may restore the processor affinity.

FIG. 2A illustrates a process 200 that may be utilized by the interrupt handler 110 for a to_idle_thread according to an embodiment of the present invention. At a process block 202, the process 200 determines an interrupted process id (“PID”) and/or thread id (“TID”). Further, at a decision block 204, the process 200 determines if the microprocessor is idle. If the microprocessor is not idle, the process 200 advances to a process bock 210 to resume the interrupted thread. Alternatively, if the microprocessor is idle, the process 200 advances to a decision block 206 to determine if a saved to_idle PID, saved by the dispatch monitoring code, is of interest. If the saved to_idle PID is not of interest, the process 200 advances to the process block 210 to resume in the interrupted thread. Alternatively, if the saved to_idle PID is of interest, the process 200 advances to a process block 208 to notify the profiler. The process 200 then advances to a process block 210 to resume the interrupted thread.

FIG. 2B illustrates a process 250 that may be utilized by the interrupt handler 110 for a from_idle_thread according to an embodiment of the present invention. At a process block 252, the process 250 determines an interrupted PID/TID. Further, at a decision block 254, the process 250 determines if the microprocessor is idle. If the microprocessor is not idle, the process 250 advances to a process block 258 to resume the interrupted thread. Alternatively, if the microprocessor is idle, the process 250 advances to a decision block 255 to determine if the deferred processing flag has already been set. If the deferred processing flag has already been set, the process 250 advances to the process block 258 to resume the interrupted thread. If the deferred processing flag has not already been set, the process 250 advances to a process block 256 to set a deferred processing flag for the scheduler 108. The process 250 then advances to a process block 258 to resume the interrupted thread.

FIG. 3A illustrates a process 300 that may be utilized by the scheduler 108 for a to_idle_thread according to an embodiment of the present invention. At a decision block 302, the process 300 determines if there is an outgoing thread of interest. If there is not an outgoing thread of interest, the process 300 advances to a process block 306 to continue the thread switch. If there is an outgoing thread of interest, the process 300 continues to a process block 304 to save the outgoing PID and/or TID. The process 300 then advances to a process block 305 to remove the outgoing PID/TID from the other processor's saved PID/TID list. The process 300 then proceeds to the process block 306 to continue the thread switch.

FIG. 3B illustrates a process 350 that may be utilized by the scheduler 108 for a from_idle_thread according to an embodiment of the present invention. At a decision block 352, the process 350 determines if the deferred processing flag has been set. If the deferred processing flag has not been set, the process 350 advances to a process block 360 to continue the thread switch. Alternatively, if the deferred processing flag as been set, the process 350 advances to a decision block 354 to determine if there is an incoming thread of interest. If there is not an incoming thread of interest, the process 350 advances to a process block 360 to continue the thread switch. Alternatively, if there is an incoming thread of interest, the process 350 advances to a process block 356 to reset the deferred processing flag. The process 350 then advances to a process block 358 to notify the profiler 104. Further, the process 350 then advances to the process block 350 to continue the thread switch.

FIG. 4 illustrates a process 400 for notifying the profiler 104 according to an embodiment of the present invention. At a decision block 402, the process 400 determines if there is a profiler to notify. If there is not a profiler to notify, the process 400 advances to a completion block 408. Alternatively, if there is a profiler to notify, the process 400 advances to a process block 404 to latch and/or save notification data. The process 400 advances to a process block 406 to queue the interrupt back-end. As a result, a work item is queued by the operating system 106. One of the pieces of information in that work item is the address of worker function to be run when the interrupt back-end is dequeued by the operating system 106. The process 400 then advances to a completion block 408.

FIG. 5 illustrates a process 500 for the performance of the interrupt back-end in the process block 406 according to an embodiment of the present invention. At a process block 502, the process 500 indicates an outstanding sample. Further, the process 500 then advances to a process block 504 to set the processor affinity of the target thread to the current processor. In addition, the process 500 then advances to a process block 506 to wake up the profiler.

FIG. 6 illustrates a process 600 performed by the profiler after being sent a signal by either the interrupt handler or by the scheduler as a result of process block 506 according to an embodiment of the present invention. At a process block 602, the process 600 has the profiler waiting for an event or signal. The event or signal comes from the interrupt handler 110 if the thread is a to_idle_thread. The event or signal comes from the scheduler 108 if the thread is a from_idle_thread. Further, at a process block 604, the process 600 receives the signal from the operating system 106. In addition, at a process block 606, the process 600 reads the sample data containing information about the target thread. At a process block 608, the process 600 requests the call stack for the target thread. Further, at a process block 610, the process 600 restores the target thread's processor affinity. At a process block 612, the process 600 processes the returned call stack. In one embodiment, the processing of the returned call stack may involve walking the returned call stack into a tree. Further, a to_idle count and/or a from_idle count may be incremented. The to_idle count or from_idle count indicates how many times the call stack, i.e., the calling sequence, has been seen ending at the leaf node. At a process block 614, the process 600 informs the operating system 106 that the sample has completed. The process 600 then returns back to the process block 602 to wait for an event or signal.

FIG. 7 illustrates a process 700 to inform the operating system 106 that the sample has completed according to an embodiment of the present invention. At a process block 702, a sample has been completed. Further, at a process block 704, the process 700 indicates that there is no outstanding sample. No additional samples are initiated on a processor that has an outstanding sample. In addition, at a process block 706, the process 700 reinitializes interrupts.

In one embodiment, idle transition reporting for the last monitored thread before the processor has gone idle may be supported by maintaining a last dispatched entry in a per processor table. When a time based sample occurs and the sample interrupts a processor that is idle, the sampler thread is woken and gets the call stack of the last monitored thread. Its call stack is walked into a tree and the base to_idle count of the leaf node of the call stack just inserted is incremented. In order to get a call stack of the from_idle monitored thread that reflects its state at the time it went idle, either the call stack must be retrieved at the time the processor is idle or at the time it is determined that the thread is to be dispatched, before it gets a chance to execute. In either case, the call stack for the first monitored thread dispatched after a to_idle sample is taken is walked into a tree and the base from_idle metric count of the leaf node of the call stack just inserted is incremented. Reports can be generated and viewed.

When a sample is taken and it is determined that the processor is idle, the sampling code indicates to the dispatcher monitoring code that the next dispatched monitored thread on that processor needs to be sampled. That thread is identified in the per processor control block and is not updated until the next sample is taken.

When the dispatcher monitoring code detects that a from idle thread call stack should be recorded and the thread to be dispatched is a monitored thread, then it may cause the sampler thread to be dispatched instead. In one embodiment, this may be done by queuing an interrupt back-end or Second Level Interrupt Handler with an indication to force the sampling thread to process the call stack for the monitored thread. In another embodiment, the dispatching monitoring code may directly force the sampling thread to be dispatched next with the information needed to get the call stack for the monitored thread. This information could be passed by simply updating the from idle monitored thread identification in a mapped sample data area.

If the call stack for the from_idle thread cannot be retrieved before it is dispatched, then call stacks for threads not currently being executed may be retrieved at the time the processor is idle. The stacks may be restricted to a subset, such as, only those that were last dispatched on the processor that is idle. There may be other criteria, such as, excluding threads that have not previously returned stacks or threads that are identified as daemon threads. If the from_idle thread's stack was captured at the time the processor was idle, then that previously captured call stack may be used at a later time, such as, at the next sample. The subset of threads may be restricted to only those that were last dispatched on the processor that is idle. Different sampler threads could be retrieving stacks concurrently. Some amount of logic would identify the list of threads whose call stacks are being retrieved and to ensure that they are not duplicated as a result of timing issues on a different processor.

FIG. 8A illustrates a process 800 that may be utilized for idle transitions sampling for a from_idle_thread according to an embodiment of the present invention. At a process block 802, the process 800 generates a sample based on an event. Further, at a process block 804, the process 800 identifies, with a dispatch monitor, a next dispatched monitored thread that is dispatched by a processor if the processor is determined to be idle based on the interrupt. In addition, at a process block 806, the process 800 sets a processor affinity of the next dispatched monitored thread such that the next dispatched monitored thread runs only on the processor without being able to migrate to a different processor. At a process block 808, the process 800 retrieves, with a sampled thread that runs on the processor, a next dispatched monitored thread call stack after the processor affinity of the next dispatched monitored thread has been set to the processor. In addition, at a process block 810, the process 800 restores the processor affinity of the next dispatched monitored thread after the next dispatched monitored thread call stack has been obtained. At a process block 812, the process 800 records the call stack for the next dispatched monitored thread. The recording may be in the form or a report.

FIG. 8B illustrates a process 850 that may be utilized for idle transitions sampling for a to_idle_thread according to an embodiment of the present invention. At a process block 852, the process 850 generates a sample based on an event. Further, at a process block 854, the process 850 identifies, with a dispatch monitor, a last dispatched monitored thread that is dispatched by a processor if the processor is determined to be idle based on the interrupt. In addition, at a process block 806, the process 850 sets a processor affinity of the last dispatched monitored thread such that the last dispatched monitored thread runs only on the processor without being able to migrate to a different processor. Further, at a process block 858, the process 850 obtains, through the last dispatched monitored thread call stack, an execution context for the last dispatched monitored thread. In addition, at a process block 860, the process 850 restores the processor affinity of the last dispatched monitored thread after the last dispatched monitored thread call stack has been obtained. At a process block 864, the process 850 records the call stack for the last dispatched monitored thread. The recording may be in the form of a report.

The processes described herein may be implemented in one or more general, multi-purpose or single-purpose microprocessors. Such microprocessors will execute instructions, either at the assembly, compiled or machine-level, to perform the processes. Those instructions can be written by one of ordinary skill in the art following the description of the figures corresponding to the processes and stored or transmitted on a computer readable medium. The instructions may also be created using source code or any other known computer-aided design tool.

FIG. 9 illustrates a block diagram of a system 900 that samples idle transitions according to an embodiment of the present invention. In one embodiment, the system 900 is suitable for storing and/or executing program code and is implemented using a general purpose computer or any other hardware equivalents. Thus, the system 900 comprises a processor 902 (which may be referred to as a “microprocessor”), a memory 912, e.g., random access memory (“RAM”) and/or read only memory (“ROM”), the profiler 104, and various input/output devices 904.

The processor 902 is coupled, either directly or indirectly, to the memory 912 through a system bus. The memory 912 can include local memory employed during actual execution of the program code, bulk storage, and/or cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

The input/output devices 904 can be coupled directly to the system 900 or through intervening input/output controllers. Further, the input/output devices 904 can include a keyboard, a keypad, a mouse, a microphone for capturing speech commands, a pointing device, and other user input devices that will be recognized by one of ordinary skill in the art. Further, the input/output devices 904 can include a receiver, transmitter, speaker, display, image capture sensor, biometric sensor, etc. In addition, the input/output devices 404 can include storage devices such as a tape drive, floppy drive, hard disk drive, compact disk (“CD”) drive, digital video disk (“DVD”) drive, etc.

Network adapters may also be coupled to the system 900 to enable the system 900 to become coupled to other systems, remote printers, or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the currently available types of network adapters.

It should be understood that the method and system described herein can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements. If software is utilized to implement the method or system, the software can include but is not limited to firmware, resident software, microcode, etc. Although only one microprocessor is explicitly shown in the illustrated embodiment of FIG. 9, the system may have more than one microprocessor.

Any of the configurations described herein may be utilized with a virtual machine. A virtual machine may be configured to keep track of calling state and return that state referring to a virtual machine supported interface to return call stacks. For instance, information about execution of threads may be obtained through trace data. This information may include call stack information obtained from call stacks associated with threads of interest. A virtual machine may be utilized to obtain the call stack information. Various approaches may be utilized by the virtual machine to obtain the call stack information. For example, entry/exit events, an application timer tick, or instrumenting codes that sample the instrumented values may be utilized. A selected sampling thread may send a call to the virtual machine to obtain the call stack information. The selected sampling thread may make the call to the virtual machine through a virtual machine tool interface. The virtual machine tool interface may return call stack information to the sampling thread or may store the call stack information in some work area. The obtained information may be placed into a tree for later analysis.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method, or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (“LAN”) or a wide area network (“WAN”), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be supplied to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the processor and instructions provide a machine that implements functions and actions specified in the one or more flowcharts or block diagrams herein. The “processor” of a general purpose computer, special purpose computer, or other programmable data processing apparatus may be referred to herein as a “microprocessor.” However, the term “microprocessor” should not be interpreted as being limited to a single-chip central processing unit or any other particular type of programmable data processing apparatus, unless explicitly so stated.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks. The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Reference throughout this Specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrase “in one embodiment,” “in an embodiment,” and similar language throughout this Specification may, but do not necessarily, all refer to the same embodiment. Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. Correspondingly, even if features are initially claimed as acting in certain combinations, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination can be directed to a subcombination or variation of a subcombination.

While the apparatus and method have been described in terms of what are presently considered to be the most practical and preferred embodiments, it is to be understood that the disclosure need not be limited to the disclosed embodiments. The disclosure is intended to cover various modifications and similar arrangements included within the spirit and scope of the claims, the scope of which should be accorded the broadest interpretation so as to encompass all such modifications and similar structures. The present disclosure includes any and all embodiments of the following claims.

Claims

1. A computer program product comprising a computer readable storage medium having a computer readable program, wherein the computer readable program when executed on a computer causes the computer to: set a processor affinity of a next dispatched monitored thread to a first value, wherein the next dispatched monitored thread executes on a current processor without being able to migrate to a different processor while a next dispatched monitored thread call stack is being retrieved;retrieve the next dispatched monitored thread call stack; andrestore the processor affinity of the next dispatched monitored thread to a second value after the next dispatched monitored thread call stack has been retrieved, wherein the next dispatched monitored thread migrates to a different processor to continue execution; andrecord the next dispatched monitored thread call stack for a subsequently dispatched monitored thread.

2. The computer program product of claim 1, wherein the next dispatched monitored thread is dispatched by the current processor based on an event, and wherein the event is based on a predetermined event.

3. The computer program product of claim 2, wherein the predetermined event is time based.

4. The computer program product of claim 1, wherein the next dispatched monitored thread is dispatched by the current processor based on an event, and wherein the event is based on an interrupt.

5. The computer program product of claim 1, wherein the computer is further caused to: notify a profiler that selects a sampled thread that retrieves the next dispatched monitored thread call stack.

6. The computer program product of claim 5, wherein the profiler profiles an application.

7. The computer program product of claim 1, wherein the computer is further caused to: after recording of the next dispatched monitored thread call stack for the next dispatched monitored thread, notify an operating system that a sample has been completed.

8. A method comprising: setting a processor affinity of a next dispatched monitored thread to a first value, wherein the next dispatched monitored thread executes on a current processor without being able to migrate to a different processor while a next dispatched monitored thread call stack is being retrieved;retrieving the next dispatched monitored thread call stack; andrestoring the processor affinity of the next dispatched monitored thread to a second value after the next dispatched monitored thread call stack has been retrieved, wherein the next dispatched monitored thread migrates to a different processor to continue execution; andrecord the next dispatched monitored thread call stack for a subsequently dispatched monitored thread.

9. The method of claim 8, wherein the next dispatched monitored thread is dispatched by the current processor based on an event, and wherein the event is based on a predetermined event.

10. The method of claim 9, wherein the predetermined event is time based.

11. The method of claim 8, wherein the next dispatched monitored thread is dispatched by the current processor based on an event, and wherein the event is based on an interrupt.

12. The method of claim 8, further comprising: notifying a profiler that selects a sampled thread that retrieves the next dispatched monitored thread call stack.

13. The method of claim 12, wherein the profiler profiles an application.

14. The method of claim 8, further comprising: notifying, after recording of the next dispatched monitored thread call stack for the next dispatched monitored thread, an operating system that a sample has been completed.

15. A system comprising: processors; andstorage coupled to the processors, wherein the storage has stored thereon program code, and wherein at least one of the processors is configured to execute the program code to perform operations, wherein the operations comprise:setting a processor affinity of a next dispatched monitored thread to a first value, wherein the next dispatched monitored thread executes on a current processor without being able to migrate to a different processor while a next dispatched monitored thread call stack is being retrieved;retrieving the next dispatched monitored thread call stack; andrestoring the processor affinity of the next dispatched monitored thread to a second value after the next dispatched monitored thread call stack has been retrieved, wherein the next dispatched monitored thread migrates to a different processor to continue execution; andrecord the next dispatched monitored thread call stack for a subsequently dispatched monitored thread.

16. The system of claim 15, wherein the next dispatched monitored thread is dispatched by the current processor based on an event, and wherein the event is based on a predetermined event.

17. The system of claim 16, wherein the predetermined event is time based.

18. The system of claim 15, wherein the next dispatched monitored thread is dispatched by the current processor based on an event, and wherein the event is based on an interrupt.

19. The system of claim 15, wherein the operations further comprise: notifying a profiler that selects a sampled thread that retrieves the next dispatched monitored thread call stack.

20. The system of claim 19, wherein the profiler profiles an application.

21. The system of claim 15, wherein the operations further comprise: notifying, after recording of the next dispatched monitored thread call stack for the next dispatched monitored thread, an operating system that a sample has been completed.

22. A computer program product comprising a computer readable storage medium having a computer readable program, wherein the computer readable program when executed on a computer causes the computer to: set a processor affinity of a last dispatched monitored thread to a first value, wherein the last dispatched monitored thread executes on a current processor without being able to migrate to a different processor while a last dispatched monitored thread call stack is being retrieved;retrieve the last dispatched monitored thread call stack; andrestore the processor affinity of the next dispatched monitored thread to a second value after the next dispatched monitored thread call stack has been retrieved, wherein the next dispatched monitored thread migrates to a different processor to continue execution; andrecord the next dispatched monitored thread call stack for a subsequently dispatched monitored thread.

23. The computer program product of claim 22, wherein the last dispatched monitored thread is dispatched by the current processor based on an event, and wherein the event is based on a predetermined event.

24. The computer program product of claim 23, wherein the predetermined event is time based.

25. The computer program product of claim 22, wherein the last dispatched monitored thread is dispatched by the current processor based on an event, and wherein the event is based on an interrupt.