Ok, I will update soon the patch to fix both the overflow in needRoom methods and remove trimToSize () methods to be jdk8 compliant.
PS: these new methods could be added later for jdk9 only Laurent Le 21 avr. 2015 19:56, "Jim Graham" <james.gra...@oracle.com> a écrit : > > Then it might make sense to make a new bug and target the existing patch at it by just removing the new method signature... > > ...jim > > > On 4/20/15 11:56 PM, Laurent Bourgès wrote: >> >> Jim & phil, >> >> The initial objective of my patch concerns the grow algorithm to use >> 1/8th of the array size instead of the fixed EXPAND_MAX (=500) ! >> >> For huge paths, it avoids a lot of growing passes and is a lot faster >> (see Path2DGrow test: 2s vs 56s). >> >> However, it wastes more memory (overflow or OOME can occur) so arrays >> should be trimmed manually or automatically when calling some methods >> like getPathIterator (). >> It is not possible to infer what is the Path2D usage pattern... and when >> a growable array should be resized down (too much waste threshold ?) >> >> I think the bug you created does not mention the problem on the grow >> algorithm at all. That fix could be backported to 1.8 except new >> trimToSize () methods. >> >> Le 21 avr. 2015 00:11, "Jim Graham" <james.gra...@oracle.com >> <mailto:james.gra...@oracle.com>> a écrit : >> >>> >>> To answer my own question - since we already have a changeset with just the new trim-on-copy stuff that is backwards compatible and since this change only adds the new trim method and some overflow protection, we can just go with the previous fix if we decide to backport things. The added value of the new overflow protection is not enough to further split this particular change down... >> >> >> I disagree: the new grow algorithm is a lot better for huge paths and is >> an important performance fix that should be backported to 1.8 too. >> >> Should I update the bug description or create a new one like 'Path2d >> needRoom very slow for huge paths' ? >> >> Laurent >>
