Undefined behaviour in HotSpot

[John Rose]

On Dec 1, 2015, at 8:56 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> Some of the code in C2 which checks for overflow (e.g.
> AddLNode::add_ring) looks very wrong to me.  I am not comfortable that
> an aggressive C++ optimizing compiler will generate the expected code
> for this function.

Good catch.  We may need to replace some normal-looking C++ expressions
on jint (or even "int") with more formal-looking expressions, when the JIT
is performing static evaluation of Java expressions.

A straw man:

// globalDefinitions.hpp
#define jint_add(x, y) jint(juint(x) + juint(y))
#define jint_mul(x, y) jint(jlong(x) * jlong(y))

In some cases, it will be enough just to use an unsigned type instead of a
signed one.  (IIRC, C unsigneds have well-defined overflow.)  But that won't
always work, e.g., with evaluation of Java multiplication.  Maybe we need
an internal JVM API specifically for computing Java bytecode results?
(As opposed to generating code that computes them.)

Thank you very much for poking at this.  Static evaluation of expressions
by the JIT is a long-term source of bugs, and there must be other "clever"
uses of overflow in our source base.  (I'm sure I've coded some.)

— John

P.S.  In case anybody is thinking it:  IMO, it would *not* be good to use
C++ operator overloading to make the static evaluation code look normal.
The special code should have a special look, even if it is uglier than the
normal look.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151201/7ecd473f/attachment-0001.html>