[OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

[Jim Graham]

D'oh, make that ">" instead of "<"... ;)

			...jim

On 4/20/15 1:47 PM, Jim Graham wrote:
> On 4/20/15 1:37 PM, Jim Graham wrote:
>> In the needRoom() methods, there is one more potential overflow path. If
>> the array grows to just under MAX_INT, then "numCoords + newCoords" may
>> overflow to a negative number and the array would not be grown because
>> the test in needRoom() would fail to trigger a call to the grow method.
>> We would still get an AIOOBE in the moveTo/lineTo/etc. routine, but we
>> would insert the new path type into the types array (and increment
>> numTypes) before we overflowed the coords array.  We'd also bump the
>> numCoords by a couple of entries before we hit the true end of the
>> array.  After the exception, we'd leave the path in a bad state where it
>> had a recorded segment type that had no associated data (or partial
>> data) in the coords array.  It would be cleaner to test the "numCoords +
>> newCoords" for overflow in needRoom().  A simple test of the sum being <
>> 0 should do since both numCoords and newCoords should always be positive
>> numbers and all pos+pos overflows always result in negative numbers...
>
> I just realized that an overflow/underflow-proof test for the growth of
> the coords array would be simply:
>
> if (numCoords < coords.length - newCoords) { grow it }
>
> since coords.length is always >= 0 and newCoords is always a small
> non-negative number so there is no overflow or underflow there...
>
>              ...jim