CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis

FIXED IN:
mantis

INTEGRATED IN:
mantis
mantis-b07

VERIFIED IN:
mantis


                                     

SUGGESTED FIX

###@###.### 2002-10-15

See the attached 4546581-webrev.tar file for the pre-code review version of
the changes.

###@###.### 2002-10-18

See the attached 4546581-webrev-cr1.tar file the changes from the code review.

###@###.### 2002-10-28

See the attached 4546581-webrev-cr2.tar file for the changes made after
an NSK test cycle. There were also two minor changes to the JPDA backend:

------- src/share/back/ObjectReferenceImpl.c -------
*** /tmp/sccs.MzaGmQ    Mon Oct 28 06:24:41 2002
--- ObjectReferenceImpl.c       Fri Oct 25 18:01:41 2002
***************
*** 173,179 ****
          WRITE_GLOBAL_REF(env, out, info.waiters[i]);
      }
  
!     jdwpFree(info.waiters);
      return JNI_TRUE;
  }
  
--- 173,181 ----
          WRITE_GLOBAL_REF(env, out, info.waiters[i]);
      }
  
!     if (info.waiter_count != 0) {
!         jdwpFree(info.waiters);
!     }
      return JNI_TRUE;
  }
  

------- src/share/back/ThreadReferenceImpl.c -------
*** /tmp/sccs.NzaGmQ    Mon Oct 28 06:24:41 2002
--- ThreadReferenceImpl.c       Fri Oct 25 16:15:35 2002
***************
*** 312,318 ****
          WRITE_GLOBAL_REF(env, out, monitor);
      }
  
!     jdwpFree(info.owned_monitors);
      return JNI_TRUE;
  }
  
--- 312,320 ----
          WRITE_GLOBAL_REF(env, out, monitor);
      }
  
!     if (info.owned_monitor_count != 0) {
!         jdwpFree(info.owned_monitors);
!     }
      return JNI_TRUE;
  }
                                     

EVALUATION

###@###.### 2002-10-11

The JVM/DI GetMonitorInfo() API returns a pointer to the following struct:

typedef struct {
    jthread owner;
    jint entry_count;
    jint waiter_count;
    jthread *waiters;
} JVMDI_monitor_info;

The owner field is pretty obvious, but the other fields are not. The
entry_count field could be the number of times the monitor is entered
by the owning thread (recursion count) or it could be the number of
threads waiting to enter (contention count). The waiter_count field
specified the number of jthread pointers in the waiters array. However,
is the waiters array the threads waiting to enter the monitor, the
threads doing an Object.wait() or both?

The resolve this mystery, I'm using the JDI spec for ObjectReference:

public int entryCount() 
    Returns the number times this object's monitor has been entered by
    the current owning thread.

public List waitingThreads()
    Returns a List containing a ThreadReference for each thread currently
    waiting for this object's monitor. See
    ThreadReference.currentContendedMonitor() for information about when
    a thread is considered to be waiting for a monitor.

ThreadReference.currentContendedMonitor() says:
    The thread can be waiting for a monitor through entry into a
    synchronized method, the synchronized statement, or Object.wait(long).

I'm planning to implement the GetMonitorInfo() API to meet the expectations
of JDI's use of the interface.

###@###.### 2002-10-14

GetCurrentContendedMonitor() returns a jobject for two conditions:

- the specified thread is waiting to enter
- the specified thread is waiting to regain through java.lang.Object.wait

The first condition is clear. The second needs clarification. An
Object.wait() call has two parts: the wait for notification (or
timeout) part and the reenter part. I believe the phrase "waiting to
regain" is intended to apply to the reenter part. However, the JDI
spec needs to be checked to see what is expected by the higher layers.

ThreadReference.currentContendedMonitor() says:

    Returns an ObjectReference for the monitor, if any, for which this
    thread is currently waiting. The thread can be waiting for a monitor
    through entry into a synchronized method, the synchronized statement,
    or Object.wait(long). The status() method can be used to differentiate
    between the first two cases and the third.

ThreadReference.status() says:

    Returns the thread's status. If the thread is not suspended the thread's
    current status is returned. If the thread is suspended, the thread's
    status before the suspension is returned (or THREAD_STATUS_UNKNOWN if
    this information is not available. isSuspended() can be used to determine
    if the thread has been suspended.

ThreadReference.THREAD_STATUS_WAIT says:
    Thread is waiting - Thread.wait() or JVM_MonitorWait() was called

Looks like the JDI layer is expecting that a call into Object.wait() will
result in the thread showing a contended monitor.
                                     

PUBLIC COMMENTS

.