You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/hotspot-style.html
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -68,8 +68,8 @@ <h3 id="why-care-about-style">Why Care About Style?</h3>
68
68
<h3id="counterexamples-and-updates">Counterexamples and Updates</h3>
69
69
<p>Many of the guidelines mentioned here have (sometimes widespread) counterexamples in the HotSpot code base. Finding a counterexample is not sufficient justification for new code to follow the counterexample as a precedent, since readers of your code will rightfully expect your code to follow the greater bulk of precedents documented here.</p>
70
70
<p>Occasionally a guideline mentioned here may be just out of synch with the actual HotSpot code base. If you find that a guideline is consistently contradicted by a large number of counterexamples, please bring it up for discussion and possible change. The architectural rule, of course, is "When in Rome do as the Romans". Sometimes in the suburbs of Rome the rules are a little different; these differences can be pointed out here.</p>
71
-
<p>Proposed changes should be discussed on the <ahref="mailto:hotspot-dev@openjdk.java.net">HotSpot Developers</a> mailing list. Changes are likely to be cautious and incremental, since HotSpot coders have been using these guidelines for years.</p>
72
-
<p>Substantive changes are approved by <ahref="https://www.rfc-editor.org/rfc/rfc7282.html">rough consensus</a> of the <ahref="https://openjdk.java.net/census#hotspot">HotSpot Group</a> Members. The Group Lead determines whether consensus has been reached.</p>
71
+
<p>Proposed changes should be discussed on the <ahref="mailto:hotspot-dev@openjdk.org">HotSpot Developers</a> mailing list. Changes are likely to be cautious and incremental, since HotSpot coders have been using these guidelines for years.</p>
72
+
<p>Substantive changes are approved by <ahref="https://www.rfc-editor.org/rfc/rfc7282.html">rough consensus</a> of the <ahref="https://openjdk.org/census#hotspot">HotSpot Group</a> Members. The Group Lead determines whether consensus has been reached.</p>
73
73
<p>Editorial changes (changes that only affect the description of HotSpot style, not its substance) do not require the full consensus gathering process. The normal HotSpot pull request process may be used for editorial changes, with the additional requirement that the requisite reviewers are also HotSpot Group Members.</p>
74
74
<h2id="structure-and-formatting">Structure and Formatting</h2>
75
75
<h3id="factoring-and-class-design">Factoring and Class Design</h3>
@@ -238,7 +238,7 @@ <h3 id="c-standard-library">C++ Standard Library</h3>
238
238
<p>Some reasons for this include</p>
239
239
<ul>
240
240
<li><p>Exceptions. Perhaps the largest core issue with adopting the use of Standard Library facilities is exceptions. HotSpot does not use exceptions and, for platforms which allow doing so, builds with them turned off. Many Standard Library facilities implicitly or explicitly use exceptions.</p></li>
241
-
<li><p><code>assert</code>. An issue that is quickly encountered is the <code>assert</code> macro name collision (<ahref="https://bugs.openjdk.java.net/browse/JDK-8007770">JDK-8007770</a>). Some mechanism for addressing this would be needed before much of the Standard Library could be used. (Not all Standard Library implementations use assert in header files, but some do.)</p></li>
241
+
<li><p><code>assert</code>. An issue that is quickly encountered is the <code>assert</code> macro name collision (<ahref="https://bugs.openjdk.org/browse/JDK-8007770">JDK-8007770</a>). Some mechanism for addressing this would be needed before much of the Standard Library could be used. (Not all Standard Library implementations use assert in header files, but some do.)</p></li>
242
242
<li><p>Memory allocation. HotSpot requires explicit control over where allocations occur. The C++98/03 <code>std::allocator</code> class is too limited to support our usage. (Changes in more recent Standards may remove this limitation.)</p></li>
243
243
<li><p>Implementation vagaries. Bugs, or simply different implementation choices, can lead to different behaviors among the various Standard Libraries we need to deal with.</p></li>
244
244
<li><p>Inconsistent naming conventions. HotSpot and the C++ Standard use different naming conventions. The coexistence of those different conventions might appear jarring and reduce readability.</p></li>
@@ -272,7 +272,7 @@ <h3 id="enum">enum</h3>
272
272
<p>Due to bugs in certain (very old) compilers, there is widespread use of enums and avoidance of in-class initialization of static integral constant members. Compilers having such bugs are no longer supported. Except where an enum is semantically appropriate, new code should use integral constants.</p>
273
273
<h3id="thread_local">thread_local</h3>
274
274
<p>Avoid use of <code>thread_local</code> (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2659.htm">n2659</a>); and instead, use the HotSpot macro <code>THREAD_LOCAL</code>, for which the initializer must be a constant expression. When <code>thread_local</code> must be used, use the Hotspot macro <code>APPROVED_CPP_THREAD_LOCAL</code> to indicate that the use has been given appropriate consideration.</p>
275
-
<p>As was discussed in the review for <ahref="https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039487.html">JDK-8230877</a>, <code>thread_local</code> allows dynamic initialization and destruction semantics. However, that support requires a run-time penalty for references to non-function-local <code>thread_local</code> variables defined in a different translation unit, even if they don't need dynamic initialization. Dynamic initialization and destruction of non-local <code>thread_local</code> variables also has the same ordering problems as for ordinary non-local variables. So we avoid use of <code>thread_local</code> in general, limiting its use to only those cases where dynamic initialization or destruction are essential. See <ahref="https://bugs.openjdk.java.net/browse/JDK-8282469">JDK-8282469</a> for further discussion.</p>
275
+
<p>As was discussed in the review for <ahref="https://mail.openjdk.org/pipermail/hotspot-dev/2019-September/039487.html">JDK-8230877</a>, <code>thread_local</code> allows dynamic initialization and destruction semantics. However, that support requires a run-time penalty for references to non-function-local <code>thread_local</code> variables defined in a different translation unit, even if they don't need dynamic initialization. Dynamic initialization and destruction of non-local <code>thread_local</code> variables also has the same ordering problems as for ordinary non-local variables. So we avoid use of <code>thread_local</code> in general, limiting its use to only those cases where dynamic initialization or destruction are essential. See <ahref="https://bugs.openjdk.org/browse/JDK-8282469">JDK-8282469</a> for further discussion.</p>
276
276
<h3id="nullptr">nullptr</h3>
277
277
<p>Prefer <code>nullptr</code> (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">n2431</a>) to <code>NULL</code>. Don't use (constexpr or literal) 0 for pointers.</p>
278
278
<p>For historical reasons there are widespread uses of both <code>NULL</code> and of integer 0 as a pointer value.</p>
if test `$STAT -c '%a' "$file_to_test"` -lt 400; then
456
-
AC_MSG_ERROR([Bad file permissions on src files. This is usually caused by cloning the repositories with a non cygwin hg in a directory not created in cygwin.])
456
+
AC_MSG_ERROR([Bad file permissions on src files. This is usually caused by cloning the repositories with non cygwin tools in a directory not created in cygwin.])
0 commit comments