Bugzilla – Full Text Bug Listing
| Summary: | [ThreadProf] Many redundant, short-living threads reported when data collection is resumed | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Asaf Yaffe <asaf.yaffe> |
| Component: | TPTP | Assignee: | Igor Alelekov <igor.alelekov> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P1 | CC: | analexee, asaf.yaffe, guru.nagarajan, jkubasta, stanislav.v.polevic |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | closed460 | ||
|
Description
Asaf Yaffe
Second approch is preferable, because it is allows to control time and conditions then attach/detach happens. But probably existed functionality with automatic attach then required should remain. It allows solve problem without breakage of current functionality. One possible approche is add second set of function which can be called from already attached thread. Asaf, since this solution requires changes in Martini API, could you estimate it, please? From profiler side I estimate it in 2 days to implement and 1 day to test. Martini changes should take no longer than 1 day (implementation and testing) Added to Igor's queue. Hi Asaf, Regarding to the second solution: Don't you think that instead of set of short-living threads we will get the same threads, but long-living? JVM creates a new thread each time of attachement. And, if clients will keep their attached state, these threads will not die and will be reported to the user as before. As another option, can we just filter out these redundant threads based on some their characteristics? I hoped we can use thread's state (JVMTI_THREAD_STATE_IN_NATIVE field), but in my sample jvm returns the same state (5) for all threads. Thanks, Igor. (In reply to comment #5) > Don't you think that instead of set of short-living threads we will get the > same threads, but long-living? You'll get one such thread each time you attach. Best case scenario: one thread per profiling session Worst case scenario: one thread each time data collection is attached, paused or resumed. Both options are better than the current behavior. > > As another option, can we just filter out these redundant threads based on some > their characteristics? I hoped we can use thread's state > (JVMTI_THREAD_STATE_IN_NATIVE field), but in my sample jvm returns the same > state (5) for all threads. I couldn't find such a characteristic. When you attach an external thread to the JVM, the JVM creates a java.lang.Thread for the attached thread, and this triggers the JVMTI ThreadStart event. The same process happens with regular application threads. (In reply to comment #0) > 2. Move the responsibility of attaching external threads from Martini to its > clients (ThreadProf, CGProf, etc). This can be done by exposing two new Martini > APIs: AttachCurrentThread and DetachCurrentThread, and by modifying all other > APIs to return errors when called from an unattached thread. This way, the > Martini client can attach all its external threads to the JVM once, and detach > them when they terminate. Asaf, as a version of the (2), Can we consider the following changes? - All attachements in the Martini remain the same to ensure that a thread is attached. If the thread was already attached before, the call will not have any effect. - Remove calls to DetachCurrentThread() from Martini - expose DetachCurrentThread() call to delegate responsibility of detaching from Martini to its clients. It seems this might be more simple to implement and no additional checks for unattached threads are required. (In reply to comment #7) > Asaf, as a version of the (2), Can we consider the following changes? > - All attachements in the Martini remain the same to ensure that a thread is > attached. If the thread was already attached before, the call will not have any > effect. > - Remove calls to DetachCurrentThread() from Martini > - expose DetachCurrentThread() call to delegate responsibility of detaching > from Martini to its clients. > > It seems this might be more simple to implement and no additional checks for > unattached threads are required. > This suggestion will make the API behavior less predictable (e.g., if a tool didn't call an "attach" API, why should it call a "detach" API?). How about enhancing option 2 to behave as follows: 1) Expose Martini Attach and Detach APIs 2) Keep auto-attach functionality intact, but only in cases when the thread was unattached prior to the API calls which require attach. This will result in a consistent behavior: 1) If the tool didn't call Attach, Martini attaches the thread for the duration of the API execution, and then automatically detaches 2) If the tool attached the thread prior to invoking an API, Martini will not detach the thread upon API completion. What do you think? Agree. I like it. Do you think we should open new bugzilla to track required changes in Martini? Actually, thread attach/detach APIs are already informally exposed by Martini, but not through the MPI interface. The JPI library exports two functions: JPI_API TResult JPI_AttachCurrentThread(JNIEnv **ppJNIEnv, bool *bAttached); JPI_API void JPI_DetachCurrentThread(); **ppJNIEnv is an output variable for the thread's JNI environment pointer. *bAttached is an output variable that tells you whether the thread was attached (true) or was already attached prior to the call (false). This allows you to write safe code like this: <code> bool bAttached; JNIEnv *pNewEnv; JPI_AttachCurrentThread(&pNewEnv, &bAttached); // do something while attached... if (bAttached) JPIDetachCurrentThread(); </code> These functions are currently used by the Dynamic Probekit Agent. Please see the "CProbekitAgent::BindJpiFunctions()" function in src-native\src\ProbekitAgent\ProbekitAgent.cpp for an example on how to bind these two APIs. In reply to comment #10) Also note that Martini itself is using these two function to attach/detach threads as necessary. Bottom line: use these APIs. No further changes are required from Martini. (In reply to comment #11) > In reply to comment #10) > Also note that Martini itself is using these two function to attach/detach > threads as necessary. > Bottom line: use these APIs. No further changes are required from Martini. Thanks, I'll use these APIs to attach/detach. resolving as fixed 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. 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. |