RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

[Erik Österlund]

On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> The main point of this change-set is to make it easier to implement S/R on top of handshakes.
>> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality).
>> But we also remove some complicated S/R methods.
>> 
>> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is.
>> 
>> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns.
>> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed.
>> 
>> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs.
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Fixed merge miss
>  - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended
>  - Merge fix from Richard
>  - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended
>  - Removed TraceSuspendDebugBits
>  - Removed unused method is_ext_suspend_completed_with_lock
>  - Utilize handshakes instead of is_thread_fully_suspended

Just wondering why the escape barrier for force early return uses a stack depth is 0. Either that is wrong, or the escape barrier is not needed in the first place here. I think.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1390:

> 1388:       return JVMTI_ERROR_OUT_OF_MEMORY;
> 1389:     }
> 1390:     if (!eb.deoptimize_objects(0)) {

Why is the depth 0 here? That makes no sense to me. My understanding of this is that we have extracted the object deopt that would "normally" (since last week?) be done in JvmtiEnvBase::check_top_frame. And it is walking 1 frame, so shouldn't the depth be 1?

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

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