Skip to content

iOS: re-read the view size when a covering modal is dismissed (#6080) - #6115

Open
shai-almog wants to merge 3 commits into
masterfrom
ios-camera-landscape-6080
Open

iOS: re-read the view size when a covering modal is dismissed (#6080)#6115
shai-almog wants to merge 3 commits into
masterfrom
ios-camera-landscape-6080

Conversation

@shai-almog

@shai-almog shai-almog commented Oct 26, 2026

Copy link
Copy Markdown
Collaborator

Fixes the remaining case of #6080: app in landscape, portrait-only camera opened, phone kept landscape, photo accepted -> the app returns with portrait display/Form dimensions over a landscape view.

Presenting the portrait-only modal sends the covered controller a portrait viewWillTransitionToSize:, which publishes the portrait size, but the covered view is never laid out portrait. On dismissal its bounds are unchanged, so no layout pass runs and #6085's viewDidLayoutSubviews sync never fires.

  • viewDidLayoutSubviews' sync is now cn1PublishViewSizeIfChanged, also called from viewDidAppear and from the transition completion (skipped while still covered).
  • NativeModalRotationTest gains a landscape-stays-landscape case that requires the precondition (portrait display over a landscape view under the modal) and then asserts the display matches the view after dismissal.

🤖 Generated with Claude Code

shai-almog and others added 3 commits October 26, 2026 20:18
@shai-almog @claude
iOS: re-read the view size when a covering modal is dismissed (#6080)
a61a023 
Presenting the portrait-only camera over a landscape app sends the covered
controller a portrait viewWillTransitionToSize:, but its bounds never change,
so staying in landscape leaves no layout pass to correct the published size.
viewDidAppear and the transition completion now re-sync from the bounds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
iOS: skip the transition re-sync while covered; test the landscape-st…
f87e6ef 
…ays-landscape case (#6080)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
test: require the landscape case's precondition (#6080)
c95701c 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog

shai-almog commented Oct 26, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 191 screenshots: 191 matched.

Native Android coverage

  • 📊 Line coverage: 18.89% (48250/255376 lines covered) [HTML preview] (artifact android-coverage-report, jacocoAndroidReport/html/index.html)
    • Other counters: instruction 17.64% (229182/1299301), branch 12.04% (16818/139691), complexity 9.67% (12911/133489), method 14.56% (9122/62643), class 25.13% (1774/7059)
    • Lowest covered classes
      • kotlin.collections.kotlin.collections.ArraysKt___ArraysKt – 0.00% (0/6367 lines covered)
      • kotlin.collections.unsigned.kotlin.collections.unsigned.UArraysKt___UArraysKt – 0.00% (0/2384 lines covered)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.ClassReader – 0.00% (0/1524 lines covered)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.MethodWriter – 0.00% (0/922 lines covered)
      • kotlin.sequences.kotlin.sequences.SequencesKt___SequencesKt – 0.00% (0/736 lines covered)
      • com.google.common.cache.com.google.common.cache.LocalCache$Segment – 0.00% (0/726 lines covered)
      • okio.okio.Buffer – 0.00% (0/687 lines covered)
      • kotlin.text.kotlin.text.StringsKt___StringsKt – 0.00% (0/625 lines covered)
      • com.codename1.androidcompat.rt.com.codename1.androidcompat.rt.TextXmlPullParser – 0.00% (0/623 lines covered)
      • com.codename1.androidcompat.androidx.constraintlayout.core.widgets.com.codename1.androidcompat.androidx.constraintlayout.core.widgets.Flow – 0.00% (0/576 lines covered)

✅ Native Android screenshot tests passed.

Native Android coverage

  • 📊 Line coverage: 18.89% (48250/255376 lines covered) [HTML preview] (artifact android-coverage-report, jacocoAndroidReport/html/index.html)
    • Other counters: instruction 17.64% (229182/1299301), branch 12.04% (16818/139691), complexity 9.67% (12911/133489), method 14.56% (9122/62643), class 25.13% (1774/7059)
    • Lowest covered classes
      • kotlin.collections.kotlin.collections.ArraysKt___ArraysKt – 0.00% (0/6367 lines covered)
      • kotlin.collections.unsigned.kotlin.collections.unsigned.UArraysKt___UArraysKt – 0.00% (0/2384 lines covered)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.ClassReader – 0.00% (0/1524 lines covered)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.MethodWriter – 0.00% (0/922 lines covered)
      • kotlin.sequences.kotlin.sequences.SequencesKt___SequencesKt – 0.00% (0/736 lines covered)
      • com.google.common.cache.com.google.common.cache.LocalCache$Segment – 0.00% (0/726 lines covered)
      • okio.okio.Buffer – 0.00% (0/687 lines covered)
      • kotlin.text.kotlin.text.StringsKt___StringsKt – 0.00% (0/625 lines covered)
      • com.codename1.androidcompat.rt.com.codename1.androidcompat.rt.TextXmlPullParser – 0.00% (0/623 lines covered)
      • com.codename1.androidcompat.androidx.constraintlayout.core.widgets.com.codename1.androidcompat.androidx.constraintlayout.core.widgets.Flow – 0.00% (0/576 lines covered)

Benchmark Results

Detailed Performance Metrics

Metric Duration
SIMD kernel backend scalar fallback (no native SIMD)
SIMD int-add (64K x300) java 151ms / native 94ms = 1.6x speedup
SIMD float-mul (64K x300) java 54ms / native 63ms = 0.8x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode 38.000 ms
Base64 CN1 decode 46.000 ms
Base64 native encode 339.000 ms
Base64 encode ratio (CN1/native) 0.112x (88.8% faster)
Base64 native decode 189.000 ms
Base64 decode ratio (CN1/native) 0.243x (75.7% faster)
Image encode benchmark status skipped (SIMD unsupported)

@shai-almog

shai-almog commented Oct 26, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 206 screenshots: 206 matched.
Native Windows port, REAL shipping pipeline: the hellocodenameone screenshot suite rendered by a binary CROSS-COMPILED on Linux (clang-cl + xwin, WebView2 linked) and RUN on a Windows x64 runner. Compared against the in-repo baseline in scripts/windows/screenshots.

Benchmark Results

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 50ms / native 4ms = 12.5x speedup
SIMD float-mul (64K x300) java 50ms / native 3ms = 16.6x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 native bridge unavailable (CN1 + SIMD + image benchmarks only)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode 68.000 ms
Base64 CN1 decode 79.000 ms
Base64 SIMD encode 92.000 ms
Base64 encode ratio (SIMD/CN1) 1.353x (35.3% slower)
Base64 SIMD decode 91.000 ms
Base64 decode ratio (SIMD/CN1) 1.152x (15.2% slower)
Image encode benchmark iterations 100
Image createMask (SIMD off) 8.000 ms
Image createMask (SIMD on) 3.000 ms
Image createMask ratio (SIMD on/off) 0.375x (62.5% faster)
Image applyMask (SIMD off) 35.000 ms
Image applyMask (SIMD on) 28.000 ms
Image applyMask ratio (SIMD on/off) 0.800x (20.0% faster)
Image modifyAlpha (SIMD off) 34.000 ms
Image modifyAlpha (SIMD on) 19.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.559x (44.1% faster)
Image modifyAlpha removeColor (SIMD off) 31.000 ms
Image modifyAlpha removeColor (SIMD on) 19.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.613x (38.7% faster)

@github-actions

github-actions Bot commented Oct 26, 2026

Copy link
Copy Markdown
Contributor

✅ Continuous Quality Report

Test & Coverage

Static Analysis

  • SpotBugs [Report archive]
    • ✅ ByteCodeTranslator: 0 findings (no issues)
    • ✅ android: 0 findings (no issues)
    • ✅ android-compat: 0 findings (no issues)
    • ✅ android-res-compiler: 0 findings (no issues)
    • ✅ backend: 0 findings (no issues)
    • ✅ backend-test: 0 findings (no issues)
    • ✅ build-engine: 0 findings (no issues)
    • ✅ build-hint-catalog: 0 findings (no issues)
    • ✅ build-hint-tools: 0 findings (no issues)
    • ✅ codenameone-gradle-plugin: 0 findings (no issues)
    • ✅ codenameone-maven-plugin: 0 findings (no issues)
    • ✅ core-unittests: 0 findings (no issues)
    • ✅ desktop-compat-runtime: 0 findings (no issues)
    • ✅ fxml-compiler: 0 findings (no issues)
    • ✅ ios: 0 findings (no issues)
    • ✅ javac: 0 findings (no issues)
    • ✅ javafx-compat: 0 findings (no issues)
    • ✅ project-model: 0 findings (no issues)
    • ✅ swing-compat: 0 findings (no issues)
  • ✅ PMD: 0 findings (no issues) [Report archive]
  • ✅ Checkstyle: 0 findings (no issues) [Report archive]

Generated automatically by the PR CI workflow.

@shai-almog

shai-almog commented Oct 26, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 227 screenshots: 227 matched.
✅ JavaScript-port screenshot tests passed.

@shai-almog

shai-almog commented Oct 26, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 206 screenshots: 206 matched.
Native Windows port (x64 / Intel-AMD): full hellocodenameone screenshot suite rendered offscreen with Direct2D/DirectWrite, plus the real benchmarks (base64 native/CN1/SIMD, image createMask/applyMask/modifyAlpha/PNG/JPEG, SSE2 SIMD kernels). Compared against the in-repo baseline in scripts/windows/screenshots.

Benchmark Results

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 61ms / native 8ms = 7.6x speedup
SIMD float-mul (64K x300) java 63ms / native 5ms = 12.6x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 native bridge unavailable (CN1 + SIMD + image benchmarks only)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode 77.000 ms
Base64 CN1 decode 89.000 ms
Base64 SIMD encode 121.000 ms
Base64 encode ratio (SIMD/CN1) 1.571x (57.1% slower)
Base64 SIMD decode 99.000 ms
Base64 decode ratio (SIMD/CN1) 1.112x (11.2% slower)
Image encode benchmark iterations 100
Image createMask (SIMD off) 15.000 ms
Image createMask (SIMD on) 7.000 ms
Image createMask ratio (SIMD on/off) 0.467x (53.3% faster)
Image applyMask (SIMD off) 49.000 ms
Image applyMask (SIMD on) 40.000 ms
Image applyMask ratio (SIMD on/off) 0.816x (18.4% faster)
Image modifyAlpha (SIMD off) 36.000 ms
Image modifyAlpha (SIMD on) 20.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.556x (44.4% faster)
Image modifyAlpha removeColor (SIMD off) 30.000 ms
Image modifyAlpha removeColor (SIMD on) 21.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.700x (30.0% faster)

ParparVM vs HotSpot (JDK 25): Windows x64

Runner CPU: AMD64 Family 25 Model 1 Stepping 1, AuthenticAMD (baseline windows-x64@amd64-family-25-model-1-authenticamd)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (WinHelloMain) 4 1.51x (base 1.22x, +23.5%) 0.74x (base 0.94x, -21.5%) ok
translator (self) 4 0.83x (base 0.83x, -0.6%) 0.55x (base 0.54x, +0.9%) ok
intArithmetic 4 1.10x (base 1.10x, +0.0%) 0.06x (base 0.06x, +2.4%) ok
longArithmetic 4 1.14x (base 1.08x, +5.1%) 0.06x (base 0.05x, +3.3%) ok
mathTranscendental 4 0.79x (base 0.79x, -0.3%) 0.06x (base 0.06x, +2.7%) ok
arraySequential 4 1.44x (base 1.36x, +5.2%) 0.39x (base 0.39x, +0.3%) ok
arrayRandom 4 0.97x (base 1.06x, -8.9%) 0.23x (base 0.23x, +0.5%) ok
objectAllocation 4 1.55x (base 1.56x, -0.9%) 0.29x (base 0.39x, -24.9%) ok
valueEscape 4 0.10x (base 0.10x, +0.3%) 0.05x (base 0.04x, +5.1%) ok
hashMapChurn 4 1.88x (base 1.80x, +4.4%) 0.09x (base 0.09x, -3.4%) ok
stringBuilding 4 1.24x (base 1.22x, +1.6%) 0.32x (base 0.32x, +0.1%) ok
recursion 4 1.41x (base 1.49x, -5.9%) 0.06x (base 0.06x, +1.5%) ok
quicksort 4 1.11x (base 1.13x, -2.1%) 0.12x (base 0.12x, +0.7%) ok

Result: no regression

@shai-almog

shai-almog commented Oct 26, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 206 screenshots: 206 matched.
Native Linux port (arm64), GTK3/Cairo/Pango, ParparVM bytecode-to-C (no JVM): the hellocodenameone screenshot suite rendered by a native ELF built + run on the GitHub arm64 runner. Baseline: scripts/linux/screenshots-arm.

ParparVM vs HotSpot (JDK 25): Linux arm64

Runner CPU: Neoverse-N2 (baseline linux-arm64@neoverse-n2)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (LinuxHelloMain) 4 0.96x (base 1.02x, -5.5%) 0.64x (base 0.93x, -31.3%) ok
translator (self) 4 0.73x (base 0.70x, +4.4%) 0.44x (base 0.43x, +1.8%) ok
intArithmetic 4 1.05x (base 1.04x, +0.0%) 0.03x (base 0.03x, +4.5%) ok
longArithmetic 4 0.79x (base 0.79x, -0.1%) 0.04x (base 0.03x, +8.1%) ok
mathTranscendental 4 1.09x (base 1.10x, -0.3%) 0.04x (base 0.03x, +9.4%) ok
arraySequential 4 0.35x (base 0.36x, -4.3%) 0.37x (base 0.37x, +0.1%) ok
arrayRandom 4 0.94x (base 0.94x, -0.1%) 0.20x (base 0.20x, +0.4%) ok
objectAllocation 4 1.87x (base 1.77x, +5.5%) 0.37x (base 0.37x, -0.4%) ok
valueEscape 4 0.51x (base 0.51x, -0.1%) 0.03x (base 0.03x, +5.1%) ok
hashMapChurn 4 0.85x (base 0.84x, +0.5%) 0.12x (base 0.12x, -0.6%) ok
stringBuilding 4 1.36x (base 1.57x, -13.0%) 0.32x (base 0.26x, +20.5%) ok
recursion 4 1.46x (base 1.43x, +1.8%) 0.04x (base 0.04x, +3.0%) ok
quicksort 4 1.00x (base 0.99x, +0.8%) 0.09x (base 0.09x, +1.0%) ok

Result: no regression

@shai-almog

shai-almog commented Oct 26, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 206 screenshots: 206 matched.
Native Windows port (arm64 / Apple Silicon - Arm): full hellocodenameone screenshot suite rendered offscreen with Direct2D/DirectWrite, plus the real benchmarks (base64 native/CN1/SIMD, image createMask/applyMask/modifyAlpha/PNG/JPEG, NEON SIMD kernels). Compared against the in-repo baseline in scripts/windows/screenshots.

Benchmark Results

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 51ms / native 3ms = 17.0x speedup
SIMD float-mul (64K x300) java 48ms / native 3ms = 16.0x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 native bridge unavailable (CN1 + SIMD + image benchmarks only)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode 59.000 ms
Base64 CN1 decode 70.000 ms
Base64 SIMD encode 77.000 ms
Base64 encode ratio (SIMD/CN1) 1.305x (30.5% slower)
Base64 SIMD decode 73.000 ms
Base64 decode ratio (SIMD/CN1) 1.043x (4.3% slower)
Image encode benchmark iterations 100
Image createMask (SIMD off) 6.000 ms
Image createMask (SIMD on) 1.000 ms
Image createMask ratio (SIMD on/off) 0.167x (83.3% faster)
Image applyMask (SIMD off) 17.000 ms
Image applyMask (SIMD on) 19.000 ms
Image applyMask ratio (SIMD on/off) 1.118x (11.8% slower)
Image modifyAlpha (SIMD off) 17.000 ms
Image modifyAlpha (SIMD on) 13.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.765x (23.5% faster)
Image modifyAlpha removeColor (SIMD off) 23.000 ms
Image modifyAlpha removeColor (SIMD on) 11.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.478x (52.2% faster)

ParparVM vs HotSpot (JDK 25): Windows arm64

Runner CPU: ARMv8 (64-bit) Family 8 Model D49 Revision 0, MICROSOFT CORPORATION (baseline windows-arm64@armv8-64-bit-family-8-model-d49-microsoft-corporation)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (WinHelloMain) 4 0.99x (base 1.11x, -10.9%) 0.60x (base 0.75x, -19.7%) ok
translator (self) 4 0.90x (base 0.84x, +7.1%) 0.49x (base 0.51x, -3.3%) ok
intArithmetic 4 1.04x (base 1.04x, +0.0%) 0.06x (base 0.06x, +3.1%) ok
longArithmetic 4 0.79x (base 0.80x, -0.0%) 0.06x (base 0.06x, +3.4%) ok
mathTranscendental 4 0.72x (base 0.72x, -0.0%) 0.07x (base 0.06x, +1.7%) ok
arraySequential 4 0.36x (base 0.46x, -20.4%) 0.39x (base 0.39x, +0.0%) ok
arrayRandom 4 0.94x (base 0.94x, -0.2%) 0.23x (base 0.23x, +0.5%) ok
objectAllocation 4 1.79x (base 1.82x, -1.6%) 0.33x (base 0.43x, -23.2%) ok
valueEscape 4 0.76x (base 0.76x, +0.0%) 0.05x (base 0.05x, +3.8%) ok
hashMapChurn 4 1.00x (base 0.98x, +1.3%) 0.12x (base 0.12x, +0.8%) ok
stringBuilding 4 1.60x (base 1.43x, +12.4%) 0.27x (base 0.27x, -0.6%) ok
recursion 4 1.55x (base 1.46x, +5.6%) 0.07x (base 0.07x, +1.3%) ok
quicksort 4 1.00x (base 1.00x, +0.3%) 0.12x (base 0.12x, +0.7%) ok

Result: no regression

@shai-almog

shai-almog commented Oct 26, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 206 screenshots: 206 matched.
Native Linux port (x64), GTK3/Cairo/Pango, ParparVM bytecode-to-C (no JVM): the hellocodenameone screenshot suite rendered by a native ELF built + run on the GitHub x64 runner. Baseline: scripts/linux/screenshots.

ParparVM vs HotSpot (JDK 25): Linux x64

Runner CPU: INTEL(R) XEON(R) PLATINUM 8573C (baseline linux-x64@intel-xeon-platinum-8573c)

1 improvement past the baseline (not a failure; rebaseline to lock it in):

  • hello (LinuxHelloMain) on all 4 CPUs: RAM 0.65x against a 0.88x baseline (-26.3%, tolerance 25%)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (LinuxHelloMain) 4 0.90x (base 0.94x, -4.6%) 0.65x (base 0.88x, -26.3%) improved: rebaseline to lock in (RAM -26.3%)
translator (self) 4 0.76x (base 0.67x, +14.4%) 0.40x (base 0.44x, -9.2%) ok
intArithmetic 4 1.03x (base 1.03x, +0.2%) 0.08x (base 0.07x, +4.4%) ok
longArithmetic 4 0.96x (base 0.96x, -0.1%) 0.06x (base 0.05x, +3.8%) ok
mathTranscendental 4 1.03x (base 1.03x, -0.3%) 0.06x (base 0.06x, +1.5%) ok
arraySequential 4 2.40x (base 2.69x, -10.8%) 0.36x (base 0.35x, +0.3%) ok
arrayRandom 4 1.05x (base 1.05x, -0.6%) 0.21x (base 0.21x, +1.0%) ok
objectAllocation 4 1.22x (base 1.03x, +17.6%) 0.43x (base 0.51x, -16.0%) ok
valueEscape 4 0.13x (base 0.13x, +0.2%) 0.05x (base 0.04x, +5.0%) ok
hashMapChurn 4 0.98x (base 1.00x, -1.8%) 0.11x (base 0.10x, +11.1%) ok
stringBuilding 4 1.56x (base 1.53x, +2.0%) 0.22x (base 0.22x, -2.3%) ok
recursion 4 0.93x (base 1.05x, -11.9%) 0.06x (base 0.06x, +1.0%) ok
quicksort 4 1.07x (base 1.08x, -0.5%) 0.11x (base 0.11x, +1.9%) ok

A change that moves performance ON PURPOSE records the new baseline in vm/selfhost/perf-baseline/pr/6115.json, with the reason, from this job's perf-results.json. The rebaseline is then part of this pull request's diff:

python3 vm/selfhost/calibrate-perf-baseline.py --pr 6115 --reason "<why these benchmarks moved>" perf-results.json

Result: no regression (improved past the baseline: consider rebaselining)

@shai-almog

shai-almog commented Oct 26, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 192 screenshots: 192 matched.
✅ Native Mac screenshot tests passed.

Benchmark Results

  • VM Translation Time: 0 seconds
  • Compilation Time: 447 seconds

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 60ms / native 6ms = 10.0x speedup
SIMD float-mul (64K x300) java 70ms / native 2ms = 35.0x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 native bridge unavailable (CN1 + SIMD + image benchmarks only)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path active (NEON-accelerated)
Base64 CN1 encode 45.000 ms
Base64 CN1 decode 52.000 ms
Image encode benchmark iterations 100
Image createMask (SIMD off) 13.000 ms
Image createMask (SIMD on) 6.000 ms
Image createMask ratio (SIMD on/off) 0.462x (53.8% faster)
Image applyMask (SIMD off) 65.000 ms
Image applyMask (SIMD on) 56.000 ms
Image applyMask ratio (SIMD on/off) 0.862x (13.8% faster)
Image modifyAlpha (SIMD off) 54.000 ms
Image modifyAlpha (SIMD on) 58.000 ms
Image modifyAlpha ratio (SIMD on/off) 1.074x (7.4% slower)
Image modifyAlpha removeColor (SIMD off) 56.000 ms
Image modifyAlpha removeColor (SIMD on) 56.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 1.000x (0.0% slower)

ParparVM vs HotSpot (JDK 25): macOS arm64

Runner CPU: Apple M1 (Virtual) (baseline macos-arm64)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (HelloCodenameOne) 3 0.73x (base 0.96x, -23.4%) 0.89x (base 0.93x, -3.8%) ok
translator (self) 3 0.60x (base 0.62x, -4.2%) 0.69x (base 0.78x, -11.8%) ok
intArithmetic 3 1.05x (base 1.03x, +1.9%) 0.12x (base 0.12x, +2.8%) ok
longArithmetic 3 1.03x (base 1.03x, +0.6%) 0.11x (base 0.07x, +61.2%) ok
mathTranscendental 3 0.97x (base 1.01x, -3.7%) 0.12x (base 0.12x, +0.7%) ok
arraySequential 3 0.45x (base 0.42x, +6.8%) 0.53x (base 0.53x, +0.3%) ok
arrayRandom 3 0.98x (base 0.99x, -1.1%) 0.33x (base 0.32x, +0.3%) ok
objectAllocation 3 1.02x (base 1.11x, -8.1%) 0.71x (base 0.72x, -1.4%) ok
valueEscape 3 0.50x (base 0.51x, -0.5%) 0.09x (base 0.09x, +4.9%) ok
hashMapChurn 3 1.06x (base 1.18x, -10.2%) 0.07x (base 0.07x, +9.1%) ok
stringBuilding 3 0.89x (base 0.84x, +5.6%) 0.48x (base 0.46x, +3.6%) ok
recursion 3 1.24x (base 1.24x, +0.6%) 0.12x (base 0.12x, +0.6%) ok
quicksort 3 1.01x (base 1.01x, -0.5%) 0.11x (base 0.11x, +1.4%) ok

Result: no regression

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@shai-almog