Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "TPTP Java Profilers Anatomy"
(Add profilers' design details overview) |
|||
| Line 21: | Line 21: | ||
== Profiliers Anatomy == | == Profiliers Anatomy == | ||
| − | + | Profilers' classes will be described as below. We will introduce some profilers' infrastructure classes. Utility classes or Martini events handlers' classes are contained in concrete profilers' description. | |
| − | === ProfEnv: Profiling Environmental Information Storage for Profilers === | + | === CBaseProfiler: Base class for Concrete Profilers === |
| + | |||
| + | CBaseProfiler provide a method "init". In this method, three template virtual methods are called: ParceOptions, InitProfilerSpecificEvents(called by InitEvents) and InitFilter. Profiling context class CProfEnv is instantiated here too. Some common event handlers such as VM initialization and shut down are also instantiated in CBaseProfiler::InitEvents. | ||
| + | |||
| + | === ProfEnv: Profiling Environmental Information Storage for Profilers === | ||
| + | |||
| + | Profiling context class CProfEnv is a little complex. This class undertakes too many responsibilities since TPTP code has been maintained for several years. To analyze some problems related with CProfEnv, here is two suggestions: | ||
| + | |||
| + | *Start from outside callers to find which interfaces of CProfEnv are used. Then you can concentrate on these interfaces' implementation. | ||
| + | *Make sure which kind of profiling (Call Graph? Heap? or Thread?) is in your analysis. For example, there are two fields named "m_Tickets" and "m_pShadowStackTracker" which are just related with call graph profiling. | ||
=== Call Graph Profiler === | === Call Graph Profiler === | ||
| − | |||
| − | The first difference is data structure used for profiling data storage. CGProf profiling data is stored in a call-tree-like hierarchical stacks structure. Both are included in org.eclipse.tptp.platform.jvmti.runtime/src-native/src/baseprof/Tickets.h. Class CTicketStack is used for exec details mode while CStackHead for aggregated mode. | + | There are two modes which can be applied to Call Graph profiling - execution details and aggregated. The difference for users between these two modes is in execution details mode provides more detailed profiling information, and it can render call graph in workbench. However, it will run slower than aggregated mode. To support these two modes, different implementations are used in call graph profiler design. |
| + | |||
| + | The first difference is data structure used for profiling data storage. CGProf profiling data is stored in a call-tree-like hierarchical stacks structure. Both are included in org.eclipse.tptp.platform.jvmti.runtime/src-native/src/baseprof/Tickets.h. Class CTicketStack is used for exec details mode while CStackHead for aggregated mode. | ||
| − | The second difference is how to poll out profiling data. Exec Details mode uses a "push" model while aggregated mode uses a "pull" model. In exec details mode, profiling data is output promptly when methods' enter or leave events are received. In aggregated mode, the data will be sent out when receive collect data command or till termination of Java applications. You can also set polling out frequency before start profiling in Eclipse profiling options setting. | + | The second difference is how to poll out profiling data. Exec Details mode uses a "push" model while aggregated mode uses a "pull" model. In exec details mode, profiling data is output promptly when methods' enter or leave events are received. In aggregated mode, the data will be sent out when receive collect data command or till termination of Java applications. You can also set polling out frequency before start profiling in Eclipse profiling options setting. |
=== Heap Profiler === | === Heap Profiler === | ||
Revision as of 03:31, 13 November 2009
Contents
Introduction
TPTP provides with not only a profiling framework Martini, but also several Java profilers. Call graph, memory and thread anlysis are three basic profiling scenarios.
Profilers Design Overview
To abstract common operations in diffrent profilers, a class named "CBaseProf" is added. The design pattern Template is used here. BaseProf defines several template methods and subclasses of it need to implement these template methods.
Profiling data will be stored or output for different profiling. We will discuss the profiling data structure later. Different handler classes are added for processing different Martini profiling events such as a method enter or a thread start etc. These classes are packaged with concrete profilers.
Class "CProfEnv" is used for profiling context. It is used for interacting with Martini and JPIAgent. Profiling data will be stored or sent out by this class objects. Other utility classes such as "CTickets" is used for profiling data organization.
In summary, there are three kinds of classes in Java Profilers:
- Basic profilers: CBaseProf, CCGProf, CHeapProf and CThreadProf etc.
- Martini events handler for profilers: CMethodEnterEvent, CMethodLeaveEvent and CObjAllocEvent etc.
- Profiling context and data organization classes: CProfEnv and CTickets etc.
Profiliers Anatomy
Profilers' classes will be described as below. We will introduce some profilers' infrastructure classes. Utility classes or Martini events handlers' classes are contained in concrete profilers' description.
CBaseProfiler: Base class for Concrete Profilers
CBaseProfiler provide a method "init". In this method, three template virtual methods are called: ParceOptions, InitProfilerSpecificEvents(called by InitEvents) and InitFilter. Profiling context class CProfEnv is instantiated here too. Some common event handlers such as VM initialization and shut down are also instantiated in CBaseProfiler::InitEvents.
ProfEnv: Profiling Environmental Information Storage for Profilers
Profiling context class CProfEnv is a little complex. This class undertakes too many responsibilities since TPTP code has been maintained for several years. To analyze some problems related with CProfEnv, here is two suggestions:
- Start from outside callers to find which interfaces of CProfEnv are used. Then you can concentrate on these interfaces' implementation.
- Make sure which kind of profiling (Call Graph? Heap? or Thread?) is in your analysis. For example, there are two fields named "m_Tickets" and "m_pShadowStackTracker" which are just related with call graph profiling.
Call Graph Profiler
There are two modes which can be applied to Call Graph profiling - execution details and aggregated. The difference for users between these two modes is in execution details mode provides more detailed profiling information, and it can render call graph in workbench. However, it will run slower than aggregated mode. To support these two modes, different implementations are used in call graph profiler design.
The first difference is data structure used for profiling data storage. CGProf profiling data is stored in a call-tree-like hierarchical stacks structure. Both are included in org.eclipse.tptp.platform.jvmti.runtime/src-native/src/baseprof/Tickets.h. Class CTicketStack is used for exec details mode while CStackHead for aggregated mode.
The second difference is how to poll out profiling data. Exec Details mode uses a "push" model while aggregated mode uses a "pull" model. In exec details mode, profiling data is output promptly when methods' enter or leave events are received. In aggregated mode, the data will be sent out when receive collect data command or till termination of Java applications. You can also set polling out frequency before start profiling in Eclipse profiling options setting.