On Thu, 13 Jan 2022 12:26:17 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> When looking at larger benchmarks, I noted a discrepancy between the >> performance of off-heap segments and on-heap segments. Looking at the >> assembly for the `MemorySegment::asSlice` method I could see some additional >> barriers in the off-heap case, but could not initially make sense of them. >> Vlad pointed me at G1 (in fact no such barrier was emitted when using a >> different GC, such as the serial GC, or ZGC), and later Erik narrowed the >> problem down to a failure in a C2 optimization to remove barriers around >> initializing stores. This problem was caused by a synthetic cast added by >> javac to a value (the base object) that initialized the newly created memory >> segment slice. Because of that case, C2 missed the store as an >> "initializing" one, and inserted additional barriers. This patch should make >> performance of on-heap segments a lot more reliable, especially when slicing >> is involved. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Add toplevel javadoc rationale in HeapMemorySegmentImpl Marked as reviewed by psandoz (Reviewer). test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverSlice.java line 71: > 69: scope = ResourceScope.newConfinedScope(); > 70: nativeSegment = MemorySegment.allocateNative(ALLOC_SIZE, scope); > 71: heapSegment = MemorySegment.ofArray(new float[ELEM_SIZE]); The heap `MemorySegment` wraps `float[]` but is accessed as if `int[]`, same bit size, but I suspect it was not intentional? ------------- PR: https://git.openjdk.java.net/jdk18/pull/97
