Fast long overflow detection?

Charles Oliver Nutter headius at headius.com
Tue Feb 7 12:30:58 PST 2012


The JRuby logic mimics what I think others are doing:

    private IRubyObject addFixnum(ThreadContext context, RubyFixnum other) {
        long otherValue = other.value;
        long result = value + otherValue;
        if (additionOverflowed(value, otherValue, result)) {
            return addAsBignum(context, other);
        }
        return newFixnum(context.getRuntime(), result);
    }

    private static boolean additionOverflowed(long original, long
other, long result) {
        return (~(original ^ other) & (original ^ result) & SIGN_BIT) != 0;
    }

JRuby's invokedynamic paths have special casing for a few small fixnum
operations by comparing with Long.MAX_VALUE and MIN_VALUE (e.g. a + 1
overflowed if it's now == Long.MIN_VALUE).

- Charlie

On Tue, Feb 7, 2012 at 7:28 PM, Mark Roos <mroos at roos.com> wrote:
> So I thought I could get away with 64bit ints and not implement the
> Smalltalk automatic conversion
> to BigIntegers.  Bad plan.
>
> So I went ahead and did it while I waited for the super bowl to start.  Not
> too difficult.  Just wrappered
> java BigInteger and added some simple overflow detection.
>
> But I am concerned about the impact on integer ops by adding a pretty
> complex precalc overflow detection.
> To help I decided to limit small ints to 62 bits and defer some checking
> until after the op and cache lookup.
>
> Any suggestions on approaches that offer superior techniques?
>
> Seems like a methodHandle of guardOverflow would be handy someday.
>
> regards
> mark
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


More information about the mlvm-dev mailing list