RFR: 8294432: Add provisions to calculate hash values from MemorySegments
Per Minborg
pminborg at openjdk.org
Tue Nov 26 14:03:42 UTC 2024
On Tue, 26 Nov 2024 13:55:10 GMT, Viktor Klang <vklang at openjdk.org> wrote:
>> This PR proposes adding a _JDK-internal_ method for calculating hash codes for content in a `MemorySegment`.
>>
>> The internal method uses a polynomial 32-bit hash function equivalent to `Arrays::hashCode`. The new method is almost two times faster than naïvely iterating over individual bytes for larger regions. Also, it is more lean on inlining space compared to a naïve loop.
>>
>>
>>
>> Benchmark (ELEM_SIZE) Mode Cnt Score Error Units
>> SegmentBulkHash.array 8 avgt 30 2.645 ? 0.078 ns/op
>> SegmentBulkHash.array 64 avgt 30 6.062 ? 0.171 ns/op
>> SegmentBulkHash.heapSegment 8 avgt 30 4.181 ? 0.145 ns/op
>> SegmentBulkHash.heapSegment 64 avgt 30 25.716 ? 1.043 ns/op
>> SegmentBulkHash.nativeSegment 8 avgt 30 3.939 ? 0.150 ns/op
>> SegmentBulkHash.nativeSegment 64 avgt 30 23.262 ? 0.694 ns/op
>> SegmentBulkHash.nativeSegmentJava 8 avgt 30 5.219 ? 0.183 ns/op <- Naïve iteration
>> SegmentBulkHash.nativeSegmentJava 64 avgt 30 39.668 ? 1.040 ns/op <- Naïve iteration
>>
>>
>> 
>>
>>
>> If internal JDK code uses this method, it will automatically benefit from future performance improvements that can be implemented once the Vector API becomes available.
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 208:
>
>> 206: final long limit = fromOffset + longBytes;
>> 207: for (; fromOffset < limit; fromOffset += 8) {
>> 208: long val = SCOPED_MEMORY_ACCESS.getLongUnaligned(segment.sessionImpl(), segment.unsafeGetBase(), segment.unsafeGetOffset() + fromOffset, !Architecture.isLittleEndian());
>
> @minborg Does it help to hoist the calls to `segment.sessionImpl()` + `segment.unsafeGetBase()` + `segment.unsafeGetOffset()` + `!Architecture.isLittleEndian()` and reusing those throughout the different strides?
I thought that initially as well, but keeping it like this helps the compiler select the correct unsafe code path.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22364#discussion_r1858596703
More information about the core-libs-dev
mailing list