Hi, some users reports high allocation rates in ParseUtil.encodePath, regardless of whether paths actually need to be encoded or not. Since this is a commonly used utility it makes sense.
Webrev: http://cr.openjdk.java.net/~redestad/8170785/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8170785 This patch provides a semantically neutral fast-path for cases when the path does not need to be encoded (up to 5x speedup), reduces allocation when the string has a prefix that does not need to be encoded (1-2x speedup) and no regression when using a separator that's not '/' or the first char needs encoding. Interpreted performance is not affected much either: small positive when no encoding is needed, neutral or negligible regression otherwise. Thanks! /Claes