RFR: 8282952: Thread::exit should be immune to Thread.stop

[David Holmes]

On Tue, 22 Mar 2022 05:26:51 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Hi Patricio,
>> 
>>> Wouldn't it be easier to check some state in JavaThread::send_async_exception() and avoid delivering the ThreadDeath all together when the target is within that Java call in exit()? I don't see anything obvious we can use so we could either add a new enum value in TerminatedTypes or add some new thread member variable.
>> 
>> I specifically wanted this to be a general utility to defer delivery of asynchronous exceptions around a chunk of Java code, so we do not want to stop things upfront in `JavaThread::send_async_exception()`, but only in the back-end when we would actually deliver it. To do this does require a "state bit" somewhere in `JavaThread`, but given where I was trying to stall the delivery it made sense to simply steal another bit from the `SuspendFlags` and augment the `has_async_exception_condition()` check.
>> 
>> I hope that clarifies the approach. Of course if this clashes with what you are currently working on then I will revise it.
>> 
>> Thanks,
>> David
>
>> Hi Patricio,
>> 
>> > Wouldn't it be easier to check some state in JavaThread::send_async_exception() and avoid delivering the ThreadDeath all together when the target is within that Java call in exit()? I don't see anything obvious we can use so we could either add a new enum value in TerminatedTypes or add some new thread member variable.
>> 
>> I specifically wanted this to be a general utility to defer delivery of asynchronous exceptions around a chunk of Java code, so we do not want to stop things upfront in `JavaThread::send_async_exception()`, but only in the back-end when we would actually deliver it. To do this does require a "state bit" somewhere in `JavaThread`, but given where I was trying to stall the delivery it made sense to simply steal another bit from the `SuspendFlags` and augment the `has_async_exception_condition()` check.
>> 
>> I hope that clarifies the approach. Of course if this clashes with what you are currently working on then I will revise it.
>> 
> So for 8283044 I'm actually removing the usage of _suspend_flags for async exceptions and just handle everything with handshakes. We will not be able to defer the processing in check_and_handle_async_exceptions() as in here because that is already inside the handshake and it will complicate things. But it can be done earlier by filtering the handshake queue, like this: https://github.com/pchilano/jdk/commit/d467d96261b9f94ac5315a872b1d009af07fcb14
> If you want to push now I think this patch looks okay. I could just fix that in 8283044. Otherwise we can fix this after 8283044. 
> 
> Thanks,
> Patricio

@pchilano if @dcubed-ojdk  agrees I will proceed with this patch and you can then adapt as you have suggested, as that way this part could be easily backported on its own. Thanks.

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

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