RFR(S) 8206183: Possible construct EMPTY_STACK and allocation stack, etc. on first use

David Holmes david.holmes at oracle.com
Mon Jul 9 04:37:42 UTC 2018

Hi Zhengyu,

On 7/07/2018 9:36 PM, Zhengyu Gu wrote:
> Hi,
> NMT has to workaround static initialization order issues: some of static 
> objects, who allocate memory inside their constructors, may be 
> initialized ahead of NMT, so NMT is forced to initialize itself early 
> and risks its static objects may be reinitialized by C runtime.
> The workaround was to declare storage for the static objects as 
> primitive arrays, then use placement new operator to initialize them, or 
> just initialize them eagerly, if the results are constants.
> But the solution is not elegant, could break with some compilers.
> A better solution is to use "construct on First Use Idiom" pattern 
> (https://isocpp.org/wiki/faq/ctors#static-init-order), cause we only 
> have initialization order problems, those static objects do not have 
> dependencies on other static objects, so we don't suffer from static 
> deinitialization problems.

Okay but this relies on C+11 thread-safe static initialization. That's 
only available in VS2015 and above (which should be okay for JDK 12+). 
What about other compilers? Does it have to be enabled via any 
compilation flags?

I'm currently running this through some additional internal build/tests.


> Bug: https://bugs.openjdk.java.net/browse/JDK-8206183
> Webrev: http://cr.openjdk.java.net/~zgu/8206183/webrev.00/
> Test:
>    hotspot_nmt on Linux 64 (fastdebug and release)
>    Submit-test.
> Thanks,
> -Zhengyu

More information about the hotspot-runtime-dev mailing list