RFR (tedious) 8216022: Use #pragma once

[Andrew Haley]

On 1/5/19 7:24 PM, Erik Österlund wrote:
> 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.

There are two possibilities: either it'd happen by accident or
deliberately. By accident is just a code generation bug, no different
from any other, and of course we're always at risk from those.
Deliberately would require a lot of dicussion because it'd break
binary compatibility. So I don't believe it.

But that doesn't matter, I'm satisfied: purely hypothetical but
implausible arguments abut what compilers might do with less than
fully standardized features are off the table.

> 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.

OK, so the argument is not hypothetical at all, but purely practical.

> 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.

Yes. We should use the compiler to help us as much as possible, reduce
our code complexity, and reduce our maintenance costs.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671