Hi Andrew, This question is very important and deserves highlighting. I have been thinking for some time that there ought to be a document describing ”allowed C++ sins in HotSpot”. And I would put aliasing rules at the top of said document. Today we rely on compilers being tamed not to be tempted to exploit aliasing rules (e.g. -fno-strict-aliasing). The reliance on this in our code base goes so deep that we will arguably never be able to stop relying on it. And why would we want to, more than to find more interesting ways of tormenting ourselves? This is something we should embrace. By embracing this and putting it in a document that this is allowed, we would have the following benefits: 1) All reoccuring discussions whether we should or should not care about aliasing would come to quick ends, and decisions would not have to be taken (inconsistently) over and over again on a case by case basis. 2) Porters would know what requirements HotSpot has on compiler taming to safely run HotSpot. If they can not tame the compiler to ignore aliasing rules, then they can not use HotSpot. 3) By embracing aliasing violations as an allowed C++ sin, time will be saved for everyone involved, not having to invent complicated solutions circumventing it. Spending time honoring these rules seems like a waste of time and resources unless we fully commit to removing all such behaviour and hence can flip the compiler switches and hence remove our reliance on this. And we will never be able to do that. Nor should we if we could. 4) It seems like the problem being discussed in this thread before I hijacked it would have simple solutions. So basically, my answer to your question is: no we do not and should not care. And that message ought to be documented somewhere to remove all uncertainty and inconsistency around that reoccuring question. Thanks, /Erik
On 7 Aug 2018, at 16:00, Andrew Haley <aph@redhat.com> wrote:
On 08/07/2018 06:48 AM, John Rose wrote:
On Aug 6, 2018, at 9:54 PM, Martin Buchholz <martinrb@google.com> wrote:
I don't know what is actually being copied here, but can't the underlying type be atomic<address*> ?
Yes, if we are allowed to cast some random sequence of metadata words to atomic<address*>[].
We're not. Well, we sort-of are because we use -fno-strict-aliasing, but that's not standard C++11. Do we care? :-)
GCC builtins do what we need when we're using GCC, but then we don't need C++11.
-- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
I agree getting to a hotspot without C++ undefined behavior is very hard. Organizations like Google like to have control over all their software, including the toolchain, and want both high performance and standards compliance, enforced via tools like ubsan https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html. Full employment for engineers like me who try to bridge the 2 worlds. I'd like to see hotspot stop using the -fno-strict-aliasing curtch, replacing it with union and/or may_alias, but this is a serious investment. Here are my type-punning notes: #---------------------------------------------------------------- # -fstrict-aliasing, union, memcpy, C99, C++. #---------------------------------------------------------------- https://blog.regehr.org/archives/959 http://dbp-consulting.com/tutorials/StrictAliasing.html C99 allows type punning via members of a union, and all known C++ compilers allow it, but strictly speaking not permitted by the C++ standard. 85. If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called type punning). This might be a trap representation. Doing type punning via memcpy really goes against low-level programmer instinct - we really have to trust the compiler to optimize away the memcpy library call! gcc (what about clang?) has the may_alias attribute https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html
participants (2)
-
Erik Osterlund
-
Martin Buchholz