RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended

David Holmes david.holmes at oracle.com
Tue Oct 20 07:26:27 UTC 2020


On 20/10/2020 5:20 pm, Robbin Ehn wrote:
> On Tue, 20 Oct 2020 02:22:15 GMT, David Holmes <dholmes 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.
>>
>> src/hotspot/share/prims/jvmtiEnv.cpp line 1648:
>>
>>> 1646:     op.doit(java_thread, true);
>>> 1647:   } else {
>>> 1648:     Handshake::execute(&op, java_thread);
>>
>> This pattern is repeated a lot - we should be able to incorporate it into the op itself by passing in `java_thread`.
> 
> My suggestion here is that we fix this in Handshake::execute() in separate RFE.

Not clear to me this is so generic that it applies to Handshake::execute 
rather than being part of the operation. ??

David
-----

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1525:
>>
>>> 1523:   Thread* current_thread  = Thread::current();
>>> 1524:   HandleMark hm(current_thread);
>>> 1525:   JavaThread* java_thread = target->as_Java_thread();
>>
>> Contrast with the same three lines at L1390 - we should use the same boilerplate in each `doit`. And ideally refactor
>> into some shared code somewhere (future RFE).
> 
> Yes, that would be good.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/729
> 


More information about the serviceability-dev mailing list