RFR(S) 8206183: Possible construct EMPTY_STACK and allocation stack, etc. on first use
zgu at redhat.com
Mon Jul 9 11:45:01 UTC 2018
On 07/09/2018 12:37 AM, David Holmes wrote:
> Hi Zhengyu,
> On 7/07/2018 9:36 PM, Zhengyu Gu wrote:
>> 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?
Thanks for pointing out.
NMT is always initialized while JVM is still in single-thread mode, so I
think it is safe even without language support, or I miss something here?
> 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/
>> hotspot_nmt on Linux 64 (fastdebug and release)
More information about the hotspot-runtime-dev