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


Reply via email to