Thread View updates

TPTP feature:

Author:

Alexander N. Alexeev

email:

alexander.n.alexeev@intel.com

Last updated:

 


Rough workload estimate in person weeks:

Process

Sizing

Names of people doing the work

Design

3

Alexander N. Alexeev

Code

5

Code (Runtime)

2

Code (WB)

3

Test

1

Documentation

1

Build and infrastructure

1

Alexander N. Alexeev

Code review & other committer work
(e.g. check-in, contribution tracking)
if this is to be contributed by someone who
is not a committer in the component

1

N/A - will be done by committer

Total

12

 

 

Requirement summary

Following list of Thread Profiling enhancements should be contained in 4.5

1.      Contention analyses (200320)

2.      Visualize interaction between threads (200342)

3.      Flat list of arbitrary threads in visualizer (200341)

These three enhancements separated, but they are highly coupled and depended from each other, therefore working on them is joined. All time allocated for their implementation are distributed among #1, #2, #3 as 50%, 25%, 25% respectively.

Enhancements requirements details

1.      Contention analyses

Contention for monitors may significantly affect overall performance of application. Some set of functions for identifying problem with high contended monitors and evaluating impact of such contention on performance are required in TPTP

 

Two type of contentions can be considered, monitor contention and data contention. The first one is an actual attempt to acquire the monitor while another thread already has it. And the second one is an actual attempt to access the data while another thread expects to manipulate it without interfering.  

Monitor contention affect performance and scalability.

Data contention (data race conditions) can lead to irreproducible errors.

This enhancement only intended to assist developers in tracking and resolving monitor contentions, also it should help with unreasonable "waits" localization.

 

Important concept of contention analysis is Critical Path (CP). CP is the sequence of dependent activities which length defines total time of execution. See Pic. 1.

 

Pic. 1.

According to enhancement’s intention following information should be displayed in Thread Profiling:

Optional requirements:

2.      Visualize interactions between threads

Following threads interactions should be visualized (Pic 1. and Pic. 2.):

-          Join/Terminate thread (or interrupted)

-          Wait/Notify object

-          Join/Terminate

-          Acquire/release lock

Visualization should be implemented using arrows from active threads to thread which state is changed.  For each type of interaction unique legend should be used.

Pic 2.

3.      Flat list of arbitrary threads in visualizer

Currently (Pic. 3.) thread visualization is divided on groups. This impedes more clear presentation and clutter view with uninteresting threads.

Pic. 3.

Grouping of threads should be optional and depends from user choice. Additional control element required on view to allow user choosing interesting threads to depict. Thread representation without groups Pic. 4.

Pic. 4.

This feature also required for preceding enhancements. Critical path and thread interaction are more understandable and good looking if nothing divides them.

User interactions

1.      Overall statistics for monitors and waits shows potential performance loss on shared resources and allow examining it.

2.      User can identify code section that critical for performance by critical path examination.

User interface

All changes required for enhancements will be contained in Thread Analysis view:

 

New tab: “Monitor statistics" (Pic. 5.) is page with general data for all application. It depicts:

-          All threads and corresponding classes which monitors were used (synchronizing or wait/notify )

-          Detailed information for blocking of selected class object’s monitors.

-          Detailed information for waits of selected class object’s monitors.

All tables’ columns are storable. Thread table supports multiselect. If more than one thread selected then total data for them is calculated in shown at class and monitors views.

Pic. 5.

            “Thread vizualizer” page should be also extended with additional control button on top control pane (Pic 6.) Comments to picture:

1. (Sample Icon) Button with fixed state is intended to turn on/off thread grouping.

 

2. Button open filter configuration dialog.  Dialog (Pic. 7) allows choose for demonstration certain set or all threads. All columns in thread table are storable. Filtering criteria can be extended in future. Icon will be changed to avoid user confusion with filter on statistical pages.

 

A, L. (Icons should be designed) Showings of critical path, wait/notify, acquire/release, join/terminate interactions are turned on/off via buttons on top control pane.

 

 

Pic. 6.

Pic. 7.

Design summary

