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

assertion for return instr (JVMS 2ed) is dependent on structured locking

    Details

    • Subcomponent:
      vm
    • Resolved In Build:
      1.6
    • CPU:
      sparc
    • OS:
      solaris_2.5.1
    • Verification:
      Verified

      Description



      Name: dkC59003 Date: 08/04/99



      In The JVM Specification (2nd edition) chapter 6 (The JVM Instruction Set)
      on the page 353 it has been written:

      "...
      Runtime Exceptions

          If the current method is a synchronized method and the current thread is not the
          owner of the monitor acquired or reentered on invocation of the method, return
          throws an IllegalMonitorStateException. This can happen, for example, if a
          synchronized method contains a monitorexit instruction, but no monitorenter
          instruction, on the object on which the method is synchronized.
      ..."
      It is the new asssertion which is absent in the first edition of JVM Specification.

      But it is not difficult to understand that this assertion is dependent
      on the rules on structured use of locks described in Section 8.13.

      The rules on structured use of locks (JVM Specification (2nd edition), Section 8.13,
      page 413) are

      "...
      Implementations of the Java virtual machine are permitted but not required
      to enforce both of the following two rules guaranteeing structured locking.

      Let T be a thread and L be a lock. Then:

       1.The number of lock operations performed by T on L during a method
          invocation must equal the number of unlock operations performed by T
          on L during the method invocation whether the method invocation
          completes normally or abruptly.

       2.At no point during a method invocation may the number of unlock
          operations performed by T on L since the method invocation exceed the
          number of lock operations performed by T on L since the method
          invocation.
      ..."

      The new assertion will be right if and only if the JVM implementation does not
      enforces the second rule on structured use of locks.
      Otherwise, if the JVM implementation enforces this rule, then the situation
      adduced in the assertion never can be and this assertion will not have sense.
      It is so because accordingly with the assertion for monitorexit instruction
      given on the page 337 which is
      " Otherwise, if the virtual machine implementation enforces the rules on structured
        use of locks described in Section 8.13 and if the second of those rules is violated
        by the execution of this monitorexit instruction, then monitorexit throws an
        IllegalMonitorStateException. "
      the monitorexit instruction must throw the IllegalMonitorStateException and
      execution of return instruction will be blocked.
      Therefore this assertion must be rather as follow:

      "...
      Runtime Exceptions

          If the virtual machine implementation does not enforces the second rule
          on structured use of locks described in Section 8.13 then
          if the current method is a synchronized method and the current thread is not the
          owner of the monitor acquired or reentered on invocation of the method, return
          throws an IllegalMonitorStateException. This can happen, for example, if a
          synchronized method contains a monitorexit instruction, but no monitorenter
          instruction, on the object on which the method is synchronized.
      ..."

      Notes.
           There are the same assertions for the folowing instructions:
            areturn, dreturn, freturn, ireturn, lreturn.

      ==========================================================

      ======================================================================

        Attachments

          Activity

            People

            • Assignee:
              abuckley Alex Buckley
              Reporter:
              dkhukhrosunw Dmitry Khukhro (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: