Skip to content

Backend: metric schema and probes (#6001), focused test slices (#6002) - #6114

Open
shai-almog wants to merge 2 commits into
masterfrom
backend-metrics-test-slices
Open

shai-almog wants to merge 2 commits into
masterfrom
backend-metrics-test-slices

Conversation

@shai-almog

Copy link
Copy Markdown
Collaborator

Closes #6001. Closes #6002.

Metrics (#6001)

  • MetricSchema, served at GET /manage/schema: each metric's name, unit, attributes, temporality, availability (always / database / JVM) and Micrometer equivalent, plus the Micrometer meters neither runtime reports, each with its reason.
  • A metric a runtime can't measure is left out of the JSON, Prometheus and OTLP output, never reported as 0. The schema marks it available: false and gives the reason.
  • New pool gauges: db.client.connection.max, .pending_requests and .timeouts. Pool reference counts are kept per server.
  • New probes: /manage/health/liveness (200 while starting and draining) and /manage/health/readiness (503 while starting or draining). Neither needs a token.
  • vm/backend/dashboards/backend-overview.json, a Grafana dashboard that uses only metrics every runtime measures.
  • MetricSchemaTest covers the JVM. BackendOperationsTest (vm/tests) builds a native server and checks the probes, the auth, that the schema reports native, that no JVM-only series appears, that every metric the dashboard uses is in the scrape, and that the exporter sends its last export on SIGTERM.

Test slices (#6002)

  • @WebMvcTest wires only the controllers it names plus includes. A missing dependency fails the build, and the error gives the three ways to supply it. @DataJpaTest runs on its own database and rolls back each test, on the JVM and compiled.
  • @BackendTest(features = MANAGEMENT | TELEMETRY | MCP | AS_PACKAGED): production features are off in tests unless a test asks for them.
  • Fixtures: ManagementContract (ready-made @Test default methods) and OtlpTestCollector.
  • The compiled runner now finds @Test default methods on interfaces that come from library jars.
  • Docs: the Observability and Testing chapters, including migrating Spring tests.

There is no GraalVM or native-image job. Native validation goes through the existing ParparVM build.

🤖 Generated with Claude Code

Metrics: a published, stable schema (MetricSchema, GET /manage/schema) with
Micrometer names; a figure a runtime cannot measure is absent, never zero;
pool pending/timeout gauges; liveness and readiness probes; a portable
Grafana dashboard. A native test (BackendOperationsTest) holds the packaged
ParparVM server to the same contract.

Tests: @WebMvcTest and @DataJpaTest slices that fail at build time on a
missing dependency, per-test rollback, opt-in management/telemetry/MCP via
@backendtest(features), and the ManagementContract and OtlpTestCollector
fixtures, all running on the JVM and compiled.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

Developer Guide build artifacts are available for download from this workflow run:

Developer Guide quality checks:

  • AsciiDoc linter: No issues found (report)
  • Vale: No alerts found (report)
  • Paragraph capitalization: No paragraph capitalization issues (report)
  • LanguageTool: No grammar matches (report)
  • Image references: No unused images detected (report)

@github-actions

Copy link
Copy Markdown
Contributor

Cloudflare Preview

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

Flutter vs Codename One

Same application, built both ways: Flutter's AOT compile of the gallery, and the identical Dart source transpiled to Java on Codename One. Lower is better for every metric, so a ratio above 1.00x means Codename One is ahead by that factor.

android

9 interleaved rounds; host load 0.37, 1.53, 1.34

Metric Codename One Flutter Ratio Winner
Installed size 78.2 MB 95.8 MB 1.22x Codename One
Executable code 4.7 MB 20.6 MB 4.41x Codename One
Download size (zipped) 78.2 MB 95.8 MB 1.22x Codename One
Cold start to first frame on screen 343 ms 1253 ms 3.69x Codename One
Memory at rest 45.3 MB 77.8 MB 1.72x Codename One

Start-up and memory at rest are judged round by round: the ratio is the median of the per-round ratios, each from two launches made back to back, and the times and sizes shown are each side's median, so the ratio need not equal their quotient. Codename One was ahead in 9 of 9 rounds on cold start to first frame on screen; 9 of 9 rounds on memory at rest.

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 75 ms 164 ms 2.19x
longArithmetic 49 ms 52 ms 1.06x
mathTranscendental 217 ms 281 ms 1.29x
arraySequential 23 ms 31 ms 1.35x
arrayRandom 199 ms 240 ms 1.21x
objectAllocation 56 ms 37 ms 0.66x
valueEscape 6 ms 6 ms 1.00x
hashMapChurn 119 ms 237 ms 1.99x
stringBuilding 77 ms 99 ms 1.29x
recursion 64 ms 233 ms 3.64x
quicksortBench 112 ms 131 ms 1.17x
Geometric mean 1.38x

Gate: within tolerance against scripts/flutter-bench/baseline.

Android sizes are for the arm64-v8a slice a phone is delivered, on both sides; Flutter's release apk carries three ABIs and would otherwise count its engine about three times.
Android start-up and memory come from an x86_64 emulator with a software GPU. They compare the two runtimes on one machine; they are not phone timings, and a renderer that leans on the GPU is penalised more there.
This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

ios

9 interleaved rounds; host load 14.14, 24.45, 24.0

Metric Codename One Flutter Ratio Winner
Installed size 108.2 MB 110.5 MB 1.02x Codename One
Executable code 17.2 MB 19.1 MB 1.11x Codename One
Download size (zipped) 80.0 MB 81.9 MB 1.02x Codename One
Cold start to first frame on screen -- -- -- not measured
Memory at rest -- -- -- not measured

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Not measured: iOS compute is not measured: a device build needs signed hardware, and on the simulator Flutter runs its JIT debug engine rather than AOT code. The macOS row runs the same ParparVM and Dart AOT compilers on the same Apple silicon.

Gate: within tolerance against scripts/flutter-bench/baseline. Smaller than its baseline, which does not fail the gate: Executable code -7.25% -- rebaseline to tighten. To accept the move, download this platform's baseline-<platform>.json artifact and run python3 scripts/flutter-bench/flutter_baseline.py calibrate --pr 6114 --reason "<why these moved>" baseline-ios.json, then commit the overlay it writes.

iOS start-up and memory are not measured here: Flutter cannot AOT-compile for the simulator, so a simulator run would time a JIT debug build against a release build. Sizes come from release device bundles; timings need signed hardware.
This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

javascript

9 interleaved rounds; host load 2.37, 1.48, 0.66

Metric Codename One Flutter Ratio Winner
Installed size 104.0 MB 122.5 MB 1.18x Codename One
Executable code 12.9 MB 25.2 MB 1.95x Codename One
Download size (zipped) 76.3 MB 84.1 MB 1.10x Codename One
Cold start to first frame on screen -- -- -- not measured
Memory at rest -- -- -- not measured

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 550 ms wrong result Flutter: wrong result
longArithmetic 4040 ms did not run Flutter: did not run
mathTranscendental 490 ms did not run Flutter: did not run
arraySequential 189 ms 70 ms 0.37x
arrayRandom 733 ms wrong result Flutter: wrong result
objectAllocation 28 ms 21 ms 0.75x
valueEscape 125 ms 6 ms 0.05x
hashMapChurn 748 ms 202 ms 0.27x
stringBuilding 379 ms 86 ms 0.23x
recursion 392 ms 398 ms 1.01x
quicksortBench 347 ms wrong result Flutter: wrong result
Geometric mean 0.31x

Gate: within tolerance against scripts/flutter-bench/baseline; BEHIND FLUTTER on Compute (geomean of the VM workloads) (reported, not gated: a loss to Flutter on the web is currently accepted).

the JavaScript adapter needs a Chrome DevTools driver; sizes are reported and timings are not
This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

linux

9 interleaved rounds; host load 0.29, 2.88, 2.43

Metric Codename One Flutter Ratio Winner
Installed size 111.5 MB 143.8 MB 1.29x Codename One
Executable code 14.1 MB 16.1 MB 1.15x Codename One
Download size (zipped) 80.9 MB 92.9 MB 1.15x Codename One
Cold start to first frame on screen 153 ms 235 ms 1.55x Codename One
Memory at rest 84.9 MB 225.5 MB 2.67x Codename One

Start-up and memory at rest are judged round by round: the ratio is the median of the per-round ratios, each from two launches made back to back, and the times and sizes shown are each side's median, so the ratio need not equal their quotient. Codename One was ahead in 9 of 9 rounds on cold start to first frame on screen; 9 of 9 rounds on memory at rest.

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 74 ms 183 ms 2.47x
longArithmetic 56 ms 55 ms 0.98x
mathTranscendental 253 ms 276 ms 1.09x
arraySequential 15 ms 35 ms 2.33x
arrayRandom 259 ms 329 ms 1.27x
objectAllocation 26 ms 44 ms 1.69x
valueEscape 5 ms 7 ms 1.40x
hashMapChurn 49 ms 339 ms 6.92x
stringBuilding 33 ms 119 ms 3.61x
recursion 87 ms 257 ms 2.95x
quicksortBench 138 ms 149 ms 1.08x
Geometric mean 1.94x

Gate: within tolerance against scripts/flutter-bench/baseline.

This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

macos

9 interleaved rounds; host load 6.19, 21.35, 25.11

Metric Codename One Flutter Ratio Winner
Installed size 124.2 MB 139.4 MB 1.12x Codename One
Executable code 33.1 MB 47.9 MB 1.45x Codename One
Download size (zipped) 85.5 MB 93.3 MB 1.09x Codename One
Cold start to first frame on screen 393 ms 529 ms 1.24x Codename One
Memory at rest 36.5 MB 55.8 MB 1.52x Codename One

Start-up and memory at rest are judged round by round: the ratio is the median of the per-round ratios, each from two launches made back to back, and the times and sizes shown are each side's median, so the ratio need not equal their quotient. Codename One was ahead in 8 of 9 rounds on cold start to first frame on screen; 9 of 9 rounds on memory at rest.

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 121 ms 266 ms 2.20x
longArithmetic 78 ms 68 ms 0.87x
mathTranscendental 297 ms 348 ms 1.17x
arraySequential 11 ms 43 ms 3.91x
arrayRandom 275 ms 345 ms 1.25x
objectAllocation 70 ms 31 ms 0.44x
valueEscape 5 ms 14 ms 2.80x
hashMapChurn 33 ms 174 ms 5.27x
stringBuilding 34 ms 122 ms 3.59x
recursion 143 ms 274 ms 1.92x
quicksortBench 133 ms 136 ms 1.02x
Geometric mean 1.76x

Gate: within tolerance against scripts/flutter-bench/baseline. Smaller than its baseline, which does not fail the gate: Executable code -6.26% -- rebaseline to tighten. To accept the move, download this platform's baseline-<platform>.json artifact and run python3 scripts/flutter-bench/flutter_baseline.py calibrate --pr 6114 --reason "<why these moved>" baseline-macos.json, then commit the overlay it writes.

This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

windows

9 interleaved rounds

Metric Codename One Flutter Ratio Winner
Installed size 107.8 MB 121.1 MB 1.12x Codename One
Executable code 11.4 MB 14.1 MB 1.25x Codename One
Download size (zipped) 77.9 MB 86.4 MB 1.11x Codename One
Cold start to first frame on screen 158 ms 249 ms 1.56x Codename One
Memory at rest 58.5 MB 92.8 MB 1.59x Codename One

Start-up and memory at rest are judged round by round: the ratio is the median of the per-round ratios, each from two launches made back to back, and the times and sizes shown are each side's median, so the ratio need not equal their quotient. Codename One was ahead in 9 of 9 rounds on cold start to first frame on screen; 9 of 9 rounds on memory at rest.

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 81 ms 184 ms 2.27x
longArithmetic 64 ms 57 ms 0.89x
mathTranscendental 198 ms 266 ms 1.34x
arraySequential 11 ms 35 ms 3.18x
arrayRandom 243 ms 345 ms 1.42x
objectAllocation 24 ms 39 ms 1.62x
valueEscape 1 ms 7 ms 7.00x
hashMapChurn 49 ms 321 ms 6.55x
stringBuilding 34 ms 121 ms 3.56x
recursion 213 ms 264 ms 1.24x
quicksortBench 145 ms 148 ms 1.02x
Geometric mean 2.13x

Gate: within tolerance against scripts/flutter-bench/baseline. Smaller than its baseline, which does not fail the gate: Executable code -10.64%; Download size (zipped) -0.77% -- rebaseline to tighten. To accept the move, download this platform's baseline-<platform>.json artifact and run python3 scripts/flutter-bench/flutter_baseline.py calibrate --pr 6114 --reason "<why these moved>" baseline-windows.json, then commit the overlay it writes.

This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

Codename One wins 26 of 26 measured metrics across 6 platform(s).

@shai-almog

shai-almog commented Oct 26, 2026 •

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 64ms / native 6ms = 10.6x speedup
SIMD float-mul (64K x300) java 57ms / native 7ms = 8.1x 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 110.000 ms
Base64 CN1 decode 137.000 ms
Base64 SIMD encode 182.000 ms
Base64 encode ratio (SIMD/CN1) 1.655x (65.5% slower)
Base64 SIMD decode 138.000 ms
Base64 decode ratio (SIMD/CN1) 1.007x (0.7% slower)
Image encode benchmark iterations 100
Image createMask (SIMD off) 15.000 ms
Image createMask (SIMD on) 5.000 ms
Image createMask ratio (SIMD on/off) 0.333x (66.7% faster)
Image applyMask (SIMD off) 45.000 ms
Image applyMask (SIMD on) 55.000 ms
Image applyMask ratio (SIMD on/off) 1.222x (22.2% slower)
Image modifyAlpha (SIMD off) 62.000 ms
Image modifyAlpha (SIMD on) 28.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.452x (54.8% faster)
Image modifyAlpha removeColor (SIMD off) 58.000 ms
Image modifyAlpha removeColor (SIMD on) 13.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.224x (77.6% faster)

@shai-almog

shai-almog commented Oct 26, 2026 •

Copy link
Copy Markdown
Collaborator Author

Compared 191 screenshots: 191 matched.

Native Android coverage

  • 📊 Line coverage: 18.90% (48250/255341 lines covered) [HTML preview] (artifact android-coverage-report, jacocoAndroidReport/html/index.html)
    • Other counters: instruction 17.64% (229182/1299035), branch 12.04% (16818/139675), complexity 9.67% (12911/133466), method 14.57% (9122/62628), class 25.16% (1774/7052)
    • 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.90% (48250/255341 lines covered) [HTML preview] (artifact android-coverage-report, jacocoAndroidReport/html/index.html)
    • Other counters: instruction 17.64% (229182/1299035), branch 12.04% (16818/139675), complexity 9.67% (12911/133466), method 14.57% (9122/62628), class 25.16% (1774/7052)
    • 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 122ms / native 122ms = 1.0x speedup
SIMD float-mul (64K x300) java 152ms / native 126ms = 1.2x 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 73.000 ms
Base64 CN1 decode 83.000 ms
Base64 native encode 449.000 ms
Base64 encode ratio (CN1/native) 0.163x (83.7% faster)
Base64 native decode 273.000 ms
Base64 decode ratio (CN1/native) 0.304x (69.6% faster)
Image encode benchmark status skipped (SIMD unsupported)

@shai-almog

shai-almog commented Oct 26, 2026 •

Copy link
Copy Markdown
Collaborator Author

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

@github-actions

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: 1 findings (P3: 1) [HTML preview] [Download]
  • ✅ Checkstyle: 0 findings (no issues) [Report archive]

Generated automatically by the PR CI workflow.

@shai-almog

shai-almog commented Oct 26, 2026 •

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 63ms / native 5ms = 12.6x speedup
SIMD float-mul (64K x300) java 58ms / native 4ms = 14.5x 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 73.000 ms
Base64 CN1 decode 90.000 ms
Base64 SIMD encode 104.000 ms
Base64 encode ratio (SIMD/CN1) 1.425x (42.5% slower)
Base64 SIMD decode 98.000 ms
Base64 decode ratio (SIMD/CN1) 1.089x (8.9% slower)
Image encode benchmark iterations 100
Image createMask (SIMD off) 9.000 ms
Image createMask (SIMD on) 2.000 ms
Image createMask ratio (SIMD on/off) 0.222x (77.8% faster)
Image applyMask (SIMD off) 42.000 ms
Image applyMask (SIMD on) 50.000 ms
Image applyMask ratio (SIMD on/off) 1.190x (19.0% slower)
Image modifyAlpha (SIMD off) 59.000 ms
Image modifyAlpha (SIMD on) 27.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.458x (54.2% faster)
Image modifyAlpha removeColor (SIMD off) 42.000 ms
Image modifyAlpha removeColor (SIMD on) 20.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.476x (52.4% 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.47x (base 1.22x, +20.6%) 0.73x (base 0.94x, -22.0%) ok
translator (self) 4 0.79x (base 0.83x, -5.1%) 0.52x (base 0.54x, -3.6%) ok
intArithmetic 4 1.10x (base 1.10x, +0.0%) 0.06x (base 0.06x, +2.7%) ok
longArithmetic 4 1.14x (base 1.08x, +5.1%) 0.06x (base 0.05x, +3.6%) ok
mathTranscendental 4 0.79x (base 0.79x, -0.3%) 0.06x (base 0.06x, +3.0%) ok
arraySequential 4 1.27x (base 1.36x, -6.9%) 0.39x (base 0.39x, +0.2%) ok
arrayRandom 4 1.13x (base 1.06x, +6.9%) 0.23x (base 0.23x, +0.5%) ok
objectAllocation 4 1.55x (base 1.56x, -0.6%) 0.29x (base 0.39x, -24.6%) ok
valueEscape 4 0.10x (base 0.10x, +0.2%) 0.05x (base 0.04x, +4.9%) ok
hashMapChurn 4 1.88x (base 1.80x, +4.5%) 0.09x (base 0.09x, -2.5%) ok
stringBuilding 4 1.33x (base 1.22x, +9.3%) 0.32x (base 0.32x, +0.3%) ok
recursion 4 1.41x (base 1.49x, -5.9%) 0.06x (base 0.06x, +1.6%) ok
quicksort 4 1.11x (base 1.13x, -2.4%) 0.12x (base 0.12x, +0.7%) ok

Result: no regression

@shai-almog

shai-almog commented Oct 26, 2026 •

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: AMD EPYC 7763 64-Core Processor (baseline linux-x64@amd-epyc-7763-64-core-processor)

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

  • translator (self) on all 4 CPUs: time 0.51x against a 0.64x baseline (-20.2%, tolerance 20%)

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.83x (base 0.85x, -2.2%) 0.65x (base 0.83x, -21.8%) ok
translator (self) 4 0.51x (base 0.64x, -20.2%) 0.47x (base 0.52x, -10.0%) improved: rebaseline to lock in (time -20.2%)
intArithmetic 4 1.10x (base 1.12x, -1.2%) 0.06x (base 0.06x, +2.3%) ok
longArithmetic 4 1.08x (base 1.08x, -0.0%) 0.07x (base 0.05x, +38.9%) ok
mathTranscendental 4 1.09x (base 1.08x, +0.1%) 0.06x (base 0.07x, -21.1%) ok
arraySequential 4 2.36x (base 2.00x, +17.7%) 0.38x (base 0.36x, +5.1%) ok
arrayRandom 4 0.96x (base 0.91x, +5.1%) 0.23x (base 0.21x, +10.0%) ok
objectAllocation 4 1.51x (base 1.65x, -8.6%) 0.33x (base 0.35x, -7.4%) ok
valueEscape 4 0.10x (base 0.10x, -0.3%) 0.04x (base 0.04x, +0.5%) ok
hashMapChurn 4 1.47x (base 1.48x, -0.5%) 0.09x (base 0.09x, +0.5%) ok
stringBuilding 4 1.42x (base 1.39x, +2.3%) 0.26x (base 0.31x, -16.9%) ok
recursion 4 1.19x (base 1.25x, -5.4%) 0.06x (base 0.08x, -24.4%) ok
quicksort 4 1.11x (base 1.07x, +3.4%) 0.13x (base 0.11x, +16.9%) ok

A change that moves performance ON PURPOSE records the new baseline in vm/selfhost/perf-baseline/pr/6114.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 6114 --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 •

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.97x (base 1.02x, -5.0%) 0.67x (base 0.93x, -28.5%) ok
translator (self) 4 0.76x (base 0.70x, +8.6%) 0.45x (base 0.43x, +5.1%) ok
intArithmetic 4 1.04x (base 1.04x, -0.0%) 0.03x (base 0.03x, +4.4%) ok
longArithmetic 4 0.79x (base 0.79x, -0.1%) 0.03x (base 0.03x, +4.6%) ok
mathTranscendental 4 1.09x (base 1.10x, -0.3%) 0.04x (base 0.03x, +9.6%) ok
arraySequential 4 0.36x (base 0.36x, -0.8%) 0.37x (base 0.37x, +0.2%) ok
arrayRandom 4 0.93x (base 0.94x, -0.2%) 0.20x (base 0.20x, +0.7%) ok
objectAllocation 4 1.94x (base 1.77x, +9.7%) 0.37x (base 0.37x, +0.2%) ok
valueEscape 4 0.51x (base 0.51x, -0.1%) 0.03x (base 0.03x, +5.0%) ok
hashMapChurn 4 0.85x (base 0.84x, +0.8%) 0.11x (base 0.12x, -5.3%) ok
stringBuilding 4 1.49x (base 1.57x, -5.1%) 0.26x (base 0.26x, +0.2%) ok
recursion 4 1.42x (base 1.43x, -1.1%) 0.04x (base 0.04x, +3.0%) ok
quicksort 4 1.01x (base 0.99x, +1.3%) 0.09x (base 0.09x, +1.2%) ok

Result: no regression

@github-actions

Copy link
Copy Markdown
Contributor

✅ ByteCodeTranslator Quality Report

Test & Coverage

  • ✅ Tests: 882 total, 0 failed, 55 skipped

Benchmark Results

  • Execution Time: 6325 ms

  • Hotspots (Top 20 sampled methods):

    • 9.92% com.codename1.tools.translator.IteratorEscape.ctorOnlyStoresParamsIntoThis (98 samples)
    • 6.88% java.util.ArrayList.indexOf (68 samples)
    • 6.58% java.lang.System.identityHashCode (65 samples)
    • 5.16% java.lang.Object.hashCode (51 samples)
    • 4.25% com.codename1.tools.translator.BytecodeMethod.equals (42 samples)
    • 2.94% com.codename1.tools.translator.classfile.analysis.Frame.execute (29 samples)
    • 2.23% com.codename1.tools.translator.Util.getCType (22 samples)
    • 2.02% java.lang.StringBuilder.append (20 samples)
    • 1.92% com.codename1.tools.translator.IteratorEscape.walk (19 samples)
    • 1.72% com.codename1.tools.translator.Parser.cullMethods (17 samples)
    • 1.72% com.codename1.tools.translator.BytecodeMethod.updateInlinableFieldDependencies (17 samples)
    • 1.72% com.codename1.tools.translator.IteratorEscape.mangle (17 samples)
    • 1.52% java.io.FileOutputStream.writeBytes (15 samples)
    • 1.42% com.codename1.tools.translator.ByteCodeClass.hasDeclaredMethod (14 samples)
    • 1.32% com.codename1.tools.translator.bytecodes.Invoke.resolveDirectTarget (13 samples)
    • 1.21% java.util.TreeMap.getEntry (12 samples)
    • 1.21% java.util.HashMap.hash (12 samples)
    • 1.21% java.util.AbstractCollection.containsAll (12 samples)
    • 1.11% com.codename1.tools.translator.DeadFieldElimination.run (11 samples)
    • 1.11% java.lang.String.equals (11 samples)
  • ⚠️ Coverage report not generated.

Static Analysis

  • ✅ SpotBugs: no findings (report was not generated by the build).
  • ⚠️ PMD report not generated.
  • ⚠️ Checkstyle report not generated.

Generated automatically by the PR CI workflow.

@shai-almog

shai-almog commented Oct 26, 2026 •

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 53ms / native 2ms = 26.5x speedup
SIMD float-mul (64K x300) java 54ms / native 3ms = 18.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 60.000 ms
Base64 CN1 decode 69.000 ms
Base64 SIMD encode 78.000 ms
Base64 encode ratio (SIMD/CN1) 1.300x (30.0% slower)
Base64 SIMD decode 68.000 ms
Base64 decode ratio (SIMD/CN1) 0.986x (1.4% faster)
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) 15.000 ms
Image modifyAlpha (SIMD on) 12.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.800x (20.0% faster)
Image modifyAlpha removeColor (SIMD off) 15.000 ms
Image modifyAlpha removeColor (SIMD on) 8.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.533x (46.7% 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.5%) 0.60x (base 0.75x, -20.1%) ok
translator (self) 4 0.89x (base 0.84x, +5.7%) 0.49x (base 0.51x, -4.1%) ok
intArithmetic 4 1.04x (base 1.04x, +0.0%) 0.06x (base 0.06x, +3.0%) ok
longArithmetic 4 0.80x (base 0.80x, +0.1%) 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.37x (base 0.46x, -17.8%) 0.39x (base 0.39x, -0.0%) ok
arrayRandom 4 0.94x (base 0.94x, +0.0%) 0.23x (base 0.23x, +0.1%) ok
objectAllocation 4 1.80x (base 1.82x, -1.2%) 0.39x (base 0.43x, -9.2%) ok
valueEscape 4 0.76x (base 0.76x, +0.1%) 0.05x (base 0.05x, +2.3%) ok
hashMapChurn 4 0.99x (base 0.98x, +0.9%) 0.11x (base 0.12x, -8.0%) ok
stringBuilding 4 1.61x (base 1.43x, +12.5%) 0.27x (base 0.27x, -0.2%) ok
recursion 4 1.55x (base 1.46x, +6.0%) 0.07x (base 0.07x, +1.0%) ok
quicksort 4 1.00x (base 1.00x, +0.3%) 0.12x (base 0.12x, +0.4%) ok

Result: no regression

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RFE: Backend focused test slices and end-to-end feature parity fixtures RFE: Backend operational metric compatibility and migration guidance

1 participant