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