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

Handshakes and locking improvements

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: 16
    • Fix Version/s: tbd
    • Component/s: hotspot
    • Labels:

      Description

      In some scenarios when using handshakes is favored there is locking mechanism (most common a Mutex) involved.
      Many of the Mutexes require that we do safepoint check before locking it. This have two problems:
      * The handshake state is protected (as of now with a semaphore) we can thus deadlock if locking order is not correct.
      (As part of "8238761: Asynchronous handshakes" this changed to a Mutex)
      * Safepointing inside a handshake break the assumption that per thread resources are safe inside the handshake, since they are also safe to modify inside a safepoint. If the JavaThread stops for a safepoint in a handshake any such per thread resource may have changed after the safepoint but while still in the handshake.

      One train of thought is to add a NoSafepointVerifyer, and thus make sure we do not block or transition inside the handshake.
      (as of now safepoint checking is not allowed/untested but not enforced)

      The other train is to instead is to allow it and make sure it works.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              rehn Robbin Ehn
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated: