RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]
Robbin Ehn
rehn at openjdk.java.net
Thu Oct 22 08:07:34 UTC 2020
On Wed, 21 Oct 2020 20:31:27 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:
>> 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
>
> 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?
@reinrich did I mess something up when merging this in?
> src/hotspot/share/prims/jvmtiEnv.cpp line 1663:
>
>> 1661: return JVMTI_ERROR_OUT_OF_MEMORY;
>> 1662: }
>> 1663: if (!eb.deoptimize_objects(1)) {
>
> Oh and why is the depth 1 here, when two frames are deoptimized? Maybe I missed something.
@reinrich did I mess something up when merging this in?
-------------
PR: https://git.openjdk.java.net/jdk/pull/729
More information about the serviceability-dev
mailing list