RFR: 6805750: Improve handling of Attributes.Name

Xueming Shen xueming.shen at oracle.com
Fri Apr 20 17:41:12 UTC 2018


It loogsk good.

One minor nit is that the "hashCode" check in Name.equals() might not be really
necessary, given in most/normal use scenario the "Name" is used as a key in
Attributes.map, which is a LinkedHashMap. Arguably the hashcode should be
check already during lookup.

Agreed what you suggested in previously email regarding equalsIgnoreCase vs
CASE_INSENSITIVE_ORDER. It appears equalsIgnoreCase() at least can take
advantage of "intern()" and "length()" match.


On 04/20/2018 07:07 AM, Claes Redestad wrote:
> Hi,
> please review this patch to address some of the legacy performance concerns arising when dealing
> extensively with java.util.jar.Attributes.Name (mainly when parsing jar
> Webrev: http://cr.openjdk.java.net/~redestad/6805750/open.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-6805750
> While also picking up a few of the micro-optimizations suggested (eagerly calculate the hashCode
> since it will always be used), the main approach is to set up a small map of commonly used manifest
> attributes, including but not limited to (non-deprecated) ones declared as constants of Attributes.Name.
> For known strings, this can see speed-ups of ~10x of Attributes.putValue(String, String) and 25x on
> Attributes.get(String), while reducing the footprint of typical Manifest objects[1].
> I've also done a few experiments with a concurrent and dynamic backing storage[2][3], each of which
> have some elegant properties (mainly getting similar benefits on arbitrary attributes), but adding too
> much complexity to improve performance of uncommon attributes while slightly reducing the efficiency
> for common ones doesn't really seem worthwhile.
> Thanks!
> /Claes
> [1] http://cr.openjdk.java.net/~redestad/6805750/Attributes.java
> [2] http://cr.openjdk.java.net/~redestad/6805750/open.00/ -- reuse
> MethodType$ConcurrentWeakInternSet. Nice to reuse some code, but only gets a 2.5x improvement
> since we can't avoid allocation.
> [3] http://cr.openjdk.java.net/~redestad/6805750/open.01/ -- create a custom interning map from
> String to WeakEntry<Name>: ~15x get and ~8x putValue perf for any repeatedly used attribute
> name.

More information about the core-libs-dev mailing list