Cleaning up undefined behaviour in HotSpot

[John Rose]

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.

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

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

— John