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

[David Holmes]

On 9/07/2018 9:45 PM, Zhengyu Gu wrote:
> Hi David,
> 
> On 07/09/2018 12:37 AM, David Holmes wrote:
>> 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?
> 
> 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?

Okay - that sounds alright then.

Thanks,
David

> -Zhengyu
> 
> 
>>
>> I'm currently running this through some additional internal build/tests.
>>
>> Thanks,
>> David
>> -----
>>
>>>
>>> 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