Using C++11+ in hotspot

[Erik Osterlund]

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 at redhat.com> wrote:
> 
>> On 08/07/2018 06:48 AM, John Rose wrote:
>>> On Aug 6, 2018, at 9:54 PM, Martin Buchholz <martinrb at 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