On 09/07/2011 05:07 AM, Charles Oliver Nutter wrote:
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.
The other solution is to do the strict opposite,
to use an exception that have a private constructor
so it can't be created by a user code and have no stacktrace, etc
(see
http://download.oracle.com/javase/7/docs/api/java/lang/Throwable.html#Throwable%28java.lang.String,%20java.lang.Throwable,%20boolean,%20boolean%29)
so the VM knows that only methods *DetectingOverflow are able to throw
that specific exception.
int addDetectingOverflow(int x, int y) throws IntegerOverflowException
This also have the advantage that the inlining heuristic can be tweaked
to not count exception handlers that receive that specific exception.
Rémi
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