Statistics about contentions with binding to source code (except site of notification) can be gathered without any changes in Martini and based on existing events set. All required procedures are brought to accurate calculation.

Set of profiling events should be extended. Besides directly generated events (threadStart, threadEnd, monContendedEnter, monContendedEntered, monWait, monWaited) some other should be computed. Those are “Attempt to start thread”, “Send notification for distinct object”, “Release monitor that is waited by other thread and passing it”.

To obtain these events heuristics are used, partly they are based on thread’s and monitor’s states tracing and partly on BCI (binary code instrumentation). Support of all BCI-based events will be introduced as special adapter for Thread profiling.

 

Detailed design.

 

This enhancement is intended to extend functionality of JVM TI agent which used by Thread Profiler for contention analysis. This consists of representing tabulated monitor’s statistics and critical path construction for profiled execution.

Currently all data produced by ThreadProf agent is based on events generated by JVM TI.  But this events set isn’t enough for critical path construction. The only way to provide required events and information is to use BCI (binary code instrumentation), this approach is mentioned in JVM TI spec, and all functionality required for this is provided by JVM via native API.

Whole scheme of profiling is the following. JVM TI agent gathers events from JVM and generates data flow consumed by Eclipse WB. Data flow isn’t necessarily repeat events from JVM TI. Agent can reevaluate them and send only relevant information. But required CPU resources should be taken into account, too complicated algorithms can negatively affect the overall profiling performance. 

Eclipse WB receive events data flow (it could be XML or binary format) from agent and process it into internal TPTP profiler data model based on EMF. In contrast to agent generated events which reflect thread state changes with marking beginning and ending of certain state (wait/waited) eclipse data model save only events reflected new state until it is changed to the another one by next event (running/sleeping/waiting for lock/waiting for object/dead lock/dead). See example of the table.

 

Agent fired event

TPTP’s EMF events on thread model

Event threadStart filred for thread A

Instance of class TRCThreadRunningEvent inserted to the event sequence for thread A

Event monContendedEnter fired for thread A

Instance of class TRCThreadWaitingForLockEvent inserted to the event sequence for thread A

Event monContendedEntered fired for thread A

Instance of class TRCThreadRunningEvent inserted to the event sequence for thread A

Event threadEnd filred for thread A

Instance of class TRCThreadDeadEvent inserted to the event sequence for thread A

As can be seen from example all events on TPTP’s EMF model shows thread state from time when associated XML was generated until next received event. There are no events which show instantaneous action within one thread or interaction between threads.

 

Information depicted in views.

Introduction

            This section contains overview of information provided to user via UI. This intended to clarify purpose of certain agent events and EMF classes. Most items in this list are already displayed and required only for whole picture understanding. New items marked bold. Separated section with new item discussion is provided at the end of the list. View’s mock-ups are above. Pictures will be mentioned where it is required.

Brief summary of views

1.      Graphical view with visualized threads state.

1.1.   Threads flow with state depiction

1.1.1.      Run

1.1.2.      Dead

1.1.3.      Deadlocked

1.1.4.      Waited for object

1.1.5.      Waited for monitor

1.1.6.      Waited for join

1.1.7.      Sleeping

1.2.   Thread flow with threads groups

1.3.   Thread flow without threads groups

1.4.   Thread flow with threads interactions      

1.4.1.      Thread spawning/starting

1.4.2.      Thread termination

1.4.3.      Thread join. Interaction between joinee and joined

1.4.4.      Calling notification (obj.notify()/obj.notifyAll())in thread

1.4.5.      Starting wait and exit from wait (obj.wait()) in  thread

1.4.6.      Attempt to acquire contended monitor,  acquire contended monitor, passing monitor after releasing

1.5.   Selection  of threads to display (filtering)

2.      Tabular views

2.1.   List of all threads

2.1.1.      ID

2.1.2.      Name

2.1.3.      Group

2.2.   List of all threads

2.2.1.      ID

2.2.2.      Name

2.2.3.      Group

2.2.4.      Blocked count

2.2.5.      Blocked time

2.2.6.      Waited count

