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