@@ -77,6 +77,9 @@ <h1 class="title">HotSpot Coding Style</h1>
7777< li > < a href ="#thread_local " id ="toc-thread_local "> thread_local</ a > </ li >
7878< li > < a href ="#nullptr " id ="toc-nullptr "> nullptr</ a > </ li >
7979< li > < a href ="#atomic " id ="toc-atomic "> <atomic></ a > </ li >
80+ < li > < a href ="#initializing-variables-with-static-storage-duration "
81+ id ="toc-initializing-variables-with-static-storage-duration "> Initializing
82+ variables with static storage duration</ a > </ li >
8083< li > < a href ="#uniform-initialization "
8184id ="toc-uniform-initialization "> Uniform Initialization</ a > </ li >
8285< li > < a href ="#local-function-objects "
@@ -791,6 +794,33 @@ <h3 id="atomic"><atomic></h3>
791794"conservative" memory ordering, which may differ from (may be stronger
792795than) sequentially consistent. There are algorithms in HotSpot that are
793796believed to rely on that ordering.</ p >
797+ < h3
798+ id ="initializing-variables-with-static-storage-duration "> Initializing
799+ variables with static storage duration</ h3 >
800+ < p > Variables with static storage duration and < em > dynamic
801+ initialization</ em > < a
802+ href ="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf "> C++14
803+ 3.6.2</ a > ). should be avoided, unless an implementation is permitted to
804+ perform the initialization as a static initialization. The order in
805+ which dynamic initializations occur is incompletely specified.
806+ Initialization order problems can be difficult to deal with and lead to
807+ surprises.</ p >
808+ < p > Variables with static storage duration and non-trivial destructors
809+ should be avoided. HotSpot doesn't generally try to cleanup on exit, and
810+ running destructors at exit can lead to problems.</ p >
811+ < p > Some of the approaches used in HotSpot to avoid dynamic
812+ initialization include:</ p >
813+ < ul >
814+ < li > < p > Use the < code > Deferred<T></ code > class template. Add a call
815+ to its initialization function at an appropriate place during VM
816+ initialization. The underlying object is never destroyed.</ p > </ li >
817+ < li > < p > For objects of class type, use a variable whose value is a
818+ pointer to the class, initialized to < code > nullptr</ code > . Provide an
819+ initialization function that sets the variable to a dynamically
820+ allocated object. Add a call to that function at an appropriate place
821+ during VM initialization. Such objects are usually never
822+ destroyed.</ p > </ li >
823+ </ ul >
794824< h3 id ="uniform-initialization "> Uniform Initialization</ h3 >
795825< p > The use of < em > uniform initialization</ em > (< a
796826href ="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm "> n2672</ a > ),
@@ -1198,12 +1228,6 @@ <h3 id="excluded-features">Excluded Features</h3>
11981228href ="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html "> n2179</ a > )
11991229— HotSpot does not permit the use of exceptions, so this feature isn't
12001230useful.</ p > </ li >
1201- < li > < p > Avoid non-local variables with non-constexpr initialization. In
1202- particular, avoid variables with types requiring non-trivial
1203- initialization or destruction. Initialization order problems can be
1204- difficult to deal with and lead to surprises, as can destruction
1205- ordering. HotSpot doesn't generally try to cleanup on exit, and running
1206- destructors at exit can also lead to problems.</ p > </ li >
12071231< li > < p > Avoid most operator overloading, preferring named functions. When
12081232operator overloading is used, ensure the semantics conform to the normal
12091233expected behavior of the operation.</ p > </ li >
0 commit comments