2.2.7.      Waited time

2.3.   Table of active monitors

2.3.1.      List of blocker classes for selected threads (one or more)

2.3.1.1.            Name of class

2.3.1.2.            Block count

2.3.1.3.            Blocked time

2.3.1.4.            Total blocked time

2.3.1.5.            Min/Max/Avg blocked time?? distribution

2.3.1.6.            Wait count

2.3.1.7.            Total wait time

2.3.1.8.            Min/Max/Avr wait time?? Distribution

2.3.2.      For selected class and selected threads (one or more) list of monitors

2.3.2.1.            Caller method

2.3.2.2.            Total blocked time

2.3.2.3.            Min/Max/Avg blocked time?? distribution

2.3.2.4.            Monitor objects number

2.3.2.5.            Thread number

2.3.2.6.            For selected class and selected threads (one or more)  list of waits

2.3.2.7.            Caller method

2.3.2.8.            Total waiting time

2.3.2.9.            Min/Max/Avg wait time?? distribution

2.3.2.10.        Monitor objects number

2.3.2.11.        Thread number

3.      View with call stack for wait/notify/notifyAll/monitor enter/entered

 

New views and elements description

  1. Adding new type of permanent thread state “Joined” (in list: 1.1.6 Waited for join)

Mainly it is required to divide the threads which are waited on ordinary object’s monitors and the threads which are waited on other threads monitors. This attract users attention to thread preventing other progress and as a case to problem of unbalanced task distribution among threads. Only TRCThreadWaitingForJoinEvent required.

  1. Flat view of all threads (in list: 1.3 Thread flow without threads groups)

This is same view as current Thread Vizualizer but without dividing threads on groups. This simplifies visual analysis by removing unnecessary widgets from view.  (see Pic. 4) Update in model or at agent doesn’t required.

  1. Thread visualization view with thread interaction (in list: 1.4. Thread flow with threads interactions)

All kind of interaction mentioned in the list will be depicted as arrows between threads according to legend and directed from active thread caused execution to resumed thread. All proposed classes from model are used.

  1. Table of active monitors (in list: 3.1. Table of active monitors)

Profiler currently gathers enough information for tracking each monitor’s usage statistics. But browsing thru them can be overwhelming. To simplify it two levels selection is used. First table allow user to select threads he interested in. And on second table he can select subset of classes whose monitors are used for interaction. After that in two last separated tables information about blocking and waiting for each monitors satisfied to selection displayed. (Pic. 5) Next model classes are used for views implementation TRCThreadWaitingForObjectEvent, TRCThreadWaitingForLockEvent, TRCThreadSleepingEvent, TRCThreadWaitingForJoinEvent, TRCThread, TRCClass, TRCObjectReference.

 

 

 

 

Extension for TPTP (Profiler) data model

Introduction

            Current model doesn’t have whole bunch of classes required for storing and analyzing information about joint thread execution and their interaction. There is limited set of way how thread can coordinate their joint execution. Who each of them separated class in scope of EMF can be provided. Also some changes are required in thread state collecting.

 

Support before 4.5

4.5 Support

TRCThreadRunningEvent

V

V

TRCThreadWaitingForObjectEvent

V

V

TRCThreadWaitingForLockEvent

V

V

TRCThreadSleepingEvent

V

V

TRCThreadWaitingForJoinEvent

 

V

TRCThreadDeadLockEvent

V

V

TRCThreadDeadEvent

V

V

TRCThreadExecEvent

 

V

TRCThreadStartsThreadEvent

 

V

TRCThreadHandoffLockEvent

 

V

TRCThreadInterruptThreadEvent

 

V

TRCThreadNotifyAllEvent

 

V

TRCThreadNotifyEvent

 

V

TRCThreadDeadAndNotifyJoined

 

V

TRCThreadWaitTimeoutExceed

 

V

General schema

 

          Entities for thread state reflection

1.     TRCThreadRunningEvent

Description:

                        Intended to express ordinary thread run

Specification (important attributes):

                        Base class: TRCThreadEvent

                        Attributes:

                                    Time

Evaluation algorithm:

