Community
Participate
Working Groups
Current thinking on bug 190687 seems to be that "execution details in the enabled profiling mode are not implemented by design". This is a request to implement this feature, which has proved useful for many years in the Eclipse Profiler (http://eclipsecolorer.sourceforge.net/index_profiler.html). In particular, there seems to be no other way of obtaining execution details for remote server processes. It is understood that this mode incurs some performance overhead even before the profiler is attached to the profiled process, as the call graph must be maintained accurately right from the start.
Based on the discussion in bug 190687, I propose to rename this feature request to "Allow running the CPU Profiler with execution flow details when data collection is initially disabled"
I have found a replacement for this feature that gives me almost exactly what I need: (1) Start the external ACServer (2) Start the application to be profiled with -agentlib:JPIBootLoader=JPIAgent:server=controlled;CGProf:execdetails=true (3) Start profiling with "Attach to Agent" in the workbench (4) Press "Start monitoring" (green arrow) in the Profiling perspective. The application "hangs" on startup until step (4) is complete, but works fine afterwards, and one obtains the detailed trace of the external application this way. Since this procedure allows one to obtain the detailed trace of an external app., the request to make this work also with "server=enabled" becomes far less important. (Somehow I had been under the impression that the mode "server=controlled" could be used only with the internal AC.)
This is related to bug 194081.
Here's a summary of all the issues related to this enhancement request (information is based on the discussions in bug 190687 and bug 194081). As opposed to JVMPI, the Method Enter/Leave notifications in JVMTI (which are the basis for constructing a call-graph and computing method execution times) are generated by instrumentation. Beginning with TPTP 4.4.1, this instrumentation is applied only when the profiler is attached, meaning that no Method Enter/Leave notifications are generated until a profiler attaches. Therefore, when the profiler attaches, we need to reconstruct the "execution context" of each thread. The only way of doing this is by examining the call-stack of each thread using JVMTI stack-walk functions. The call-stack information provided by JVMTI may be incomplete due to method inlining (an inlined method does not have a stack frame and will not be returned by the JVMTI stack-walk function). Therefore, the execution context constructed for each thread may not match the actual method call-chain executed by a thread. If the above problem is not handled properly it can lead to incorrect profiling results. This is better illustrated with an example: Consider the following method chain for a certain thread: main() -> a() -> b() -> c() Assume that a() is a small method (inlined by the JIT-compiler) and that it is invoked twice. Assume we attach a profiler when execution enters c() for the first time. Capturing the execution context at this point (using stack walk) will give us the following call chain: main() -> b() -> c() - because a() was inlined. Now assume that execution continues (under the profiler), reaches back to main() and enters a() again. At this point, a Method Enter notification will be generated for a() since a() is now instrumented. Repeating the same execution path as before will now generate the following call-chain: main() -> a() -> b() -> c() Combining these call-chains on the workbench side will yield the following call-graph: main() <1 call> b() <1 call> c() <1 call> a() <1 call> b() <1 call> c() <1 call> Obviously, this is incorrect. Profiling the same application in "controlled" mode will give us a different call-graph (the correct one): main() <1 call> a() <2 calls> b() <2 calls> c() <2 calls> This behavior may confuse users. Handling the discrepancies shown above is not trivial and additional discussion is required.
Could this be something the China team can start looking for the upcoming release. This limitation is blocking certain profile on server feature from working.
Mass update of P1 enhancements and defects targetted to future to P2.
Since shadow stack solution has been added in bug 270767. Now execution details with the "enabled" profiling mode can be supported. Thanks, Chengrui
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html).
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
