<div dir="ltr">Indeed, this is a good proposal to reduce unnecessary allocation, especially if the executing thread does not share the array with another thread.<div>FYI for String, I believe the no-low-allocation was mainly due to that Strings may have extended lifespan, and it's not feasible for a small substring to hold a long string (such as a substring in a whole file) not reclaimable by GC.<br><div>After checking the PR <a href="https://github.com/openjdk/jdk/pull/24128">https://github.com/openjdk/jdk/pull/24128</a>, I think there is value in providing an initial hash base (as the internal version) for things like views that source from multiple arrays.</div><div><br></div><div>Chen</div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Mar 17, 2025 at 1:42 PM Roger Riggs <<a href="mailto:roger.riggs@oracle.com">roger.riggs@oracle.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"><u></u>

  
  <div>
    Hi,<br>
    <br>
    It seems like a reasonable API enhancement, the implementation
    already supports sub-ranges.<br>
    <br>
    Created <a href="https://bugs.openjdk.org/browse/JDK-8352171" id="m_2976203129759002068key-val" rel="5153081" target="_blank">JDK-8352171</a> Arrays.hashCode for sub-range of
    byte array API addition<br>
    <br>
    Regards, Roger<span role="button" aria-label="Arrays.hashCode for sub-range of byte array API addition: Edit Summary"></span><br>
    <br>
    <div>On 1/31/25 6:45 AM, Matthew Swift
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hello experts,
        <div><br>
        </div>
        <div>Firstly, please let me know where to post this question if
          it is an inappropriate question for this mailing list.</div>
        <div><br>
        </div>
        <div>The java.util.Arrays utility class currently exposes pairs
          of methods for comparing arrays of primitives and objects, for
          example:</div>
        <div><br>
        </div>
        <div>    java.util.Arrays#equals(byte[], byte[])</div>
        <div>    java.util.Arrays#equals(byte[], int, int, byte[], int,
          int)</div>
        <div><br>
        </div>
        <div>However, only a single method is provided for the
          equivalent hashCode() methods:</div>
        <div><br>
        </div>
        <div>    java.util.Arrays#hashCode(byte[])</div>
        <div><br>
        </div>
        <div>Specifically, the offset+length versions are not present,
          despite there being support
          in jdk.internal.util.ArraysSupport. Given the ubiquity of
          equals + hashCode, I would expect there to be symmetry between
          the equals and hashCode APIs in Arrays. The lack of support
          means that applications cannot take advantage of intrinsics.</div>
        <div><br>
        </div>
        <div>The use-case we have is parsing byte[] network protocol
          packets into their components, which are represented using
          objects containing offset+length pointers into the original
          packet. These components are frequently stored in hash sets
          and maps. More precisely, we are parsing ASN.1 BER packets, so
          our use-case is remarkably similar to
          JDK's sun.security.util.DerValue#hashCode, but could be
          applied equally to other network protocols.</div>
        <div><br>
        </div>
        <div>I know that the String class stopped using the
          offset+length low-allocation design some time ago, so perhaps
          the design I'm describing above is no longer best-practice
          thanks to JVM advancements, and hence there should be no need
          for offset+length Arrays#hashCode - but that doesn't explain
          the asymmetry with Arrays#equals.</div>
        <div><br>
        </div>
        <div>Thanks in advance,</div>
        <div>Matt</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div>