Input: agent “XML” events monContendedEntered, monWaited, threadStart, threadInterrupted (optional, and only required for more precise information).

How it works: instance of TRCThreadRunningEvent class inserted in events sequence of source thread with time stamp (Time) obtained from income input agent’s event. 

Representation:

It is represented only in Thread Visualization view. Event is depicted as box on thread’s time line until next event. Color and flooding are selected according to legend. User can open call stack view for the call associated with one of the above mentioned agent’s events.

Current status:

                        Already exist, no changes required.

 

2.     TRCThreadWaitingForObjectEvent

Description:

Intended to express thread waiting state on monitor for notification (for notify method call).

Specification (attributes):

                        Base class: TRCThreadEvent

                        Attributes:

                                    Time.

                                    Timeout

                                    Object waiting for.

Evaluation algorithm:

Input: agent’s event monWait

How it works: All required information (object, time and timeout) loaded from monWait event.

Representation:

It is represented only in Thread Visualization view. Event is depicted as box on thread’s time line until next event. Color and flooding are selected according to legend. User can open call stack view for the call associated with monWait agent event.

Current status:

                        Already exist, no changes required.

 

3.     TRCThreadWaitingForLockEvent

Description:

                        Intended to express blocked thread’s state on attempt to acquire monitor.

Specification (attributes):

                        Base class: TRCThreadEvent

                        Attributes:

                                    Time.

                                    Locked Thread (current monitor holder).

                                    Locked Object.

Evaluation algorithm:

Input: agent’s event monContendedEnter

How it works: All required information (time, locked object and thread) loaded from monContendedEnter event.

Representation:

It is represented only in Thread Visualization view. Event is depicted as box on thread’s time line until next event. Color and flooding are selected according to legend. User can open call stack view for the call associated with monContendedEnter agent event.

Current status:

                        Already exist, no changes required.

 

4.     TRCThreadSleepingEvent

Description:

                        Expresses thread sleeping state.

Specification (attributes):

                        Base class: TRCThreadEvent

                        Attributes:

                                    Time

Sleeping time. Isn’t used.

Evaluation algorithm:

Input: agent’s event monWait

How it works: Filled from monWait similar to TRCThreadWaitingForObjectEvent. If ObjIdRef is "-1" then the thread is in Thread.sleep().

Note: Thread is considered as slept until monWaited event come.

Representation:

It is represented only in Thread Visualization view. Event is depicted as box on thread’s time line until next event. Color and flooding are selected according to legend. User can open call stack view for the call associated with monWait agent event.

Current status:

                        Already exist, no changes required.

 

5.     TRCThreadWaitingForJoinEvent

Description:

This class is intended to express thread waiting state for other thread termination.

Specification (attributes):

                        Base class: TRCThreadWaitingForObjectEvent

                        Attributes:

                                    JoinedThread

Evaluation algorithm:

Input: agent’s events monWait and threadStart

How it works: If waited object is instance of class Thread (accordingly to ObjRefId) then instead of TRCThreadWaitingForObjectEvent class TRCThreadWaitingForJoinEvent  is used for storing threads state. Event is inserted in Thread event sequence. Table of all thread’s object reference ID constructed from information received via threadStart. This table is used for checking what object is instance of class Thread.

Representation:

It is represented only in Thread Visualization view. Event is depicted as box on thread’s time line until end. Color and flooding are selected according to legend. User can open call stack view for the call associated with monWait agent event.

Current status:

                        No, full implementation required.

 

6.     TRCThreadDeadLockEvent

Description:

                        Shows deadlocked state of thread

Specification (attributes):

                        Base class: TRCThreadWaitingForLockEvent

                        Attributes:

                                    Time

                                    Locked object

                                    Locked thread

Evaluation algorithm:

Input: agent’s event monContendedEnter and states of other blocked threads

How it works: Every handling of monContendedEnter event calls for checking that locked object’s monitor isn’t part of blocked thread loops. If it is then all thread are deadlocked. All threads in loop receive this event at the end of their event system.

Representation:

