<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Thank you for reporting this issue and providing the details. I
      have created <a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8353787">https://bugs.openjdk.org/browse/JDK-8353787</a> to track
      this. Any fixes done related to this issue will be first done
      against the mainline JDK and the project members that manage the
      update releases (<a class="moz-txt-link-freetext" href="https://openjdk.org/projects/jdk-updates/">https://openjdk.org/projects/jdk-updates/</a>) will
      then decide if/when this change should be backported.</p>
    <p>-Jaikiran<br>
    </p>
    <div class="moz-cite-prefix">On 04/04/25 11:55 pm, Ayman wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAP8t59pDnmuR3fEFPqA9PPdsCDdA0v2mrLhm3bHSP3Ocdmxopg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
              moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
              class="moz-txt-link-freetext">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" moz-do-not-send="true"
              class="moz-txt-link-freetext">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" moz-do-not-send="true"
              class="moz-txt-link-freetext">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" moz-do-not-send="true"
              class="moz-txt-link-freetext">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" moz-do-not-send="true"
              class="moz-txt-link-freetext">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>
    </blockquote>
  </body>
</html>