bench(spike): Phase-2 TensorView/Storage access-path spike — JMH benchmarks, flat-RSS loop, report (SKEEP-003 decision #6, S1.0)

[michalharakal]

Summary

SKEEP-003 slice S1.0 (milestone M1 #1002, decision #6, #1016): the Phase-2 access-path spike — what does a TensorView layer between a kernel and its bytes cost on the JVM? Report: docs/design/memory/spike-p2-access-path-2026-08-23.md; benchmarks kept reproducible in the JMH module (sk.ainet.bench.spike, run with -PjmhIncludes='spike.*' and runFlatRssSpike).

Verdict: go for Phase 2, with the access-path rule written into the M1 slices — kernels take TensorViews and unwrap once per call (asHeapArray() / segment()); decoding get() is the reference path only; JVM Scope.Forward defaults to heap slabs; vector kernels keep explicit offsets.

Numbers (i7-9750H, JDK 25, JMH fork 1 / 3 warmup / 5 it):

• GEMV 256×1024: view over heap, unwrap once +1 % · heap get per element 0 % · off-heap unwrap +3 % · off-heap get +4 % — within budget.
• Elementwise add 1 M: raw 286 µs · raw with loop-invariant offsets (control, no view) 539 µs · view-heap unwrap 567 ± 182 · view-heap get 516 · view-segment unwrap 495 · view-segment get 1579. The 1.9× on the vectorizable loop comes from C2 not auto-vectorizing the offset form, not from the view (view-unwrap ≈ raw-offset). SKaiNET's vector kernels take offsets explicitly, so the ≤ 3 % elementwise budget is re-checked on them at S1.4 / S1.7 against the baseline.
• Off-heap: scalar MemorySegment.getAtIndex loops are 1.7–5.5× slower than arrays → activations stay on the heap by default on the JVM; mapped/off-heap weights are fine (already consumed by ByteVector.fromMemorySegment).
• Flat RSS (3 000 decode-shaped steps, -Xmx256m): recycled bump slab 62–86 MiB with zero slab bytes allocated after warm-up vs 214 MiB plateau with per-step heap arrays; the slab's residual creep is the one view object per allocate() (193/step) — cheap, not free.

Also in this PR: -PjmhIncludes=<regex> to run a subset of the JMH suite; runFlatRssSpike JavaExec task.

Open: the Android half (Cortex-A55-class device, direct ByteBuffer) is pending the reference-device choice (PRD §9); recorded on #1016 when available — the JVM result already sets the rule.

Test plan

Full local gate (scripts/pr-gate.sh, JDK 25); results in the first comment. Benchmarks themselves are not run by the gate (JMH source set); they were run for the report as described.

Closes #1016

🤖 Generated with Claude Code

[michalharakal]

Local gate scripts/pr-gate.sh (JDK 25) on 62fd1c2:

=== pr-gate: JVM tests ===                                      BUILD SUCCESSFUL
=== pr-gate: apiCheck ===                                       BUILD SUCCESSFUL
=== pr-gate: verifyNpmPins jsTest wasmJsTest wasmWasiTest ===   BUILD SUCCESSFUL (first run hit the pre-existing timing test `SlicingTest.testPerformanceAccessPatterns` on JS/Chrome — unrelated to this change, passed on re-run)
=== pr-gate: linuxX64Test ===                                   BUILD SUCCESSFUL
=== pr-gate: assemble ===                                       BUILD SUCCESSFUL
=== pr-gate: :skainet-test:skainet-test-java:test ===           BUILD SUCCESSFUL
pr-gate: all legs passed.

[github-actions]

📖 Documentation Preview

The documentation has been built successfully for this PR.

Generated Files:

• Operator documentation: docs/modules/operators/_generated_/
• JSON schema output: operators.json

Artifacts:

• Download the documentation-preview-1060 artifact to view the complete documentation locally.

This comment will be updated automatically when the PR is updated.