It is represented only in Thread Visualization view. Event is depicted as box on thread’s time line until the end. Color and flooding are selected according to legend. User can open call stack view for the call associated with monContendedEnter agent event.

Current status:

                        Already exist, no changes required.

 

7.     TRCThreadDeadEvent

Description:

                        Intended to express thread termination.

Specification (attributes):

                        Base class: TRCThreadEvent

                        Attributes:

                                    Time

Evaluation algorithm:

Input: agent’s event threadEnd

How it works: All required information (time) loaded from threadEnd event

Representation:

It is represented only in Thread Visualization view. Event is depicted as box on thread’s time line until the end. Color and flooding are selected according to legend.

Current status:

                        Already exist, no changes required.

 

          Entities for thread interaction reflection

8.     TRCThreadExecEvent

Description:

Base event for interactions, allows receiving new state of threads caused by event.

Specification:

                        Base class: TRCThreadEvent

                        Attributes:

                                    runNum – number of threads executed by abstract interaction

                                    iterator thru corresponding TRCThreadRunningEvent events

 

9.     TRCThreadStartsThreadEvent

Description:

Show that thread spawns another thread. 

Specification:

                        Base class: TRCThreadInteraction

                        Attributes:

                                    threadId – id of the thread spawning the new one

startedThread – object reference id of the started thread

runningEvent – reference to the TRCThreadRunningEvent element of the spawned thread (initially NULL – see “how it works” section for more information)

Evaluation algorithm:

Input: agent’s event callStart

How it works: The startedThread attribute identifies the object reference ID of the spawned thread. When the spawned thread starts and its threadStart event is received, the field runningEvent of the spawning thread will be updated with a reference to the TRCThreadRunningEvent object of the spawned thread.

 

Representation:

It depicts interaction between threads. Arrows should point from starter to started thread.

 

10.            TRCThreadHandoffLockEvent

Description:

Class instance provide information about passing monitor between threads in case of contention. 

Specification:

                        Base class: TRCThreadInteraction

                        Attributes:

                                    lockedObject – monitor of this object have been passed

                                    receiverThread – released monitor receiving thread

                                    runningEvent – corresponded TRCThreadRunningEvent

Evaluation algorithm:

Input: agent’s event monContendedEntered, and table with correspondence between lockedObject (monitors) and current owner threads. Table is maintained during collection.

How it works: Monitors – owner threads table is a kind of map (it can be hash table or other). This Map maintained in following way. Since events about enter and entered in monitor only come in case of contention information about monitors can be obtained only when they are already locked (owned) my some unknown thread. Event monContendedEnter comes for thread which is trying to acquire monitor. monContendedEnter contains information about current owner of monitor, so data about initial owner which later pass monitor to next thread can be caught. For further maintains of the map both events monContendedEnter and monContendedEntered can be used.  monContendedEnter as mentioned above provides current owner, monContendedEntered is sent to the new owner of monitor.

               TRCThreadHandoffLockEvent is related to contended exit from monitor (exit from monitor while other thread is waiting to acquire it), this happens only in pair with monContendedEntered and hence it can be generated as supplement to this event. Descriptive information for it can be gathered in following way. Monitor ID can be taken directly from monContendedEntered and thread for which this event happens can be taken as previous owner of monitor from the map.

Representation:

It depicts interaction between threads. Arrows should be drawn between threads and its show how monitor ownership transited.

 

11.            TRCThreadInterruptThreadEvent

Description:

Shows that Thread class’s method “interrupt” have been called from thread.

Specification:

                        Base class: TRCThreadInteraction

                        Attributes:

                                    threadId – thread id of caller

interruptedThread – object id of the interrupted thread

runningEvent – corresponded TRCThreadRunningEvent

Evaluation algorithm:

Input: agent’s events callInterrupt, monWaited, threadInterrupted

How it works: When the interrupted thread returns to execution and its monWaited (threadInterrupted) event is received, the TRCThreadInterruptThreadEvent of the interrupting thread will be updated with a reference to the TRCThreadRunningEvent object of the interrupted thread.

Representation:

