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

[Christian Tornqvist]

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

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
>