Browse Prior Art Database

Formatting Trace in a multi-thread multi-core environment

IP.com Disclosure Number: IPCOM000199533D
Publication Date: 2010-Sep-08
Document File: 4 page(s) / 86K

Publishing Venue

The IP.com Prior Art Database

Abstract

This disclosure describes a system to format and display multi-threaded trace data in a simple 3-dimensional view.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 42% of the total text.

Page 1 of 4

Formatting Trace in a multi-thread multi-core environment

The disclosed solution helps display formatted trace in a more readable format.

    Technology is advancing at a rapid rate - Just 5 years ago, mainframes were considered high-powered with 32 processors, now 64 processors are not uncommon. By the end of 2010, there will be mainframes with more than 100 processors.

    This significant increase in numbers of processors coupled with the increasing processor speed means that the amount of work that can be run on any machine is rapidly increasing. For example, using 16 processors on a system, it is possible to process 500,000 message puts and gets per second - every second.

    Whilst this capacity is impressive, when problems occur, it becomes more difficult to diagnose when the number of threads involved is increasing at a rate that corresponds to the number of processors.

    Software being developed today is becoming more and more complex and the relationships between threads becomes more and more important as there will be times that access to common resources need to be serialised. When running on a many-processor system, in order to ensure good scalability, it is preferred that common resources are "locked" for as little time as possible.

    Typically when looking into issues that have occurred in this high concurrent thread environment, a trace function is enabled.

    This trace process writes out trace data on entry and exit from separate modules so that the viewer of the trace can see the path through the system. In a multi-threaded environment, each trace entry has the associated thread identifier.

    When the trace runs for any period of time in a system processing hundreds of thousands of messages every second, the trace data will have 10's of millions of trace lines.

    To pick out the relevant data can be daunting in the current environment. Currently there are 2 views of the trace data available:-
1) A sequential list of each trace point which includes all the threads that have been traced. This contains all of the thread entries interleaved with each other based on a time order e.g.

XXXEDSB2-00 EB=206E8F18 CALLNTRY RET=A45E427C 08:06:53.9038540 CFM RMID=C5 EID=2D2 00.0000002138
=0000048=

XXXEDSI2-00 EB=206E8F18 CALLNTRY RET=A44C7844 08:06:53.9038542 CFM RMID=C5 EID=2BD 00.0000002275
=0000049=

XXXMCPRH-01 EB*206E8

                      RAENTRY RET=00000000 08:06:53.9041950 CMC RMID=94 EID=015 00.0003407202
=0000050=

XXXZTFLO-42 EB=206E8

                      RMENTRY RET=A17175F4 08:06:53.9041954 SPMC RMID=0C EID=008 00.0000004970
=0000051=

XXXZTFLO-42 EB=206E8

                      RMEXIT RET=A17175F4 08:06:53.9041956 SPMC RMID=0C EID=009 00.0000001416
=0000052=

XXXMPRH2-45 EB=206E8

A

                      CALLNTRY RET=A4787538 08:06:53.9041970 MMC RMID=D4 EID=296 00.0000004130
=0000054=

In the above example, the second thread has been highlighted to make it more clear - but consider when there are not 2 threads but 100 threads. To quickly identify separate threads and the relationship between those threads is not simple in this vie...