RFR: 8325937: runtime/handshake/HandshakeDirectTest.java causes "monitor end should be strictly below the frame pointer" assertion failure on AArch64 [v2]

[Robbin Ehn]

On Thu, 3 Oct 2024 19:01:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove comment about state.
>
> That is why I want a third fence here, if your shipping this:
> 
> bool HandshakeState::process_by_self(bool allow_suspend, bool check_async_exception) {
>   assert(Thread::current() == _handshakee, "should call from _handshakee");
>   assert(!_handshakee->is_terminated(), "should not be a terminated thread");
>   _handshakee->frame_anchor()->make_walkable();
>   // Threads shouldn't block if they are in the middle of printing, but...
>   ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id());
> ================>FENCE<==================
>   while (has_operation()) {
>     // Handshakes cannot safely safepoint. The exceptions to this rule are
>     // the asynchronous suspension and unsafe access error handshakes.
>     MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag);
> 
> As that would be for the MutexLocker which is now "missing" it. (not sure if it's problem or not)

> @robehn so you're saying that the process_by_self may be processing ThreadSelfSuspensionHandshake handshake, so setting state that another thread will be reading? Why not have the fence in do_self_suspend() ? And does it need also a SystemMemoryBarrier?

Yes, yes, maybe that is better. No it do not need sysmembar, this case is the oppsite, as we are only executing our own handshakes or blocking.

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

PR Comment: https://git.openjdk.org/jdk/pull/21295#issuecomment-2392286287