Community
Participate
Working Groups
This is somewhat related to 190802 but is more about the performance of JVMTI profiling. Because byte code instrumentation is done dynamically w/ JVMTI profiling, are we satisfied with the startup (or attach) performance when the enabled filters trigger a bunch of instrumentations and/or class redefinitions? Has some exploration of the overhead been performed? Is there a problem and is there some low hanging fruit to improve it. Related to this is the latency involved in deciding if the underlying VM is Java 1.4 or Java 5 so it can tell me which monitoring options to enable. This seems to take between 2 and 10 seconds on my box. Is any streamlining there planned?
There are two different use-cases here: 1. "load time" instrumentation, done when the profiler starts with the profiled application (standalone and controlled mode): the instrumentation overhead largely depends on the filter criteria. It is performing quite well as it is, and further optimizations must be done in the underlying Probekit BCI engine, although I am not sure whether this is worth the effort. 2. "dynamic" instrumentation, done when attaching the profiler to a running application (enabled mode): there are two factors here: the instrumentation overhead itself and the overhead of redefining loaded classes using the JVMTI RedefineClasses or RetransformClasses APIs. The first factor is identical to use-case 1. The second factor is more problematic: the implementation of RedefineClasses in both Sun and Bea JVMs (IBM was not tested as it does not support redefinition for certain system classes) is neither optimal nor scalable. It is slow, and consumes a lot of memory. As it is, relying on these APIs for dynamic instrumentation is a limitation which impacts performance and is not within our control.
good information. Has anyone tried comparable profilers that [I assume] use BCI? (e.g., netbeans profiler) to determine if TPTP overheads are consistent with other options?
Updated target milestone. To be considered for 4.5.
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.
