Hotspot loves PHP.reboot

[Charles Oliver Nutter]

On Tue, Sep 6, 2011 at 6:10 PM, John Rose <john.r.rose at 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