RFR(S): 8033405 - metaspace/stressHierarchy/stressHierarchy005 hangs in atexit handler

[David Holmes]

Hi Christian,

On 24/04/2014 8:00 PM, Christian Tornqvist wrote:
> Hi David,
>
>> The real fix is to get rid of those non-trivial static destructors!
>
> Someone can battle this out with the GC team (and any other team with static
> destructors), this was our first suggestion but nothing happened.

This is something the VM lead(s) should address.

People
> have spent man-weeks debugging the deadlocks caused by this issue. As I
> wrote in my email, this is merely a workaround to get rid of this
> hard-to-diagnose and time consuming deadlock issue until Zhengyu can push
> his re-worked NMT implementation where this won't be a problem anymore.
>
>> That aside when exactly in the VM termination process will DllMain be
> called?
> DllMain gets called before the CRT starts calling the static destructors.
>
>> How can we be sure that there is sufficient VM state still valid to perform
> the NMT shutdown?
> The only thing the MemTracker::shutdown() does is change the NMT state to
> NMT_shutdown_pending. Even though nothing else is alive at this point we're
> merely changing some fields and the DLL is still loaded, otherwise we
> wouldn't be in DllMain.

Okay - I hadn't checked what it actually did and assumed it was more 
substantial.

I'm very wary of adding any VM related unload code; particularly when 
the whole problem is already caused by an at_exit handler.

Thanks for clarifying.

David

> Thanks,
> Christian
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Thursday, April 24, 2014 4:29 AM
> To: Christian Tornqvist; 'hotspot-runtime-dev'
> Subject: Re: RFR(S): 8033405 - metaspace/stressHierarchy/stressHierarchy005
> hangs in atexit handler
>
> Hi Christian,
>
> On 24/04/2014 1:18 AM, Christian Tornqvist wrote:
>> Hi everyone,
>>
>> This is a small fix for an issue on Windows where NMT tries to track a
>> free from a static destructor and ends up hanging on acquiring the
>> ThreadCritical lock. The fix is to make sure we shut down NMT before
>> the VM exits and then to not track malloc/free when NMT is shutting down.
>
> The real fix is to get rid of those non-trivial static destructors!
>
> That aside when exactly in the VM termination process will DllMain be
> called? How can we be sure that there is sufficient VM state still valid to
> perform the NMT shutdown? The detach hook should only be doing very simple
> resource cleanup - I'm not sure this qualifies.
>
> David
>
>> Zhengyu is working on a rewrite of the NMT feature where this won't be
>> an issue, so this is a temporary workaround until then.
>>
>> Tested on Windows x64 using vm.quick and Hotspot jtreg tests.
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~ctornqvi/webrev/8033405/webrev.00/
>>
>> Bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8033405
>>
>> Thanks,
>>
>> Christian
>>
>