Question on JavaThread::is_ext_suspend_completed()
Daniel D. Daugherty
daniel.daugherty at oracle.com
Fri Sep 18 21:56:39 UTC 2020
Since T is in _thread_in_native, it can't execute Java bytecode with
transitioning back to thread_in_Java and it can't execute
Java bytecode equivalents (raw monitor enter) without transitioning
to thread_in_vm. In case of either of those transitions, the external
suspend request should be observed and T should self-suspend at that
point.
Dan
On 9/16/20 6:00 PM, Reingruber, Richard wrote:
> I think I can answer this myself now :)
>
> C sets _external_suspend in T's _suspend_flags then it reads T's thread state
> (with a store-load barrier between write and read). If C sees _thread_in_native
> than this read happened before the thread state change. This means T will see
> _external_suspend when checking _suspend_flags after changing the thread state
> to _thread_in_native_trans (again with store-load barrier).
>
> So if C sees _thread_in_native it can be sure that T is effectively suspended.
>
> Thanks, Richard.
>
> -----Original Message-----
> From: Reingruber, Richard
> Sent: Mittwoch, 16. September 2020 23:06
> To: Hotspot dev runtime <hotspot-runtime-dev at openjdk.java.net>
> Subject: Question on JavaThread::is_ext_suspend_completed()
>
> Hi,
>
> I've got a question on JavaThread::is_ext_suspend_completed():
>
> Current thread C loads the thread state of target thread T [1]. Assume it
> observes _thread_in_native and also that T has a walkable stack. In this case
> is_ext_suspend_completed() returns true [2]. If called by JavaThread::java_suspend(), then this
> method will also return.
>
> I don't see the synchronization that shields against C seeing stale values of T's
> thread state and frame anchor. To me it looks as if T could be executing java
> bytecodes while C observes a stale state making the wrong conclusion that T
> is effectively suspended.
>
> What am I missing?
>
> I'd think that a sleep just before returning true could trigger the issue, can't it? [4]
>
> Thanks, Richard.
>
> [1] Loading thread state
> https://github.com/openjdk/jdk/blob/1c84cfa2364fa18fc028df89bdc4de207365784f/src/hotspot/share/runtime/thread.cpp#L671
>
> [2] JavaThread::is_ext_suspend_completed() Returns true if save_state == _thread_in_native && frame_anchor()->walkable()
> https://github.com/openjdk/jdk/blob/1c84cfa2364fa18fc028df89bdc4de207365784f/src/hotspot/share/runtime/thread.cpp#L686
>
> [3] JavaThread::java_suspend() returns if JavaThread::is_ext_suspend_completed() returns true.
> https://github.com/openjdk/jdk/blob/1c84cfa2364fa18fc028df89bdc4de207365784f/src/hotspot/share/runtime/thread.cpp#L2512
>
> [4] Can a sleep before returning (see link below) trigger the issue?
> https://github.com/openjdk/jdk/blob/1c84cfa2364fa18fc028df89bdc4de207365784f/src/hotspot/share/runtime/thread.cpp#L691
More information about the hotspot-runtime-dev
mailing list