[OpenJDK Rasterizer] Path2d needRoom very slow for huge paths

[Phil Race]

pisces was originally written for the "ME" environment so I suspect that
it was very conservative in allocating new heap space. That clearly does not
matter so much on desktop so the proportional approach rather than
the fixed size approach seems better. 1/8th seems conservative and
since the results look good so I don't object.

I think a new bug id would be required as this is another thing that
might be backported to pisces in 8u60.

A performance test to verify it would be good but a jtreg type pass/fail
on performance tests can be a challenge to make 100% reliable.

-phil.

On 4/2/2015 9:10 AM, Laurent Bourgès wrote:
> Hi again,
>
> I quickly tested the proposed solution:
>
>         void needRoom(boolean needMove, int newCoords) {
>             if (needMove && numTypes == 0) {
>                 throw new IllegalPathStateException("missing initial 
> moveto "+
>                                                     "in path definition");
>             }
>             int size = pointTypes.length;
>             if (numTypes >= size) {
>                 int grow = size;
>                 if (grow > EXPAND_MAX) {
> *                    grow = Math.max(EXPAND_MAX, size >> 3); // 1/8th min
> *                } else if (grow == 0) {
>                     grow = 1;
>                 }
>                 pointTypes = Arrays.copyOf(pointTypes, size+grow);
>             }
>             size = floatCoords.length;
>             if (numCoords + newCoords > size) {
>                 int grow = size;
>                 if (grow > EXPAND_MAX * 2) {
> *                    grow = Math.max(EXPAND_MAX * 2, size >> 3); // 
> 1/8th min
> *                }
>                 if (grow < newCoords) {
>                     grow = newCoords;
>                 }
> *System.out.println("floatCoords["+System.currentTimeMillis()+"]: 
> grow=" + (size+grow));
> *                floatCoords = Arrays.copyOf(floatCoords, size+grow);
>             }
>         }
>
> Before changing the grow parameter (only log):
> *10025 resizes:*
> floatCoords[1427989723142]: grow=9192
> floatCoords[1427989723142]: grow=10192
> floatCoords[1427989723143]: grow=11192
> floatCoords[1427989723143]: grow=12192
> ...
> floatCoords[1427989775916]: grow=10030192
> floatCoords[1427989775925]: grow=10031192
> floatCoords[1427989775933]: grow=10032192
> floatCoords[1427989775942]: grow=10033192
> *duration[spiralTest-dash-false.ser] = 54729.927044 ms.*
>
> After modifying the grow parameter to be at least 1/8th the array size:
> *61 resizes:*
> floatCoords[1427990208647]: grow=9216
> floatCoords[1427990208647]: grow=10368
> floatCoords[1427990208647]: grow=11664
> floatCoords[1427990208647]: grow=13122
> ...
> floatCoords[1427990209097]: grow=7587943
> floatCoords[1427990209142]: grow=8536435
> floatCoords[1427990209163]: grow=9603489
> floatCoords[1427990209187]: grow=10803925
> *duration[spiralTest-dash-false.ser] = 2373.493056 ms.*
>
>
> What do you think ?
>
> Does it worth a new bug ?
> Do you need my Spiral test code ?
>
> Laurent
>