Browse Prior Art Database

Big Tree (real-time or dynamic) construction for complex applications which repeatedly spawn threads Disclosure Number: IPCOM000010550D
Original Publication Date: 2002-Dec-16
Included in the Prior Art Database: 2002-Dec-16
Document File: 2 page(s) / 43K

Publishing Venue



Dynamic construction of event based compact trees for complex applications that repeatedly spawn threads

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

Page 1 of 2

  Big Tree (real-time or dynamic) construction for complex applications which repeatedly spawn threads

Performance tuning of applications, especially Java*, which runs in very complicated environments provide a challenge to analysts and the tools used by analysts. The tools must provide the information needed to identify commonly executed paths. The basic methodology used by arcflow and Real-time arcflow place the information in trees, one tree for each thread. Method entry and exit events are supported by the Java Virtual Machine Profiling Interface. When applications repeatedly spawn threads to perform units of work, the number of trees continue to grow so that the information becomes so large that it becomes difficult to maintain all of the required information without seriously affecting the system under test, for example, the application paging space may be limited or we may cause thrashing by affecting the working set. This can occur when new Java threads are created for each new transaction. The transaction itself is basically repeated, but it is repeated on a different thread, and do not have separate trees for different transactions; that is, avoid having separate trees for each thread. We call this approach "Big Tree." When each transaction starts from the beginning of the transaction, we get a tree that reflects the entire transaction and should not get any exits without a previously corresponding entry. We assume this is the case. In order to maintain a consistent tree, some sort of locking or semaphores must be used; however, on NT** using locks when trying to build structures that are accessible by multiple threads can cause severe performance degradations. The degradations can be enough to cause application time outs or significantly perturb the system enough to skew the results. This can also occur on other operating systems. Thus it is desirable to produce a mechanism that avoids locking and avoids the problems of starvation. When searching for a node without a lock, if the node is found, then we can use the node. If the node is not found, then the old methodology would require a lock and another search to ensure that the same node was not created by another thread. We disclose a solution that both minimizes the secondary search effort and avoids the locking.

The solution, which applies to any forward chained link list with multiple thread access is as follows:
Keep a dummy node for each thread for usage when needed.

Outline of Algorithm: oldsav = save = head Search for node if (found) return successfully /* if here, then did not find node on initial search */ while ( not done) fill node with r...