RFR (tedious) 8216022: Use #pragma once

[David Lloyd]

If there was some way to push for and achieve "#pragma once" inclusion
in the upstream C/C++ standards, I think that would change the
arguments substantially.

On Wed, Jan 9, 2019 at 11:03 AM <coleen.phillimore at oracle.com> wrote:
>
>
> 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.
> >
>


-- 
- DML