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

David Holmes dholmes at openjdk.java.net
Tue Mar 22 02:27:41 UTC 2022


On Mon, 21 Mar 2022 07:59:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

> To allow Thread::exit to be immune from asynchronous exceptions causing corruption of state we introduce a simple async exception delivery deferral mechanism. Note that we still allow async exceptions to become the "pending async exception" so they are not lost (potentially desirable in other usecases), but we defer the delivery of that exception i.e when it is moved from being the "pending async exception" to being the "current pending exception" (which is the exception actually in the process of being propagated).
> 
> Testing:
>  - runtime/Thread/StopAtExit.java combined with logging and debugging hooks to show that exceptions were being deferred
>  - tiers 1-3
> 
> 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.

Thanks,
David

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

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


More information about the hotspot-runtime-dev mailing list