It is depicts interaction between threads. Arrows should point from interrupting to interrupted thread.

 

12.            TRCThreadNotifyAllEvent

Description:

Represents a thread invoking the notifyAll() method on a monitor.

Specification:

                        Base class: TRCThreadInteraction

                        Attributes:

                                    threadId – thread id of  “notifyAll” method caller

objectRef – Id of notified object

list of TRCThreadRunningEvent – a list of references to TRCThreadRunningEvent elements of the threads that woke up as a result of calling notifyAll (initially empty, see “how it works” section for more information).

Evaluation algorithm:

Input: agent’s event callNotify with “isNotifyAll” key equal “true”, monWaited

How it works: The objectRef attribute identifies the notified object. When the notified thread wakes up (receives monWaited event for “objectRef”), reference to the TRCThreadRunningEvent object of the woken thread will be added to the list in TRCThreadNotifyAllEvent of the notified thread.

Due the problem that JVM TI event JVMTI_EVENT_MONITOR_WAITED fired only then thread acquire monitor. Binding between thread calling notifyAll and woken threads can be ambiguous.

Proposed following rule: For each thread, which received monWait event, corresponded notification event firstly searched among callNotify events. callNotify event should have the same monitor and be unbound. If there is no such event then search among callNotifyAll. It can be bound with more then one woken thread. If appropriate notification wasn’t found then it is saved in dedicated map and should be bound with new callNotify/callNotifyAll events.

Representation:

It depicts interaction between threads. TBD it is difficult if too much thread notified. Just present this call on time line and provide callstack. As a stretch goal list of notified threads can be provided

 

13.            TRCThreadNotifyEvent

Description:

Represents a thread invoking the notify() method on a monitor.

Specification:

                        Base class: TRCThreadInteraction

                        Attributes:

                                    threadId – thread id of the thread  which calls “notify” method

objectRef – Id of notified object

runningEvent – corresponded TRCThreadRunningEvent

 

Evaluation algorithm:

Input: agent’s event callNotify with “isNotifyAll” key equal “false”, monWaited

How it works: The “objectRef” attribute identifies the notified object. When the notified thread wakes up (receives monWaited event for “objectRef”), the TRCThreadNotifyEvent of the notified thread will be updated with a reference to the TRCThreadRunningEvent object of the woken thread.

See «How it works» for TRCThreadNotifyAllEvent.

Representation:

It depicts interaction between threads. Shows arrow from notifying to notified thread.

 

14.            TRCThreadDeadAndNotifyJoinedEvent

Description:

Show that thread dead and woke up all joined thread.

Specification:

                        Base class: TRCThreadInteraction

                        Attributes:

Time

runningEvent – corresponded TRCThreadRunningEvent

Evaluation algorithm:

Input: agent’s event monWaited

How it works: if reference ID of monitor from monWaited corresponds to some thread’s objID then event TRCThreadDeadAndNotifyJoined added to the end of event sequence of this thread (thread should be terminated already), and TRCThreadRunningEvent field fills with reference to   TRCThreadRunningEvent event consequent of received monWaited.

Representation:

It depicts interaction between threads. Shows arrow from dead thread to joined.

 

15.            TRCThreadWaitTimeoutExceedEvent

Description:

                        Shows that wait finished by timeout

Specification (attributes):

                        Base class: TRCThreadEvent

                        Attributes:

Evaluation algorithm:

Input: agent’s event monWait

How it works: Creation based on monWait if isTimedOut (attribute should be added) and inserted to the thread event sequence before TRCThreadRunningEvent.

Representation:

It is represented only in Thread Visualization view. Event is depicted as short box on thread’s time line. Color and flooding are selected according to legend. User can open call stack view for the call associated with monWaited agent event.

 

 

Subsidiary data structures maintained at collecting

1.     Monitor to owner thread map

Description: Map allows define which thread currently own monitor of object with certain ObjRefID.

 

2.     Object Reference to threads ID map

Description: Each thread has unique ID and Java Object associated with this thread. Map allows to define thread ID  by its ObjRefID

 

3.     threads ID to Object Reference map

