RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2]

Daniel D.Daugherty dcubed at openjdk.java.net
Fri Jul 30 00:15:31 UTC 2021


On Fri, 30 Jul 2021 00:02:46 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> It was added here:
>> 
>> commit bec8431683a36ad552a15cd7c4d5ca48058249a7
>> Author: Robbin Ehn <rehn at openjdk.org>
>> Date:   Fri Feb 15 14:15:10 2019 +0100
>> 
>>     8203469: Faster safepoints
>>     
>>     Reviewed-by: dcubed, pchilanomate, dholmes, acorn, coleenp, eosterlund
>
> Here's the code block:
> 
>   uint64_t safepoint_id = SafepointSynchronize::safepoint_counter();
>   // Check that we have a valid thread_state at this point
>   switch(state) {
>     case _thread_in_vm_trans:
>     case _thread_in_Java:        // From compiled code
>     case _thread_in_native_trans:
>     case _thread_blocked_trans:
>     case _thread_new_trans:
> 
>       // We have no idea where the VMThread is, it might even be at next safepoint.
>       // So we can miss this poll, but stop at next.
> 
>       // Load dependent store, it must not pass loading of safepoint_id.
>       thread->safepoint_state()->set_safepoint_id(safepoint_id); // Release store

So I think @robehn was trying to separate these two lines of code:

`uint64_t safepoint_id = SafepointSynchronize::safepoint_counter();`

and

`thread->safepoint_state()->set_safepoint_id(safepoint_id);`

I think the same situation applies in the updated code, but it is harder
to see in this GitHub view. Especially now that I've added all these
comments.

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

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


More information about the hotspot-runtime-dev mailing list