JDK-6373461 : Unhanded oop detector misses naked oops with locks guarded by conditional
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-01-17
  • Updated: 2012-10-08
  • Resolved: 2006-11-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u4Fixed 7Fixed hs10Fixed
The unhandled oop detector will clear stack allocated oops in MutexLocker code to detect whether an oop is held around a safepoint (lock), but misses the case in code like JvmtiThreadState::state_for() where taking the lock out is conditional.   It should check for naked oops even if the condition around the lock is not true because it may be that way during testing with the switch, and miss the case when it's true.

  // retrieve or create JvmtiThreadState
  inline static JvmtiThreadState *state_for(JavaThread *thread) {
    JvmtiThreadState *state = thread->jvmti_thread_state();
    if (state == NULL) {
      MutexLocker mu(JvmtiThreadState_lock);
      // check again with the lock held
      state = state_for_while_locked(thread);
    return state;

EVALUATION Fixed 6373461: Unhanded oop detector misses naked oops with locks guarded by conditional The naked oops are cleared so they crash in the call to MutexLocker, but in a few cases, the MutexLocker was inside a conditional causing the detector to miss naked oops (esp in code surrounding the JvmtiThreadState state_for()) call. I fixed several of these to clear the naked oops in the else clause if MutexLocker was conditionalized. That should find more naked oops.

EVALUATION There were only a few obvious cases like this, so I fixed them. I didn't change the vm for cases where a call that takes out a lock is protected by a conditional. Those are harder to find.