RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES
Claes Redestad
claes.redestad at oracle.com
Tue Dec 4 08:32:12 UTC 2018
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
More information about the core-libs-dev
mailing list