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

[Jim Graham]

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