RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES
Claes Redestad
claes.redestad at oracle.com
Fri Mar 15 16:14:31 UTC 2019
Hi Peter,
thanks for reviewing!
Interning arbitrary attribute names might have some unfortunate side-
effects, but a tiny - maybe one or two element - cache might be
sufficient to keep the churn low in practice.
Name and SHA1-Digest are the most commonly repeated non-constant
attribute, generated by the jarsigner tool. Often appearing many times
in a single manifest. I also added SHA-256-Digest because that's what
you'd typically get if you signed a JAR file today.
/Claes
On 2019-03-15 17:07, Peter Levart wrote:
> Hi Claes,
>
> If you have observed memory churn allocating Name objects when reading
> jar files, then perhaps we could do something to the logic of Attributes
> class so that lazily allocated Name(s) would get interned too?
>
> As a separate change of course. This looks good as is.
>
> Regards, Peter
>
> On 3/15/19 2:45 PM, Claes Redestad wrote:
>> Hi,
>>
>> On 2019-03-14 18:20, Claes Redestad wrote:
>>>
>>> On 2019-03-14 18:13, Alan Bateman wrote:
>>>>
>>>> For the current webrev then I'm concerned it is brings back legacy
>>>> attributes. The concept of "installed optional packages" was removed
>>>> in Java SE 9, as was the ability for JAR packaged applets to trigger
>>>> downloading of optional packages. I don't think the later was ever
>>>> implemented in the JDK so surprising that we are finding JAR files
>>>> with those attributes now. If we can prune that down then I think
>>>> the changes will be okay.
>>>
>>> Ok. I stumbled on some new test issues in SA with this patch, so I'll
>>> need to pause this one for a while anyhow.
>>
>> I have a solution to the heap dump issues out for review[1], so I've
>> cleaned up this patch, verified the failing tests pass locally and am
>> running both through tier1-3:
>>
>> http://cr.openjdk.java.net/~redestad/8214712/open.01/
>>
>> Thanks!
>>
>> /Claes
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027455.html
>>
>
More information about the core-libs-dev
mailing list