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

Coleen Phillimore coleenp at openjdk.org
Thu Oct 3 19:32:37 UTC 2024


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?

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

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


More information about the hotspot-runtime-dev mailing list