RFR(S): 8033405 - metaspace/stressHierarchy/stressHierarchy005 hangs in atexit handler
david.holmes at oracle.com
Thu Apr 24 10:29:26 UTC 2014
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.
> 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
> 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
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.
> -----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.
>> 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.
More information about the hotspot-runtime-dev