review request for 6740526
David Holmes - Sun Microsystems
David.Holmes at Sun.COM
Sat Aug 23 03:15:41 PDT 2008
I'd add to the comment:
"The right way to prevent termination would be to acquire the
Terminator_lock, but we can't do that without violating the lock rank
checking in some cases."
Xiaobin Lu said the following on 08/23/08 11:51:
> Webrev: http://javaweb.sfbay/~xl116366/webrev/6740526/
> 6740526: sun/management/HotspotThreadMBean/GetInternalThreads.java test
> The above test failure is caused by a recent fix for 6608862. The
> problem there was that when some JVMTI operation was made to examine all
> the threads' state and while in the meantime, the WatcherThread is
> actually exiting. This makes the ThreadClosure->do_thread call fail
> since we are now referencing a NULL pointer. To preserve WatcherThread
> and its data inside memory, we grab the Terminator_lock before making a
> call on it. So the thread calling WatcherThread::stop will be blocked
> and therefore can't set the reference to NULL and destroy the structure.
> I assumed that these operations (basically Threads::threads_do) are
> always called at safepoint, therefore, the rank checking when acquiring
> the Terminator_lock will be bypassed. The assumption is wrong since
> obviously some calls originating from management.cpp for example, aren't
> issued at safepoint, thus making the rank checking fail.
> The fix is that we remove the lock acquisition. As documented in the
> comment, strictly speaking, this isn't sufficient to make sure the data
> for WatcherThread is still there when the call is actually being made,
> but the chance of that is extremely small.
> Reviewed by:
> Verified by:
> All tests under sun/management
> Test reported in 6608862
> Thanks in advance!
More information about the hotspot-dev