RFR: 8145096: Undefined behaviour in HotSpot

[Andrew Haley]

On 12/10/2015 09:44 PM, Kim Barrett wrote:
> To me, this seems to be trading one form of undefined behavior for
> another.  Since there *is* a portable solution, which I understand is
> also well supported / optimized by compilers, I'd prefer that.

OK.  I'm not convinced that a memcpy is into a signed int is really
more perfectly portable than a union, but I'm certain it will work for
the machines we care about.  I'm not going to argue about it if that's
what you prefer: I just want the bugs to be fixed!

> Note that I would not like to see these java_xxx functions used as a
> general "solution" to overflow problems.  Most cases of signed integer
> arithmetic overflow are actual bugs, and papering over them with these
> functions would be a mistake.  I haven't reviewed them carefully, but
> the way these are being used in the various changes in the opto
> directory look appropriate, in order to match Java's defined behavior.
> But I wouldn't be surprised if there were other places (like the
> problem found in advancedThresholdPolicy.cpp) where I would not want
> these operations used.  In fact, I'd like the comment describing these
> operations to say something along that line.

Okay, I'll do that.  For the hash index computation it might make more
sense to do the whole thing unsigned.

Andrew.