RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES

[Peter Levart]

On 3/15/19 5:14 PM, Claes Redestad wrote:
> Hi Peter,
>
> thanks for reviewing!
>
> Interning arbitrary attribute names might have some unfortunate side-
> effects, 

You mean if the number of different names would get larger and larger on 
a long-running JVM, the cache would grow without bounds?

I noticed that the Name constructor:

         public Name(String name) {
             this.hashCode = hash(name);
             this.name = name.intern();
         }

...interns the String name. Do interned strings have a weak cache or are 
they kept for the entire life of JVM?

Regards, Peter

> 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 
>>>
>>