Bug in Long.parseUnsignedLong

Dmitry Nadezhin dmitry.nadezhin at gmail.com
Sat Dec 21 10:04:58 UTC 2013


I can weaken the question:
Is there a reason to prefer extra int multiplication to the cache ?

long result = first * radix + second;
final int GUARD_BIT = 7;
int guard = radix * (int) (first >>> (Long.SIZE - GUARD_BIT));
if (guard >= (1 << GUARD_BIT) - Character.MAX_RADIX
     && (guard >= (1 << GUARD_BIT) || result >= 0)) {
  . . .


On Fri, Dec 20, 2013 at 10:48 PM, Louis Wasserman <lowasser at google.com>wrote:

> @Paul Sandoz: Is there a particular reason you prefer an extra division to
> the cache?
>
>
> On Fri, Dec 20, 2013 at 8:54 AM, Dmitry Nadezhin <
> dmitry.nadezhin at gmail.com> wrote:
>
>> What is performance of Long.compareUnsigned(x, y) ?
>> Does HotSpot implement it as a call of Long.compare(x + MIN_VALUE, y +
>> MIN_VALUE) or as a single machine instruction ?
>>
>>
>>
>> On Fri, Dec 20, 2013 at 7:53 PM, Paul Sandoz <paul.sandoz at oracle.com>
>> wrote:
>>
>> > Hi Brian,
>> >
>> > It would be nice to avoid the caches, on a hunch i am wondering if the
>> > following will work:
>> >
>> >   long result = first * radix + second;
>> >   if ((first >>> 1) > (Long.MAX_VALUE / radix) ||  // possible overflow
>> of
>> > first * radix
>> >     Long.compareUnsigned(result, first) < 0) {  // overflow of  first *
>> > radix + second
>> >
>> > It should be possible to write some tests creating strings in the
>> > appropriate base to select the appropriate value for first will kick
>> off an
>> > overflow.
>> >
>> > Paul.
>> >
>> > On Dec 19, 2013, at 9:21 PM, Brian Burkhalter <
>> brian.burkhalter at oracle.com>
>> > wrote:
>> >
>> > > Here's a formalization of the suggested fix:
>> > >
>> > > http://cr.openjdk.java.net/~bpb/8030814/webrev/
>> > >
>> > > It works against the test case.
>> > >
>> > > Brian
>> > >
>> > > On Dec 19, 2013, at 11:26 AM, Brian Burkhalter wrote:
>> > >
>> > >> Upon inspection only that indeed looks correct.
>> > >>
>> > >> Thanks …
>> > >>
>> > >> On Dec 19, 2013, at 10:28 AM, Louis Wasserman wrote:
>> > >>
>> > >>> Here's one approach that works: there is overflow iff
>> > >>>
>> > >>> compareUnsigned(first, divideUnsigned(MAX_UNSIGNED, radix)) > 0 ||
>> > (first == divideUnsigned(MAX_UNSIGNED, radix) && second >
>> > remainderUnsigned(MAX_UNSIGNED, radix));
>> > >>>
>> > >>> Since radix <= Character.MAX_RADIX, you can precompute the divides
>> and
>> > remainders in a small table.
>> > >>
>> > >
>> >
>> >
>>
>
>
>
> --
> Louis Wasserman
>



More information about the core-libs-dev mailing list