On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn <r...@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
