<div dir="ltr"><div dir="ltr">Yes, I started looking into this because of a memory regression.<br>While upgrading our project from Java 17 to Java 21, I noticed an increase in memory consumption. After dumping the heap and analyzing the differences, I found that there are a few thousand instances of the class "java.util.jar.Attributes$Name" which all contain the same string which is "SHA-384-Digest".<br>In our case, it was a 2MB increase in a process that uses 35MB normally so that's almost a 5% increase. <br>The issue here is that we are loading multiple jars that each contain a MANIFEST file which contains hundreds of classes and so many times the string "SHA-384-Digest".<br><br>It would be nice if the fix could be backported to java 21 since it's the current LTS that's impacted.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Apr 4, 2025 at 7:07 PM Jaikiran Pai <<a href="mailto:jai.forums2013@gmail.com">jai.forums2013@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The caching of some attribute names in the java.util.jar.Attributes <br>
class appears to have been introduced in <br>
<a href="https://bugs.openjdk.org/browse/JDK-6805750" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-6805750</a> (RFR <br>
<a href="https://mail.openjdk.org/pipermail/core-libs-dev/2018-April/052697.html" rel="noreferrer" target="_blank">https://mail.openjdk.org/pipermail/core-libs-dev/2018-April/052697.html</a>).<br>
<br>
Given the precedence, it may be OK to add "SHA-384-Digest" to that set, <br>
but I don't know how much (if any) would it help with the performance. <br>
Did you happen to notice any performance issues which prompted you to <br>
look at this cache?<br>
<br>
-Jaikiran<br>
<br>
On 04/04/25 10:25 pm, Jaikiran Pai wrote:<br>
> Since this is about caching values in the java.util.jar.Attributes <br>
> class, the discussion is more appropriate in the core-libs-dev mailing <br>
> list. I've added it to the "To" now and "Bcc"ed the jdk-dev mailing <br>
> list. Please subscribe to core-libs-dev <br>
> <a href="https://mail.openjdk.org/mailman/listinfo/core-libs-dev" rel="noreferrer" target="_blank">https://mail.openjdk.org/mailman/listinfo/core-libs-dev</a> if you haven't <br>
> already and we can continue the discussion there.<br>
><br>
> -Jaikiran<br>
><br>
> On 04/04/25 8:54 pm, Ayman wrote:<br>
>> Hello,<br>
>><br>
>> Starting from JDK 19, SHA-384 is replacing SHA-256 as the default <br>
>> digest algorithm in the jarsigner: <br>
>> <a href="https://bugs.openjdk.org/browse/JDK-8283475" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8283475</a><br>
>><br>
>> This means that the string "SHA-384" is now written multiples times <br>
>> is the MANIFEST files, this has been tackled in the past by adding <br>
>> the string "SHA-256" as a KNOWN_NAME that shouldn't be duplicated in <br>
>> memory: <br>
>> <a href="https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/Attributes.java#L729" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/Attributes.java#L729</a> <br>
>><br>
>><br>
>> Is it possible to do the same with "SHA-384"?<br>
>><br>
>> Thanks,<br>
</blockquote></div></div>