RFR: 8238761: Asynchronous handshakes [v3]

[Robbin Ehn]

On Mon, 21 Sep 2020 05:32:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 157:
>> 
>>> 155:
>>> 156:     // Threads shouldn't block if they are in the middle of printing, but...
>>> 157:     ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id());
>> 
>> Can you explain why you had to add this?
>> Did something show up in testing?
>
> Yes please explain as this looks really bad.

The tty lock allow vm thread to block and it is a no safepoint check lock.
Meaning that you are not allowed to safepoint/handshake poll while holding it.
Also if someone is holding it, you can't print on the tty inside a safepoint/handshake.

The tty lock is also lower rank than Threads_lock (we used to block on that in safepoint) and lower rank than the
handshake state lock.

Compiler have code which takes the ttyLocker and prints on tty.
Some of the information that it prints passes code which can safepoint/handshake.
The way safepoint have gotten around this is by unlocking tty lock before a safepoint.
Now that handshake use a mutex instead of semaphore, we thus get an error also.
(even if you now don't get an error we could potentially deadlock, or at least we are very deep water).

Until compiler is fixed to UL we need this unlocking of the tty lock.

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

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