RFR (tedious) 8216022: Use #pragma once

[Erik Österlund]

Hi Andrew,

On 2019-01-05 18:26, Andrew Haley wrote:
> On 1/5/19 3:03 PM, Erik Österlund wrote:
> 
>> I have asked this before, but does anyone actually know of a
>> compiler/os/filesystem combo that has a #pragma once implementation that
>> gets confused about symbolic links or different include paths, or is
>> this all a hypothetical problem, for a hypothetical
>> compiler+os+filesystem combo that can probably never support e.g. C++17?
> 
> When we were discussing the possibility of using compiler intrinsics
> for atomic operations you used the following hypothetical reason to
> oppose the idea:
> 
>> 2) Even if you could and the compiler happens to generate that - we
>> can not rely on it because there is no contract to the compiler what
>> fence instructions it elects to use. The only contract the compiler
>> needs to abide to is how atomic C++ operations interact with other
>> C++ operations. And we do not want the underlying fencing to
>> silently change when performing compiler upgrades.
> 
> I could surely have replied to this with a question along the lines of
> "Does anyone know of a compiler/processor combo that actually changed
> its atomic operations in a semantically incompatible way?", i.e. used
> exactly the same reasoning as you're using above.
> 
> It's not practically possible for a compiler silently to change
> atomics in the way that you suggested here because it would break
> binary compatibility, but you insisted that because it's
> *hypothetically* possible we shouldn't use such atomic intrinsics.
> 
> Perhaps we should beware of relying on compiler properties that aren't
> standardized and so might silently change when performing compiler
> upgrades, even when such changes are extremely unlikely. I don't think
> so, but I admit it is at least an argument.
> 
> I suggest to you that these two cases are very similar: they're both
> about relying on compiler behaviour that is not standardized.
> 

I see that is a similarity indeed. But there are important differences.

The main difference is that compiler internal ABI for atomics on ARMv7 
and PPC (which was my particular concern in that conversation), a) do 
have incompatible bindings that are allowed by the standard described in 
papers with proposed bindings (as I pointed out then), b) would be 
really dangerous if it subtly changed because it could go undetected for 
a long time before anyone noticed stranged crashes because of it. We 
essentially rely on the generated machine code to have an exact machine 
code binding that is compatible. And for what it's worth, I am okay with 
changing the x64 Atomic/OrderAccess implementation to use compiler 
intrinsics. Because there is essentially no risk due to the nature of 
the ISA.

However, hypothetical differences in whether symbolic references are 
followed or not for #pragma once would lead to HotSpot either building 
or not, depending on whether it relies on that or not (pretty sure it 
doesn't), and never cause bugs to silently infect the binary. 
Conversely, not using #pragma once and relying on all files getting the 
manually typed include guards right, seems more dangerous to me.

So the atomics reliance comes with a risk, the #pragma once reliance 
does not - it removes a risk.

If we truly stop relying on compiler features that are implementation 
defined, when there are no risks involved, we would end up crippled and 
get nothing done.

Thanks,
/Erik