Details
-
Enhancement
-
Resolution: Fixed
-
P4
-
15
-
b18
Description
thread(s). The most common situation is that a JavaThread should wait for
something. If the targeted JavaThread is safepoint-safe (e.g., blocked/native) it
can't start waiting and the VMThread can't wait for it.
The JavaThread may be indefinitely safepoint-safe so the handshake operation may
never be executed. The requesting thread cannot use a synchronous handshake
since it might never finish.
By letting the request be asynchronous and guarantee that the handshake
operation will be performed if the thread tries to leave the safepoint-safe state, the
requester can act as if the JavaThread was already waiting in that handshake
operation.
Right now a JavaThread can only have one handshake operation so an asynchronous
handshake would thus block all other handshakes.
This means that it's not enough to make the request asynchronous, but also a
queue is needed to be able to process concurrent handshake operations.
Attachments
Issue Links
- duplicates
-
JDK-8252479 Introduce new assertion for checking current thread or handshaker
- Closed
- relates to
-
JDK-8254780 EnterInterpOnlyModeClosure::completed() always returns true
- Resolved
-
JDK-8223312 Utilize handshakes instead of is_thread_fully_suspended
- Resolved
-
JDK-8267079 Support async handshakes that can be executed by a remote thread
- Closed
-
JDK-8238861 Remove suspend_flag
- Open
-
JDK-8254263 Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake()
- Resolved
-
JDK-8238860 Safepoints with handshakes
- Closed
-
JDK-8252902 Handshakes and locking improvements
- Closed