RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake()

Richard Reingruber rrich at openjdk.java.net
Mon Oct 12 15:27:10 UTC 2020


On Mon, 12 Oct 2020 13:07:51 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Reading that comment I realized that this change would break in flight pr #119
>> 
>> To refresh memories: there I'm adding a new suspend flag currently required for object reallocation. I'm using a
>> handshake to synchronize with the suspendee thread S. After the handshake it is guaranteed that the stack of S is
>> walkable and S cannot push/pop frames. This would not work anymore.  I could replace the handshakes (in
>> [escapeBarrier.cpp line 172,
>> 218](https://github.com/openjdk/jdk/pull/119/files#diff-b72c15f49cba82da2158d4e9a4ab0e92R172-R173)) with vm operations
>> though. Should be ok.
>
> I see. You should still be able to use handshakes. I think the issue is that in handle_polling_page_exception(),
> instead of calling SafepointMechanism::process_if_requested(thread()), we should be doing { ThreadInVMfromJava
> __tiv(thread());} and { ThreadInVMfromJavaNoAsyncException __tiv(thread());} for the polling on return and not on
> return respectively. That will process a safepoint/handshake and then check the special conditions before going back to
> java.

Yes, looks like this is possible.

Wouldn't this also make the block
  if (state != _thread_blocked_trans &&
      state != _thread_in_vm_trans &&
      thread->has_special_runtime_exit_condition()) {
    thread->handle_special_runtime_exit_condition(
      !thread->is_at_poll_safepoint() && (state != _thread_in_native_trans));
  }
in `SafepointSynchronize::block(JavaThread *thread)`redundant? This would eliminate the recursion you mentioned in the
PR synopsis, I think.

-------------

PR: https://git.openjdk.java.net/jdk/pull/577


More information about the hotspot-runtime-dev mailing list