RFR (tedious) 8216022: Use #pragma once

[coleen.phillimore at oracle.com]

I'm replying to this message but my reply applies to the one by Dmitry 
and Thomas as well.

Internally at Oracle, many of us like and support the #pragma once 
change.  But as an open source project, we need to consider strongly the 
opinions of all contributors, or at least the ones that have spoken up 
here and are also Reviewers.  Also, we cannot practically verify all the 
different platforms that OpenJDK can be built on, whether supported by 
an organization or not.

Some of the arguments against #pragma once seem like situations that are 
difficult or impossible to observe in our build, and Erik's replies are 
well reasoned.  Even so, I have to think that this discomfort with this 
change is greater than the cut/paste annoyance of creating include 
guards.  Include guards are a defacto industry standard way of solving 
this problem.

This is a practical argument against continuing with this change at this 
time.  Therefore, I'm withdrawing this change.

Thanks,
Coleen

On 1/7/19 4:39 AM, Andrew Haley wrote:
> 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.
>