On Tue, Sep 6, 2011 at 6:10 PM, John Rose <john.r.r...@oracle.com> wrote: > Yes. Your request for "JO" makes me think some users would be happy with a > boolean test, a la addWouldOverflow. > It's what happens after the test that differs widely among applications, so > why not just standardize the test. > if (addWouldOverflow(p, q)) { throw or return BigInt or ... } > return new Integer(p + q); > The p+q, if it occurs within addWouldOverflow(p, q), will value-number to > the explicit p+q, allowing the expected assembly code which computes p+q and > then checks the overflow bit. > (Actually, it's likely that the "addl p',q" instruction would occur twice, > because hotspot not very good at tracking condition codes.)
That was my immediate concern. JO will act based on the last operation, so we wouldn't duplicate any work. Of course, at the level of multiple addl's it may be a small price to pay for a less code-order-sensitive option like addWouldOverflow. Thinking about how you'd JIT with such intrinsics made me realize the best case is still the full-on "addDetectingOverflow" since it could emit the add and jo operations all together in the proper order. Anything that depends on the bytecode ordering (iadd followed by this intrinsic call) would be tweaky, and then there's the simple fact that in the *absence* of JIT there's no real way to do "didAddOverflow" without passing everything in again like we do in JRuby now. Perhaps no gain in that case. Only the full "addDetectingOverflow" could reliable do the add and jo in precisely the correct order, figuring in any other register effects. > That's true, except that exceptions tend to be imprecise: It's hard to tell > which sub-expression cause the exception, out of a complex statement. > Addressing both the precision and pre-allocation problems, you could ask the > application to create the exception: > public static <X extends Throwable> > int addDetectingOverflow(int x, int y, X onOverflow) throws X This is pretty good, though it's another unusual precedent for JDK (or at least I know of no APIs that have this form). Still, it might be the lightest-weight option, since it allows you to opt completely out of all allocation. I also thought of an existing API that would benefit from this, and perhaps there's a path to getting something in JDK 7 (unofficially) and JDK 8 (officially): BigInteger. Ideally BigInteger should only use a primitive long (or int?) up to its limits, and not allocate an array until it exceeds those limits. Such an implementation would need to do the same overflow checks JRuby does, and could benefit from addDetectingOverflow. And we know there's constant cries for BigInteger and BigDecimal perf to be improved...so I'd say every bit helps. - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev