Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4763264

JDI spec: ObjectReference.waitingThreads: add the owner must be suspended

XMLWordPrintable

    • generic, sparc
    • generic, solaris_9

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

      While working on the fix for the following bug:

          4546581 4/5 GetCurrentContendedMonitor, GetOwnedMonitorInfo,
                      GetMonitorInfo not implemented

      I ran into a minor bug in the following test:

          nsk/jdi/VirtualMachine/canGetMonitorInfo/cangetmonitorinfo001

      The main thread in the debuggee starts a worker thread while holding
      a monitor, lockingObject. The worker thread blocks on the monitor
      and the debuggee main thread waits for the debugger to tell it to
      proceed.

      The debugger suspends the worker thread while it is waiting to enter
      the monitor and verifies the JVM/DI GetCurrentContendedMonitor()
      call. It also verifies the JVM/DI GetMonitorInfo() call indirectly
      via the JDI ObjectReference.waitingThreads() call.

      The GetMonitorInfo() call fails because the debuggee main thread is
      not suspended (JVMDI_ERROR_THREAD_NOT_SUSPENDED). Here is the
      relevant requirements from the JVM/DI spec:

          Get Monitor Info
          :
          Get information about the the object's monitor The fields of the
          JVMDI_owned_monitor_info structure are filled in with details of
          the monitor. Each thread that might affect the monitor state must
          either be suspended or must be the current thread.

      The debuggee main thread owns the monitor and is not the caller of
      GetMonitorInfo() so it must be suspended.

      The JDI spec for ObjectReference.waitingThreads() does not document
      the requirement that the owner of the monitor needs to be suspended
      (or the current thread). This is because there is no 1-1 mapping
      between the JDI APIs and the JVM/DI APIs. The waitingThreads() API
      doesn't care about the owning thread. In other words, the
      waitingThreads() API doesn't know that it is built on top of the
      JVM/DI GetMonitorInfo() API so it doesn't describe requirements
      for the underlying API that do not directly map to the information
      that it is trying to return (a list of waiting threads).

      It is entirely possible that the ObjectReference.waitingThreads()
      API should be suspending the thread that owns the object on behalf
      of the caller. However, I can't make that call.

            Unassigned Unassigned
            dcubed Daniel Daugherty
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: