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

Patricio Chilano Mateo pchilanomate at openjdk.java.net
Wed Apr 27 22:07:45 UTC 2022


On Wed, 27 Apr 2022 21:48:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> 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.

I don't understand, was the clean_async_exception_operation() call in JavaThread::exit() removed? The only place where another async exception could have been installed after the call to clean_async_exception_operation()(if not removed) and the change of state to _thread_exiting is in post_thread_end(). So if anything we would need to call it after that. Is your testing calling that jvmti event?

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

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


More information about the hotspot-runtime-dev mailing list