On Tue, 25 Feb 2025 09:51:08 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> Benchmark results for the latest revision appears performance neutral. >> bytestacks same as last revision. 11 jobs left in tier 1-3, no failure so >> far. Also created CSR for this minor behavioral change. >> >> Benchmark (polluteProfile) >> Mode Cnt Score Error Units >> LoopOverNonConstantHeap.BB_get false >> avgt 30 0.934 ± 0.027 ns/op >> LoopOverNonConstantHeap.BB_get true >> avgt 30 0.946 ± 0.028 ns/op >> LoopOverNonConstantHeap.BB_loop false >> avgt 30 0.208 ± 0.004 ms/op >> LoopOverNonConstantHeap.BB_loop true >> avgt 30 0.211 ± 0.003 ms/op >> LoopOverNonConstantHeap.segment_get false >> avgt 30 1.123 ± 0.040 ns/op >> LoopOverNonConstantHeap.segment_get true >> avgt 30 1.120 ± 0.040 ns/op >> LoopOverNonConstantHeap.segment_loop false >> avgt 30 0.205 ± 0.004 ms/op >> LoopOverNonConstantHeap.segment_loop true >> avgt 30 0.202 ± 0.003 ms/op >> LoopOverNonConstantHeap.segment_loop_instance false >> avgt 30 0.209 ± 0.005 ms/op >> LoopOverNonConstantHeap.segment_loop_instance true >> avgt 30 0.202 ± 0.003 ms/op >> LoopOverNonConstantHeap.segment_loop_instance_unaligned false >> avgt 30 0.209 ± 0.004 ms/op >> LoopOverNonConstantHeap.segment_loop_instance_unaligned true >> avgt 30 0.210 ± 0.004 ms/op >> LoopOverNonConstantHeap.segment_loop_readonly false >> avgt 30 0.206 ± 0.004 ms/op >> LoopOverNonConstantHeap.segment_loop_readonly true >> avgt 30 0.206 ± 0.005 ms/op >> LoopOverNonConstantHeap.segment_loop_slice false >> avgt 30 0.203 ± 0.002 ms/op >> LoopOverNonConstantHeap.segment_loop_slice true >> avgt 30 0.207 ± 0.004 ms/op >> LoopOverNonConstantHeap.segment_loop_unaligned false >> avgt 30 0.206 ± 0.004 ms/op >> LoopOverNonConstantHeap.segment_loop_unaligned true >> avgt 30 0.209 ± 0.003 ms/op >> LoopOverNonConstantHeap.unsafe_get false >> avgt 30 0.386 ± 0.017 ns/op >> LoopOverNonConstantHeap.unsafe_get true >> avgt 30 0.381 ± 0.017 ns/op >> Loo... > > Great work @liach -- I've bumped the number of reviewers as this whole area > is rather tricky, and I think the PR can probably benefit from another > independent pass. Unfortunately no. I don't really know about the Foreign Memory API as I only started to investigate its performance bottlenecks recently. @mcimadamore or @JornVernee were more involved in the development and likely know better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2683776781
