RFR: 8286830: ~HandshakeState should not touch oops

[Daniel D.Daugherty]

On Fri, 3 Jun 2022 20:45:42 GMT, Daniel D. Daugherty <dcubed 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
>
> test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 95:
> 
>> 93:         threadCreator.setDaemon(true);
>> 94:         threadCreator.start();
>> 95:         test(timeMax);
> 
> Okay, but now the test is going to execute for twice `timeMax` which might be
> a bit of a surprise... In particular the usage() mesg is now wrong.

Also, the `@bug` line is not updated with this bug ID.

> test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 101:
> 
>> 99:         threadCreator.setDaemon(true);
>> 100:         threadCreator.start();
>> 101:         test(timeMax);
> 
> Okay, but now the test is going to execute for twice `timeMax` which might be
> a bit of a surprise... In particular the usage() mesg is now wrong.

Also, the `@bug` line is not updated with this bug ID.

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

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