RFR: 8284632: runtime/Thread/StopAtExit.java possibly leaking memory again

[Daniel D.Daugherty]

On Wed, 27 Apr 2022 21:47:42 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> It appears that adding an `is_exiting()` check to `JavaThread::install_async_exception()`
>> is insufficient. I restored my debug counter code and disabled the two leak fixes in this
>> PR and retested:
>> 
>> 
>> vm_exit: dcubed_async_global_alloc_cnt=936344
>> vm_exit: dcubed_drop_installer_thread_terminated_cnt=113472
>> vm_exit: dcubed_drop_is_exiting_cnt=13
>> vm_exit: dcubed_async_blocked_cnt=67577
>> dcubed_async_global_release_cnt=755282
>> 
>> 
>> dcubed_async_global_alloc_cnt=936344 - dcubed_async_global_release_cnt=755282
>> 181062 // The number of exceptions leaked.
>> 
>> 181062 - dcubed_drop_is_exiting_cnt=13
>> 181049 // The number of leaked exceptions that made it past the is_exiting() check.
>> 
>> 181049 - dcubed_drop_installer_thread_terminated_cnt=113472
>> 67577 // The number of exceptions that made it past the is_exiting() check and
>>            // the is_terminated() check in HandshakeOperation::do_handshake().
>> 
>> 67577 - dcubed_async_blocked_cnt=67577
>> 0   // The number of exception that made it past the cleanup in JavaThread::exit
>
> The clean_async_exception_operation() call in exit() shouldn't be removed, only this is_async_installer() part. Adding the is_exiting() check will take care of preventing any new async exceptions after the clean_async_exception_operation() call.

The target thread sets the `_terminated` field to `_thread_exiting` in
src/hotspot/share/runtime/thread.cpp: JavaThread::exit() AFTER the
creation of the `NoAsyncExceptionDeliveryMark` object that protects
the VM call out to `Thread::exit()`. The dcubed_async_blocked_cnt
counter I mumble about above is counted before the target thread
sets the `_terminated` field to `_thread_exiting` so that's why adding
the new `is_exiting()` check is so ineffective.

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

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