Description: Each thread has unique  ID and Java Object associated with this thread. Map allows to define ObjRefID  by its thread ID

 

4.     Object Reference (monitor) to last its notification map

Description: Last notifications are following events TRCThreadNotifyEvent or TRCThreadNotifyAllEvent. This map helps bind TRCThreadRunningEvent caused by monWaited agent event with corresponded notification.

       

5.     Object Reference (monitor) to woken and unbound TRCThreadRunningEvent

Description: Allow to find unbound TRCThreadRunningEvent caused by monWaited with new incoming TRCThreadNotifyEvent or TRCThreadNotifyAllEvent.

       

Extension for TPTP (Profiler) events set

 

In current implementation all events related to thread profiling are generated by JBM TI interface. For further extension of profiler functionality some instrumentation injection required. This design is oriented on minimal affecting of system classes and such classes as java.lang.Thread and java.lang.ThreadGroup don’t have to be instrumented.

 

XML event

PI Support before 4.5

TI Support before 4.5

4.5 TI  Support

Requires BCI

monContendedEnter

 

V

V

no

monContendedEntered

 

V

V

no

monWait

 

V

V

no

monWaited

 

V

V

no

threadStart

 

V

V

no

threadEnd

 

V

V

no

threadStartCalled

 

 

V

yes

threadInterruptCalled

 

 

V

yes

monNotifyCalled

 

 

V

yes

threadInterrupted

 

 

V

yes

 

            Binary code instrumentation could have additional impact on profiling performance overhead and can reveal hidden JVM problems. To make instrumentation optional key “contanalysis” should be added to ThreadProf.

 

Execution dialog in WB “Profiler configuration” should be extended with thread profiler configuration dialog.

 

1.     monContendedEnter

Description:

Thread’s blocking on monitor trigger this event.

DTD:

<!ELEMENT monContendedEnter ((annotation)*)>

<!ATTLIST monContendedEnter

            threadIdRef CDATA #IMPLIED

            time CDATA #IMPLIED

            objIdRef CDATA #IMPLIED

            threadOwner CDATA #IMPLIED

> 

Source of event:

                        Based on JVM TI event handled on ThreadProf agent.

Current status:

                        Already exist, no changes required.

 

2.     monContendedEntered

Description:

Event Generation is triggered if thread successfully acquire monitor.

DTD:

<!ELEMENT monContendedEntered ((annotation)*)>

<!ATTLIST monContendedEntered

            threadIdRef CDATA #IMPLIED

            time CDATA #IMPLIED

            objIdRef CDATA #IMPLIED

> 

Source of event:

                        Based on JVM TI event handled on ThreadProf agent.

Current status:

                        Already exist, no changes required.

 

3.          monWait

Description:

Thread’s waiting on monitor trigger this event.

DTD:

<!ELEMENT monWait ((annotation)*)>

<!ATTLIST monWait

            threadIdRef CDATA #IMPLIED

            time CDATA #IMPLIED

            objIdRef CDATA #IMPLIED

            timeout CDATA #IMPLIED

> 

Source of event:

                        Based on JVM TI event handled on ThreadProf agent.

Current status:

                        Already exist, no changes required

                                   

4.     monWaited

Description:

Fired when thread receives notification or interrupted or timeout exceed and start execution after waiting.

Specification:

isTimedOut: Indicate was thread woken by notification or interruption or continue execution by timeout.

DTD:

<!ELEMENT monWaited ((annotation)*)>

<!ATTLIST monWaited

            threadIdRef CDATA #IMPLIED

            time CDATA #IMPLIED

            objIdRef CDATA #IMPLIED

            timeout CDATA #IMPLIED

            isTimedOut (1|0) #IMPLIED

> 

Source of event:

                        Based on JVM TI event handled on ThreadProf agent.

Current status:

                        Already exist, but required field should be supported “isTimedOut”

           

5.     threadStart

Description:

Fired when a thread starts

DTD:

<!ELEMENT threadStart ((annotation)*)>

