Martin Buchholz suggested the topic and Mikael signed up to lead the session. Martin gave an introduction. He had observed some issues recently (“impossible null pointer exceptions”) which after investigation turned out to be caused by a toolchain upgrade and in turn revealed the fact that some code in hotspot requires atomicity but does not make this requirement very explicit and in the end assumes that the C++ compiler will produce suitable code to guarantee atomicity. Martin also observed that (on linux) hotspot is compiled targeting the c++98 standard, which is old enough to not even mention the concept of threads. Mikael also added that for extra fun the story is different on different platforms and toolchains.
A quick poll in the room showed no immediate resistance to upgrading to a more recent C++ standard. It was noted that upgrading/changing the target standard is separate from actively starting to use new functionality, and that not all functionality may be well suited for, or even compatible with Java’s memory model. There are caveats with using toolchain intrinsics, C++ atomics, etc. More investigations and discussions are needed to decide on what subset of the C++ functionality to pick up and use.
Andrew Haley noted that the race conditions Martin had observed is an example of the more broad use/reliance on “undefined behavior” which exists in the hotspot code, acknowledging that some things are unlikely to ever change (the use of no-strict-aliasing was mentioned). He polled the room for thoughts on removing/rewriting code relying on undefined behavior, and the poll indicated that people were open to such improvements.
Mikael mentioned that he has done some initial work to make hotspot build successfully with C++14 on linux, mac, and windows (all x64). One change[1] to remove uses of the register storage class specifier was recently pushed to jdk/jdk (jdk12), and a relatively small and so far mostly untested webrev[2] is available which has the changes needed to enable C++14.
It was noted that if new C++ functionality is used in shared code all platforms are affected which in turn requires all relevant toolchains to support the new functionality. For example, the xlc compiler (AIX) does not yet support C++14 (unless this has changed recently?) so maintainers of that port would need to figure out how to move forward.
Finally, Mikael also noted that there is other native code in the JDK (apart from hotspot) for which an upgrade should also be considered.
Cheers,
Mikael
[1] http://hg.openjdk.java.net/jdk/jdk/rev/96ea37459ca7
[2] http://cr.openjdk.java.net/~mikael/webrevs/c++14/webrev.08/open/webrev/
Hi all,
Here are the notes I showed at the "Code Review Tips" session of the Oracle
Committers' Workshop. They might not be intelligible, but they might provoke
some discussion. :-)
s'marks
http://cr.openjdk.java.net/~smarks/ocw2018/CodeReviewTips.html
Hello,
Yesterday I presented a slide deck
http://cr.openjdk.java.net/~darcy/Presentations/ocw-2018-08-01-skara.pdf
and led a discussion about Skara, investigating source code management
options for the JDK sources, on the first day of the OpenJDK Committers’
Workshop. As expected, some developers had passionate opinions about SCM
and tooling choices, including at least one strong voice against using
git, and a larger number of opinions in favor. There was some concern
expressed for changing review procedures as a separate topic from
changing the SCM system.
Cheers,
-Joe