RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES

[Claes Redestad]

On 2018-12-04 08:42, Alan Bateman wrote:
> On 03/12/2018 16:50, Claes Redestad wrote:
>> :
>>
>> The extra Names added to KNOWN_NAMES was my doing, and it was based 
>> on commonly used attributes in Jar file manifests scanned from a set 
>> commonly used applications as an alternative to building up a Name 
>> cache dynamically (which is frought with other perils). The chose 
>> extras gave a marginal but measurable improvement in startup to a 
>> wide array of applications as a result, and their inclusion is 
>> strictly an internal implementation detail. If you insist on having 
>> them removed I won't object, but I believe it's an harmless 
>> optimization.
> There are several non-standard and tool/library specify attribute name 
> in this list, many should not be interesting to libraries on either 
> the class path or module path. So I think we should look at pruning 
> that list. Ideally it would like just standard and JDK-specific 
> attributes as they are the only attributes that the JDK knows about.

These non-standard and tool/library specific names appear in the 
manifest of a great many jar files, for example on maven central, and 
including the most common non-standard manifest attributes significantly 
reduce allocation churn reading such manifests. Especially true for ones 
that were oft repeated within the same manifest, e.g.,"Name" and 
"SHA1-Digest" for signed entries.

Was it a crucial optimization? Probably not, a few percent on some 
startup applications.

Ideals vs trade-offs... Hard-coding a bunch of arbitrarily chosen 
external values isn't exactly pretty, sure, but I do think the JDK 
should try to optimize for typical behavior, and the fact that many 
(most?) libraries on maven central have OSGi attributes ("Bundle-*") in 
their manifests is one such typical behavior, and this optimization was 
very low cost and net beneficial on most. With 8214712 the overhead cost 
is even less (almost zero in fact).

/Claes