Thanks for reporting. There’s a known issue that will likely fix this problem: https://bugs.openjdk.org/browse/JDK-8251971
I’ve linked to this mail in the bug report. (FWIW, null-restricted storage is not a supported feature of this release, so performance work in that area may not be prioritized. But I believe that issue will be addressed during the 28 development cycle.) > On Aug 11, 2026, at 1:53 AM, Ivan Ponomarev <[email protected]> wrote: > > Hi Valhalla folks, > > I've been experimenting with |28-ea+10-569|on Windows x86-64 and noticed > surprising |System.arraycopy|performance on null-restricted flat value arrays. > > The element type is: > > |value record Node(int link, Object value) {}| > > For both atomic and |@LooselyConsistentValue|flat arrays, > |System.arraycopy|is consistently about 8–20x slower than a simple: > > |for (int i = 0; i < n; i++) dst[i] = src[i];| > > over the same arrays. > > As a control, the same benchmark on |Object[]|shows the opposite result: > |System.arraycopy|is substantially faster than the manual loop. > > I ran the benchmark twice independently and got the same overall result. For > example, the |arraycopy / loop|ratios were (first..second run; >1 means > |System.arraycopy|is slower than a for (...) loop): > > |1K 16K 256K flat atomic 8.82..10.28 12.04..8.60 15.47..11.50 flat loose > 17.90..18.27 19.48..18.57 11.66..12.14 Object[] 0.06..0.05 0.11..0.11 > 0.25..0.31| > > The benchmark asserts that the value arrays are actually flat and primes the > measured helpers before measurement to make sure C2 compilation has happened. > > I've attached the self-contained JMH reproducer, a vibe-written report, and > raw output from both runs. > > Is this expected at the current stage of Valhalla, or would it be useful to > file an issue? > > Thanks, > Ivan > > <FlatArrayCopyBenchmark.java><raw-results-run1.txt><raw-results-run2.txt><REPORT.md>
