RFR: 6805750: Improve handling of Attributes.Name

Claes Redestad claes.redestad at oracle.com
Fri Apr 20 14:07:58 UTC 2018


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 

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.



[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

More information about the core-libs-dev mailing list