<!ATTLIST threadStart

            transientThreadId CDATA #IMPLIED

            threadId CDATA #IMPLIED

            time CDATA #IMPLIED

            groupName CDATA #IMPLIED

            parentName CDATA #IMPLIED

            transientObjIdRef CDATA #IMPLIED

            objIdRef CDATA #IMPLIED

            threadName CDATA #IMPLIED

            collationValue CDATA #IMPLIED

            traceIdRef CDATA #IMPLIED

> 

Source of event:

                        Currently based on JVM TI event handled on ThreadProf agent.

Current status:

                        Already exist, no changes required

           

6.     threadEnd

Description:

Fired when a thread is terminated

DTD:

<!ELEMENT threadEnd EMPTY>

<!ATTLIST threadEnd

            transientThreadIdRef CDATA #IMPLIED

            threadIdRef CDATA #IMPLIED

            time CDATA #IMPLIED

            collationValue CDATA #IMPLIED

            traceIdRef CDATA #IMPLIED

> 

Source of event:

                        Currently based on JVM TI event handled on ThreadProf agent.

Current status:

                        Already exist, no changes required

           

7.     threadStartCalled

Description:

Fired when thread calls for Thread class’s start method and spawn another thread.

Specification:

threadId - Id of thread calls “start”

            time - time when element was generated

objIdRef - ID of object’s reference for which method “start” was called

DTD:

<!ELEMENT callStart ((annotation)*)>

<!ATTLIST callStart

            threadId CDATA #IMPLIED

            time CDATA #IMPLIED

            objIdRef CDATA #IMPLIED

> 

Source of event:

It is generated by inserted BCI probes. Instrumentation hooks call for start method of Thread class and send event about that to agent

Instrumentation:

Require instrumentation.

Current status:

                        Absent, require full implementation.

                       

 

8.     threadInterruptCalled

Description:

Fired when thread calls for Thread class’s interrupt method and target thread in waiting state (check via getState() == (WAITING | TIMED_WAITING))

Specification:

threadId - Id of thread calls “interrupt”

            time - time when element was generated

objIdRef - ID of object’s reference for which method “interrupt” was called.

DTD:

<!ELEMENT callInterrupt ((annotation)*)>

<!ATTLIST callInterrupt

            threadId CDATA #IMPLIED

            time CDATA #IMPLIED

            objIdRef CDATA #IMPLIED

> 

Source of event:

It is generated by inserted BCI probes. Instrumentation hooks call for “interrupt” method of class “Thread” and send event about this to agent

Current status:

                        Absent, require full implementation.

 

9.     monNotifyCalled

Description:

Fired when thread calls for “notify”/”notifyAll” method for object

Specification:

          threadId - Id of thread calls for “notify”/”notifyAll”

            time - time when element was generated

objIdRef - ID of object’s reference. Interrupt method was called for this object.

            isNotifyAll - boolean value, it defines “notify” or “notifyAll” was called

                       

DTD:

<!ELEMENT callNotify ((annotation)*)>

<!ATTLIST callNotify

            threadId CDATA #IMPLIED

            time CDATA #IMPLIED

            objIdRef CDATA #IMPLIED

            isNotifyAll (1|0) #IMPLIED

> 

Source of event:

It is generated by inserted BCI probes. Instrumentation hooks call for “notify” method of class “Object” and send event about this to agent.

Current status:

                        Absent, require full implementation.

 

10.            threadInterrupted

Description:

This event considered as a stretch goal, it is only required for more precise binding between interrupt and interrupted threads.

Fired when exception “java.lang.InterruptedException” is thrown in thread.

 

This event is triggered by an exception, which is thrown in the current thread.

Specification:

                        threadID is Id of interrupted thread.

                        time is Time when element was generated

DTD:

<!ELEMENT threadInterrupted ((annotation)*)>

<!ATTLIST threadInterrupted

            threadId CDATA #IMPLIED

            time CDATA #IMPLIED

> 

Source of event:

                        Generated by JVM TI handler.

Instrumentation:

Doesn’t require instrumentation. Can be implemented via JVM TI event JVMTI_EVENT_EXCEPTION

Current status:

                        Absent, require full implementation.