When profiling a concurrent program, we usually would like to see 2 views – one view centered on threads – individual execution sequences and their life cycle events and resource – locks that are contended and used by threads at given time. Clearly it is infeasible to collect two sets of traces.

The dual view is accomplished by redirecting raw trace event to go through the ILifeEvent interface, and this is the interface that the ILifeCycleViewModel uses, which is basically a collection of ILifeEvent and is in the contract of the LifeEventVisualizer user control.

Two sample ILifeEvent is implemented for reference: the ThreadLifeEvent and ResourceLifeEvent provide support for the two main views in the main window. A ThreadLifeEvent is essentially a wrapper for a single JVMTIEvent with a Subject and Object field. The Subject field is the thread id, while the Object field, if any, is the id of the resource that is related to the JVMTIEvent. On the contrary, a ResourceLifeEvent is essentially a wrapper for a single JVMTIEvent with a Subject and Object field. The Subject field is the resource id, while the Object field, which always present, is the id of the thread. This means that each JVMTIEvent corresponds to 2 ILifeEvent objects.

This is the single design that allowed LENS to have a single unified interface for visualizing events and event filtering. The rest of the code is straightforward.

Last edited Dec 11, 2014 at 6:18 AM by LuoLiang, version 3