After JDK-8230661 we are guaranteed that no mutator holds a weak oop containing a "dead" object when the ZResurrection::unblock() call happens.
Therefore, it doesn't matter if the load barrier that the thread executes runs the code guarded by ZResurrection::is_blocked() or the "non-blocked" part, when ZResurrection::unblock() changes the state. As long as the ZResurrection::unblock() call happens after the handshake, we are good to go.
Today, we perform the purging and deletion of metadata in _unload.purge(), and call ZResurrection:unblock() after that. There's no need to delay the unblocking to after the purge. We have the opportunity to shrink the resurrection-blocked window by moving the ZResurrection::unblock() call to before the call to _unload.purge(), but still after the handshake.
Therefore, it doesn't matter if the load barrier that the thread executes runs the code guarded by ZResurrection::is_blocked() or the "non-blocked" part, when ZResurrection::unblock() changes the state. As long as the ZResurrection::unblock() call happens after the handshake, we are good to go.
Today, we perform the purging and deletion of metadata in _unload.purge(), and call ZResurrection:unblock() after that. There's no need to delay the unblocking to after the purge. We have the opportunity to shrink the resurrection-blocked window by moving the ZResurrection::unblock() call to before the call to _unload.purge(), but still after the handshake.