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

possible race in java_suspend_self_with_safepoint_check

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 16
    • Fix Version/s: 16
    • Component/s: hotspot
    • Subcomponent:
    • Resolved In Build:
      b15
    • CPU:
      generic
    • OS:
      generic

      Description

      During the code review of this fix:

          JDK-8252414: Redundant suspend check when determining if a java thread is safe

      Richard R. raised a possible issue with java_suspend_self_with_safepoint_check():

      On 8/28/20 9:33 AM, Reingruber, Richard wrote:
      > Hi Robbin,
      >
      > your change looks correct to me. Thanks!
      >
      > I see a related issue that allows a suspended thread to continue executing
      > java. Hope it's ok to ask about it here.
      >
      > Assume a thread T is resumed and then taken off CPU in JavaThread::java_suspend_self_with_safepoint_check()
      > just before restoring its prior state [1].
      >
      > In this situation T gets suspended again (by executing VM_ThreadSuspend)
      >
      > Now T is put back on the CPU. There are code paths where T won't check its
      > suspend flags and return to executing java even though it is suspended.
      >
      >
      > Example: JavaCallWrapper
      >
      > Stack:
      >
      > JavaThread::java_suspend_self_with_safepoint_check() : void
      > JavaThread::handle_special_runtime_exit_condition(bool) : void
      > JavaCallWrapper::JavaCallWrapper(const methodHandle &, Handle, JavaValue *, Thread *)
      >
      > Example: Polling page exception
      >
      > Stack:
      >
      > JavaThread::handle_special_runtime_exit_condition(bool) : void
      > SafepointSynchronize::block(JavaThread *) : void
      > SafepointMechanism::block_or_handshake(JavaThread *) : void
      > SafepointMechanism::block_if_requested_slow(JavaThread *) : void
      > SafepointMechanism::block_if_requested(JavaThread *) : void
      > ThreadSafepointState::handle_polling_page_exception() : void
      >
      > Would you agree or have I missed something?
      >
      > Note that there is no problem when T is put back on CPU while a handshake is
      > executed on its behalf because after restoring its prior state T calls
      > SafepointMechanism::block_if_requested() in
      > JavaThread::java_suspend_self_with_safepoint_check().
      >
      > Thanks, Richard.
      >
      > [1] T is taken off CPU before restoring its prior state.
      > https://github.com/openjdk/jdk/blob/30c2dbea95f817c93f84f0d8f7dc3b5c159b5e25/src/hotspot/share/runtime/thread.cpp#L2619

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              rrich Richard Reingruber
              Reporter:
              dcubed Daniel Daugherty
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: