Browse Prior Art Database

USE OF KERNEL INSTRUMENTATION TO ENHANCE JAVA METHOD INVOCATION ANALYSIS

IP.com Disclosure Number: IPCOM000014653D
Original Publication Date: 2000-Mar-01
Included in the Prior Art Database: 2003-Jun-20
Document File: 2 page(s) / 44K

Publishing Venue

IBM

Abstract

USE OF KERNEL INSTRUMENTATION TO ENHANCE JAVA METHOD INVOCATION ANALYSIS A significant amount of application level instrumentation takes the form of trace hooks, or events, firing at the entry to and exit from a procedure/function/subroutine/method. These events are tagged with information about the function, the time at which the entry/exit occurred, and the thread on which the event is taking place. The resulting event stream is then post processed to develop a report of time spent within each function, and the flows from function to function for each thread. Unfortunately, this kind of instrumentation provides an inaccurate measure of where time is actually spent, and in the presence of significant interrupt or synchronization activity the resulting timings will be quite misleading.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 2

USE OF KERNEL INSTRUMENTATION TO ENHANCE JAVA METHOD

INVOCATION ANALYSIS

A significant amount of application level instrumentation takes the form of trace hooks, or events, firing at the entry to and exit from a procedure/function/subroutine/method. These events are tagged with information about the function, the time at which the entry/exit occurred, and the thread on which the event is taking place. The resulting event stream is then post processed to develop a report of time spent within each function, and the flows from function to function for each thread.

Unfortunately, this kind of instrumentation provides an inaccurate measure of where time is actually spent, and in the presence of significant interrupt or synchronization activity the resulting timings will be quite misleading.

The solution is to integrate system level events with application level entry/exit events. These system level events can then be post processed in a manner that allows them to be integrated seamlessly into the original application level event stream. [This is important, because the application level event stream is subsequently post processed/presented/analyzed by an application unaware of the semantics of system level events.]

Details

The original event stream consists of events of the following type:

      (function id, timestamp, thread, ENTRY) (function id, timestamp, thread id, EXIT) This stream is post processed to report time spent in the each of the unique functions identified in the stream.

Consider the following example:

(x, 1, thread 1, ENTRY)

(x, 5, thread 1, EXIT)

(z, 6, thread 1, ENTRY) (y,10,thread 2, ENTRY) (y,20,thread 2, EXIT) (z,30,thread 1, EXIT)

The problem is that from time 6 to time 10, it is unknown to which thread to allocate the elapsed time.

With an instrumented kernel, a system event would have recorded the thread switch, say at times 7 and 29:

7, thread 2, THREADSWITCH 29, thread 1, THREADSWITCH

With this information (possibly collected separately from the application...