Cleaning up undefined behaviour in HotSpot

[Andrew Haley]

On 12/02/16 03:32, John Rose wrote:
> On Feb 11, 2016, at 4:34 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>> I think we need to have a policy that all UB, with the possible
>> exception of a couple of things which can be worked around with
>> compiler switched, gets fixed.
>>
>> Comments, please...
> 
> It's worth study to see how bad things are and what the various
> remedial tactics will cost.  One remedial tactic might be to not
> use compilers that aggressively DTWT for by-the-book UB.

None of the Linux distros can really have that choice: it's something
that's for proprietary binary versions only.  All of us in the OpenJDK
community, proprietary and Open Source, have to use the same sources.
And besides, every C++ compiler is going to bite us all eventually:
using a magic C++ compiler only delays the evil day when we have to
fix this stuff.

> To me it seems possible that this new wave of UB enforcement
> will ultimately be rejected by the C programming community.
> (Of course, I was wrong about XML getting rejected so what
> do I know.)
> 
> That said, I agree with Vladimir, that an anti-UB policy is all
> to the good, and assuming it does not become our new job.

I understand that.  I am thinking of putting together a hit squad to
fix all this stuff.  But I can't do that if I have to fight people at
every turn.  I've seen this in other communities: "Well, I know that
my code is *technically* UB, but I don't want to change it..."

> I have one positive contribution: anti-UB workarounds should be
> encapsulated in macros or inline functions and defined in
> globalDefinitions.hpp (or equivalent).  The HotSpot way is to take
> trick and complex C expression patterns and write them up once,
> correctly, in a header file.  Neither HotSpot maintainers nor
> HotSpot platform compilers have a full grasp of the subtleties of
> the C expression language.  Best practices for C expressions need to
> be communicated in header files, not in admiring comments near
> virtuoso cadenzas of C operators.

I agree up to a point, but it's not always like that, and not always
something you can just wrap up in a macro.  Some HotSpot idioms aren't
really any better or more convenient than non-UB code, they're just
old-fashioned.

> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-Miscellaneous
> 
>> • Use functions from globalDefinitions.hpp when performing bitwise operations on integers.
>> Do not code directly as C operators, unless they are extremely simple.
>> (Examples: round_to, is_power_of_2, exact_log2.)

OK.

Andrew.