EVALUATION
jinfo -flag is an interim solution to enable DTrace probes dynamically. As Mandy said, this is suppose to go away. We don't want to commit to too many flags being manageable/writable by jinfo. The CCC (http://ccc.sfbay/6402766) clearly stated about ExtendedDTraceProbes and manageable flags (as defined for HotSpotDiagnosticMBean) only. This bug is accepted for investigating the first part of the bug (i.e., Staring from JDK6b85 turning off ExtendedDTraceProbes flag in runtime does not work).
|
EVALUATION
I confirmed that obervation reported in (part 1) description is correct and it is indeed a bug. When I checked all related b85 putbacks, I came across this change in build 85:
6417266 sun/management/jmxremote/bootstrap/LocalManagementTest.sh fails with IOException: Bad file number
We essentially removed the logic for "last client detach" detection and call to detach_all operation. But we depend on last-client-detach event in elsewhere. When disabling ExtendedDTraceProbes flag, we delay sync'ing it with fine-grained DTrace probe flags. This is the root cause of the current problem.
|
SUGGESTED FIX
With fix for 6417266 (sun/management/jmxremote/bootstrap/LocalManagementTest.sh fails with IOException: Bad file number), we essentially removed (the incorrect) logic for "last-attach-on-demand-client-detach" detection and call to detach_all operation. When disabling ExtendedDTraceProbes flag, we delayed syncing it with fine-grained DTrace probe flags. This is the root cause of the current problem.
Code in src/share/vm/services/dtraceAttacher.cpp depends on detach all event being called:
void DTrace::set_extended_dprobes(bool flag) {
// explicit setting of ExtendedDTraceProbes flag
set_bool_flag("ExtendedDTraceProbes", flag);
// make sure that the fine grained flags reflect the change.
if (flag) {
enable_dprobes(DTRACE_ALL_PROBES);
}
/*
* disable_dprobes call is delayed till next "detach all "event.
* This is done so that concurrent DTrace clients that may
* have enabled one or more fine grained dprobes and may be
* running still. On "detach all" clients event, we would
* sync ExtendedDTraceProbes with fine grained flags which
* would take care of disabling fine grained flags.
*/
}
In the above logic, we don't reflect DTrace "overall" flag change into fine-grained flags immediately -- we instead wait for last-client-detach. This is because concurrent DTrace client could have used libjvm_dtrace.so (it does not as of now-- but it will) and turned a fine grained flag. So, we have to wait for all-client-detach and then disable fine grained flag! So, the correctness depends on all-client-detached event.
We can probably not worry about DTrace using libjvm_dtrace.so and go with sync'ing "overall" flag with fine grained flags immediately.
After fix, the above would look like:
void DTrace::set_extended_dprobes(bool flag) {
// explicit setting of ExtendedDTraceProbes flag
set_bool_flag("ExtendedDTraceProbes", flag);
// make sure that the fine grained flags reflect the change.
if (flag) {
enable_dprobes(DTRACE_ALL_PROBES);
} else {
// fix explanation here...
disable_dprobes(DTRACE_ALL_PROBES);
}
}
|
EVALUATION
DTraceMethodProbes, DTraceAllocProbes, and DTraceMonitorProbes flags are internal flags and not designed for users to be dynamically set via jinfo. The jinfo -flag +ExtendedDTraceProbes is an interim solution until DTrace is changed to use the new JVM/DTrace interface which allows to enable one type of extended probes instead of all.
Accept this bug to further investigate problem #1.
|
Java