Hotspot loves PHP.reboot

[Rémi Forax]

On 09/07/2011 05:07 AM, Charles Oliver Nutter wrote:
> 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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110907/86d7af2f/attachment.html