Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2172388 | 7 | Lev Serebryakov | P3 | Closed | Fixed | b42 |
JDK-2172843 | 6u14 | Lev Serebryakov | P3 | Closed | Fixed | b01 |
With help of the D-Light tool I can see that the contended-exit events
comes after contended-entered event on another thread.
This is an example:
t12:Enter, t14:Enter, t2:Exit, t14:Entered, (t14:Exit is missed), t12:Entered
The tool does not show the t14:Exit event as it is already out of scope.
It happens because the Hotspot monitor-contended-exit probe is located incorrectly.
I think that posting the contended__exit monitor probe needs to be done
before wakee is unparked:
void ObjectMonitor::ExitEpilog (Thread * Self, ObjectWaiter * Wakee) {
...
Trigger->unpark() ;
// Maintain stats and report events to JVMTI
if (ObjectSynchronizer::_sync_Parks != NULL) {
ObjectSynchronizer::_sync_Parks->inc() ;
}
DTRACE_MONITOR_PROBE(contended__exit, this, object(), Self);
}
comes after contended-entered event on another thread.
This is an example:
t12:Enter, t14:Enter, t2:Exit, t14:Entered, (t14:Exit is missed), t12:Entered
The tool does not show the t14:Exit event as it is already out of scope.
It happens because the Hotspot monitor-contended-exit probe is located incorrectly.
I think that posting the contended__exit monitor probe needs to be done
before wakee is unparked:
void ObjectMonitor::ExitEpilog (Thread * Self, ObjectWaiter * Wakee) {
...
Trigger->unpark() ;
// Maintain stats and report events to JVMTI
if (ObjectSynchronizer::_sync_Parks != NULL) {
ObjectSynchronizer::_sync_Parks->inc() ;
}
DTRACE_MONITOR_PROBE(contended__exit, this, object(), Self);
}
- backported by
-
JDK-2172388 sometimes contended-exit event comes after contended-entered on another thread
-
- Closed
-
-
JDK-2172843 sometimes contended-exit event comes after contended-entered on another thread
-
- Closed
-