RFR: 8286830: ~HandshakeState should not touch oops

[David Holmes]

On Thu, 19 May 2022 19:17:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. 
> To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things:
> - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state.
> - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true.
> 
> I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases.
> 
> I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that.
> 
> Thanks,
> Patricio

Marked as reviewed by dholmes (Reviewer).

Hi Patricio,

I've had a much closer look at the details and have been surprised at how "loose" the coordination between handshakes and thread termination actually is. It would be good, IMO, if there was a point (like setting is_exiting) where you knew that once that was reached a thread would have zero interaction with handshakes and could delete everything handshake related if you wanted to.

The fact that the acquisition of the Threads_lock in Threads::remove might process any handshake certainly complicates things. I think, at a minimum, it would be preferable if we actually checked _is_exiting in that polling/checking logic so that we knew no further handshakes could be executed once _is_exiting is true - rather than placing the check in the operation (e.g. in install_async_exception()). That still relies on your changes for the destroy_vm case of course.

So future RFE's aside everything you are doing seems fine and reasonable. Thanks for your patience walking me through this one.

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

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