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

[Daniel D.Daugherty]

On Wed, 27 Apr 2022 19:25:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Throwing async exceptions at exiting JavaThreads can leak the exception:
>> 
>> 1) HandshakeOperation::do_handshake() recognizes that the target thread
>>     might be terminated, but needs to do some cleanup when the operation
>>     is one that installs an async exception.
>> 
>> 2) JavaThread::exit() uses a NoAsyncExceptionDeliveryMark to protect the
>>     VM's call out to Thread::exit() from async exceptions, but it needs to do
>>     some cleanup when those async exceptions cannot be delivered because
>>     the target thread has logically exited.
>> 
>> Also tweaked runtime/Thread/StopAtExit.java to alternate between throwing
>> RuntimeException and ThreadDeath. The async exception queuing code accepts
>> any exception, but it recognizes ThreadDeath as special. When a target thread
>> already has a queued async ThreadDeath exception, then another exception will
>> not be queued. So the test now throws RuntimeException on odd iterations and
>> ThreadDeath on even iterations and the target thread will have at most two async
>> exceptions queued up.
>> 
>> This fix has been tested with Mach5 Tier[1-7] (about to start a Tier8) and I also ran
>> my StressWrapper_StopAtExit.java test using {release, fastdebug, and slowdebug}
>> bits for 12 hours per config. No leaks detected. Previously, release bits would
>> fail with OutOfMemoryException in ~2 minutes with StressWrapper_StopAtExit.java.
>
> test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 104:
> 
>> 102:             } else {
>> 103:               myException = new ThreadDeath();
>> 104:             }
> 
> I think this should go in the inner loop if we want to throw different exceptions for the same target.

Thanks for catching this also!

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

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