Skip to content

Enable native Linux editor input and loopback MCP - #6026

Merged
shai-almog merged 9 commits into
masterfrom
linux-loopback-mcp
Oct 16, 2026
Merged

shai-almog merged 9 commits into
masterfrom
linux-loopback-mcp

Conversation

@shai-almog

@shai-almog shai-almog commented Oct 16, 2026 •

Copy link
Copy Markdown
Collaborator

Native Linux editor clients could not use TextInputClient, and native review applications could not host the loopback listener used by built-in MCP. Add the GTK input-method bridge and loopback socket transport so the same editor and debugging APIs work in a ParparVM Linux application.

The GTK bridge routes composition, Unicode commits, editing shortcuts and surrounding-text requests to the EDT, guarded by session and event sequence. It binds the owning window, supports initially focused fields before the dialog is mapped, and resumes after temporary native window focus loss without ending the Java input session. Sensitive fields withhold surrounding text and disable spelling/completion requests while preserving their normal input purpose; only password fields request password purpose. Explicit capitalization constraints map to the corresponding GTK hints, with autoCapitalize used as a fallback. Secondary windows now let pointer events through empty native-peer overlay space, matching the main window; previously clicking a different dialog field left typing in the first field. GTK clipboard/native-edit text is decoded as UTF-8 instead of widening UTF-8 bytes. The canvas key handler activates registered GTK menu accelerators before consuming ordinary keys, so shortcuts such as Ctrl-B reach their menu command while native peer widgets retain normal dispatch.

Sockets bind only IPv4 loopback. Retained token handles keep close/read/write races and stale handles from touching freed peers or reused descriptors. Closing wakes blocked I/O, reads retry EINTR, writes suppress SIGPIPE, and stream closure releases its peer. The developer guide documents the input contract and Linux MCP access.

Validation:

  • Review fix: Java 8 Maven verify passes with 6 focused input/socket tests. The original Linux-module run passed 7 tests.
  • Local Linux ASan/UBSan socket tests: loopback binding, bind conflict, listener cancellation/restart, blocked I/O and close, stale handles, EINTR, SIGPIPE, bounds, outbound connection and descriptor cleanup.
  • Local GTK ASan/UBSan tests: pre-map binding, commit/dead-key composition, UTF-16 offsets, stale state, deletion, commands, window routing, privacy hints, focus return and 100 session replacements/stops.
  • Maven/ParparVM ARM64 application under local Xvfb: 73 checks pass: 7 comparison, 13 Mailings, 13 basic document-keyboard, 4 dialog-input, 22 navigation and 14 paragraph/typing checks. These cover Unicode composition/clipboard, actual X11 key and pointer events, field switching, document isolation, native Ctrl-B followed immediately by typing, grouped undo and paragraph navigation; original document/recipient state is restored.
  • Developer guide structure, API-name and cross-reference checks pass.

Native checks run locally only. Xvfb does not certify window-manager controls, physical input, native TextArea overlay workflows or every IBus/Fcitx engine. Application validation uses merged baseline 008f9ece plus this isolated Linux-port patch; the module tests use current-master base b5ed7e4e. The review application is a RelWithDebInfo build, not a performance baseline. Outbound connection timeouts retain their pre-existing behavior; the port-based listener lifecycle still shares the core API's stop-before-bind limitation.

Review follow-up: local GTK input and socket suites pass with ASan/UBSan. The previous hosted CI failure was a standalone ParparVM hello-memory ratio narrowly crossing the lower improvement threshold; identical VM sources and a passing same-CPU mainline control support measurement variance. Details and retained ratios are in the CI diagnosis comment. No performance baseline or tolerance was changed.

@github-actions

github-actions Bot commented Oct 16, 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

@shai-almog

shai-almog commented Oct 16, 2026 •

Copy link
Copy Markdown
Collaborator Author

Compared 170 screenshots: 170 matched.

Native Android coverage

  • 📊 Line coverage: 16.01% (26002/162390 lines covered) [HTML preview] (artifact android-coverage-report, jacocoAndroidReport/html/index.html)
    • Other counters: instruction 14.37% (122147/850229), branch 9.91% (8466/85441), complexity 7.81% (6525/83503), method 11.59% (4648/40094), class 19.78% (960/4853)
    • 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: 16.01% (26002/162390 lines covered) [HTML preview] (artifact android-coverage-report, jacocoAndroidReport/html/index.html)
    • Other counters: instruction 14.37% (122147/850229), branch 9.91% (8466/85441), complexity 7.81% (6525/83503), method 11.59% (4648/40094), class 19.78% (960/4853)
    • 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 170ms / native 172ms = 0.9x speedup
SIMD float-mul (64K x300) java 230ms / native 104ms = 2.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 85.000 ms
Base64 CN1 decode 84.000 ms
Base64 native encode 477.000 ms
Base64 encode ratio (CN1/native) 0.178x (82.2% faster)
Base64 native decode 269.000 ms
Base64 decode ratio (CN1/native) 0.312x (68.8% faster)
Image encode benchmark status skipped (SIMD unsupported)

@shai-almog

shai-almog commented Oct 16, 2026 •

Copy link
Copy Markdown
Collaborator Author

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

@github-actions

github-actions Bot commented Oct 16, 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)
    • ✅ ios: 0 findings (no issues)
    • ✅ javac: 0 findings (no issues)
    • ✅ project-model: 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 16, 2026 •

Copy link
Copy Markdown
Collaborator Author

Compared 185 screenshots: 185 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 performance regression:

  • translator (self) on all 4 CPUs: time 0.67x against a 0.51x baseline (+32.0%, 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 15% (time) / 15% (RAM) away from its baseline in vm/selfhost/perf-baseline/ fails: above it is a regression, below it an improvement that has to be rebaselined (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.94x (base 0.94x, +0.2%) 0.90x (base 0.88x, +2.6%) ok
translator (self) 4 0.67x (base 0.51x, +32.0%) 0.44x (base 0.52x, -14.1%) REGRESSION (time +32.0%)
intArithmetic 4 1.03x (base 1.03x, -0.1%) 0.06x (base 0.07x, -24.1%) ok
longArithmetic 4 0.96x (base 0.96x, -0.2%) 0.07x (base 0.05x, +36.6%) ok
mathTranscendental 4 1.03x (base 1.03x, -0.1%) 0.08x (base 0.06x, +34.6%) ok
arraySequential 4 2.54x (base 2.69x, -5.8%) 0.36x (base 0.35x, +0.3%) ok
arrayRandom 4 1.02x (base 1.05x, -3.4%) 0.22x (base 0.21x, +7.7%) ok
objectAllocation 4 1.27x (base 1.03x, +23.0%) 0.42x (base 0.51x, -18.0%) ok
valueEscape 4 0.13x (base 0.13x, +0.1%) 0.05x (base 0.04x, +2.8%) ok
hashMapChurn 4 0.99x (base 1.00x, -1.5%) 0.11x (base 0.10x, +14.3%) ok
stringBuilding 4 1.57x (base 1.53x, +2.6%) 0.22x (base 0.22x, -2.3%) ok
recursion 4 0.93x (base 1.05x, -11.4%) 0.06x (base 0.06x, -2.4%) ok
quicksort 4 1.08x (base 1.08x, -0.4%) 0.11x (base 0.11x, +0.6%) ok

A change that moves performance ON PURPOSE records the new baseline in vm/selfhost/perf-baseline/pr/6026.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 6026 --reason "<why these benchmarks moved>" perf-results.json

Result: performance regression

@shai-almog

shai-almog commented Oct 16, 2026 •

Copy link
Copy Markdown
Collaborator Author

Compared 185 screenshots: 185 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 15% (time) / 15% (RAM) away from its baseline in vm/selfhost/perf-baseline/ fails: above it is a regression, below it an improvement that has to be rebaselined (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 1.04x (base 0.93x, +11.5%) 0.92x (base 0.87x, +6.1%) ok
translator (self) 4 0.73x (base 0.70x, +5.2%) 0.47x (base 0.45x, +4.5%) ok
intArithmetic 4 1.04x (base 1.04x, -0.0%) 0.03x (base 0.03x, +0.3%) ok
longArithmetic 4 0.79x (base 0.79x, -0.2%) 0.03x (base 0.03x, -0.5%) ok
mathTranscendental 4 1.10x (base 1.10x, -0.0%) 0.03x (base 0.03x, +2.2%) ok
arraySequential 4 0.36x (base 0.36x, -1.3%) 0.37x (base 0.37x, +0.0%) ok
arrayRandom 4 0.94x (base 0.94x, +0.3%) 0.20x (base 0.20x, -0.1%) ok
objectAllocation 4 1.97x (base 1.77x, +11.4%) 0.37x (base 0.38x, -1.8%) ok
valueEscape 4 0.51x (base 0.51x, -0.1%) 0.03x (base 0.03x, -0.8%) ok
hashMapChurn 4 0.83x (base 0.84x, -1.7%) 0.13x (base 0.12x, +4.9%) ok
stringBuilding 4 1.48x (base 1.36x, +8.8%) 0.26x (base 0.26x, -0.4%) ok
recursion 4 1.42x (base 1.43x, -1.2%) 0.03x (base 0.04x, -1.5%) ok
quicksort 4 1.00x (base 0.99x, +1.0%) 0.09x (base 0.09x, +1.0%) ok

Result: no regression

@shai-almog

Copy link
Copy Markdown
Collaborator Author

@codex review

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 16, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-16T08:23:42.599347Z 1a1436f Manual request
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 120d445c7d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread Ports/LinuxPort/nativeSources/cn1_linux_text_input.c Outdated
@shai-almog

Copy link
Copy Markdown
Collaborator Author

@codex review

@shai-almog

Copy link
Copy Markdown
Collaborator Author

The failed x64 job completed its native test suite; its final performance gate flagged an improvement in hello RSS, not a regression or test failure. PR run 38855790022 measured 0.7670636× JDK RSS, just below the 0.7672 improvement threshold.

The passing mainline control 38848075973 used the same AMD EPYC 9V74 CPU model and the identical VM tree (0a5d022d2c690cbda74a461220b826fac85399ee), measuring 0.9824423× RSS. This supports measurement variance rather than an effect of the Linux input changes. No performance baseline or tolerance was changed, and no native CI job was manually rerun. The review fix is now at a99c5afa68af6174b3fa247746b3f174b34af0f3; its fresh checks are pending.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a99c5afa68

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread Ports/LinuxPort/nativeSources/cn1_linux_text_input.c Outdated
@shai-almog

Copy link
Copy Markdown
Collaborator Author

@codex review

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 72c044c94d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread Ports/LinuxPort/nativeSources/cn1_linux_text_input.c Outdated
Comment thread Ports/LinuxPort/nativeSources/cn1_linux_text_input.c
Comment thread Ports/LinuxPort/nativeSources/cn1_linux_text_input.c
@shai-almog

Copy link
Copy Markdown
Collaborator Author

@codex review

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Didn't find any major issues. Breezy!

Reviewed commit: 1a1436f3da

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@shai-almog

shai-almog commented Oct 16, 2026 •

Copy link
Copy Markdown
Collaborator Author

Compared 185 screenshots: 185 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 57ms / native 5ms = 11.4x speedup
SIMD float-mul (64K x300) java 65ms / native 5ms = 13.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 73.000 ms
Base64 CN1 decode 98.000 ms
Base64 SIMD encode 113.000 ms
Base64 encode ratio (SIMD/CN1) 1.548x (54.8% slower)
Base64 SIMD decode 99.000 ms
Base64 decode ratio (SIMD/CN1) 1.010x (1.0% slower)
Image encode benchmark iterations 100
Image createMask (SIMD off) 7.000 ms
Image createMask (SIMD on) 4.000 ms
Image createMask ratio (SIMD on/off) 0.571x (42.9% faster)
Image applyMask (SIMD off) 21.000 ms
Image applyMask (SIMD on) 22.000 ms
Image applyMask ratio (SIMD on/off) 1.048x (4.8% slower)
Image modifyAlpha (SIMD off) 27.000 ms
Image modifyAlpha (SIMD on) 19.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.704x (29.6% faster)
Image modifyAlpha removeColor (SIMD off) 30.000 ms
Image modifyAlpha removeColor (SIMD on) 70.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 2.333x (133.3% slower)

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 15% (time) / 15% (RAM) away from its baseline in vm/selfhost/perf-baseline/ fails: above it is a regression, below it an improvement that has to be rebaselined (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.42x (base 1.22x, +16.6%) 0.74x (base 0.94x, -20.8%) ok
translator (self) 4 0.74x (base 0.60x, +22.2%) 0.54x (base 0.54x, +0.1%) ok
intArithmetic 4 1.20x (base 1.10x, +8.8%) 0.06x (base 0.06x, +5.2%) ok
longArithmetic 4 1.08x (base 1.08x, -0.1%) 0.05x (base 0.05x, +1.5%) ok
mathTranscendental 4 0.77x (base 0.79x, -2.2%) 0.06x (base 0.06x, -4.0%) ok
arraySequential 4 1.34x (base 1.36x, -1.5%) 0.39x (base 0.39x, +0.1%) ok
arrayRandom 4 1.08x (base 1.06x, +1.7%) 0.23x (base 0.23x, +0.0%) ok
objectAllocation 4 1.58x (base 1.56x, +1.1%) 0.31x (base 0.39x, -20.1%) ok
valueEscape 4 0.10x (base 0.10x, +0.4%) 0.04x (base 0.04x, +1.3%) ok
hashMapChurn 4 1.80x (base 1.80x, +0.3%) 0.09x (base 0.09x, -1.9%) ok
stringBuilding 4 1.25x (base 1.22x, +2.9%) 0.32x (base 0.32x, +0.1%) ok
recursion 4 1.41x (base 1.49x, -5.8%) 0.06x (base 0.06x, -0.6%) ok
quicksort 4 1.11x (base 1.13x, -2.2%) 0.12x (base 0.12x, -0.2%) ok

Result: no regression

@shai-almog

shai-almog commented Oct 16, 2026 •

Copy link
Copy Markdown
Collaborator Author

Compared 185 screenshots: 185 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 49ms / native 3ms = 16.3x 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 78.000 ms
Base64 encode ratio (SIMD/CN1) 1.322x (32.2% 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) 2.000 ms
Image createMask ratio (SIMD on/off) 0.333x (66.7% faster)
Image applyMask (SIMD off) 23.000 ms
Image applyMask (SIMD on) 21.000 ms
Image applyMask ratio (SIMD on/off) 0.913x (8.7% faster)
Image modifyAlpha (SIMD off) 18.000 ms
Image modifyAlpha (SIMD on) 13.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.722x (27.8% faster)
Image modifyAlpha removeColor (SIMD off) 22.000 ms
Image modifyAlpha removeColor (SIMD on) 14.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.636x (36.4% 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 15% (time) / 15% (RAM) away from its baseline in vm/selfhost/perf-baseline/ fails: above it is a regression, below it an improvement that has to be rebaselined (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.12x (base 1.11x, +1.3%) 0.97x (base 0.97x, -0.2%) ok
translator (self) 4 0.86x (base 0.84x, +2.5%) 0.50x (base 0.51x, -2.4%) ok
intArithmetic 4 1.04x (base 1.04x, -0.0%) 0.06x (base 0.06x, +1.5%) ok
longArithmetic 4 0.79x (base 0.80x, -0.4%) 0.06x (base 0.06x, +1.8%) ok
mathTranscendental 4 0.71x (base 0.72x, -1.0%) 0.06x (base 0.06x, +0.3%) ok
arraySequential 4 0.37x (base 0.46x, -18.6%) 0.39x (base 0.39x, +0.1%) ok
arrayRandom 4 0.94x (base 0.94x, +0.4%) 0.23x (base 0.23x, +0.0%) ok
objectAllocation 4 1.75x (base 2.81x, -37.7%) 0.32x (base 0.43x, -24.5%) ok
valueEscape 4 0.76x (base 0.76x, +0.0%) 0.05x (base 0.05x, +2.5%) ok
hashMapChurn 4 1.00x (base 0.98x, +1.6%) 0.12x (base 0.12x, +1.6%) ok
stringBuilding 4 1.53x (base 1.43x, +7.0%) 0.27x (base 0.27x, -0.6%) ok
recursion 4 1.44x (base 1.46x, -1.4%) 0.06x (base 0.07x, -0.2%) ok
quicksort 4 1.01x (base 1.00x, +0.8%) 0.12x (base 0.12x, -0.1%) ok

Result: no regression

@shai-almog

shai-almog commented Oct 16, 2026 •

Copy link
Copy Markdown
Collaborator Author

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

Benchmark Results

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

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 55ms / native 3ms = 18.3x speedup
SIMD float-mul (64K x300) java 54ms / native 2ms = 27.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 46.000 ms
Base64 CN1 decode 52.000 ms
Image encode benchmark iterations 100
Image createMask (SIMD off) 4.000 ms
Image createMask (SIMD on) 1.000 ms
Image createMask ratio (SIMD on/off) 0.250x (75.0% faster)
Image applyMask (SIMD off) 29.000 ms
Image applyMask (SIMD on) 23.000 ms
Image applyMask ratio (SIMD on/off) 0.793x (20.7% faster)
Image modifyAlpha (SIMD off) 26.000 ms
Image modifyAlpha (SIMD on) 23.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.885x (11.5% faster)
Image modifyAlpha removeColor (SIMD off) 28.000 ms
Image modifyAlpha removeColor (SIMD on) 21.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.750x (25.0% faster)

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 15% (time) / 15% (RAM) away from its baseline in vm/selfhost/perf-baseline/ fails: above it is a regression, below it an improvement that has to be rebaselined (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.87x (base 0.96x, -9.2%) 1.25x (base 1.34x, -6.7%) ok
translator (self) 3 0.68x (base 0.62x, +8.6%) 0.57x (base 0.57x, -0.1%) ok
intArithmetic 3 1.05x (base 1.03x, +2.1%) 0.12x (base 0.12x, +0.6%) ok
longArithmetic 3 1.01x (base 1.03x, -1.2%) 0.11x (base 0.07x, +59.1%) ok
mathTranscendental 3 0.98x (base 1.01x, -2.2%) 0.12x (base 0.12x, -0.1%) ok
arraySequential 3 0.43x (base 0.42x, +2.3%) 0.53x (base 0.53x, +0.2%) ok
arrayRandom 3 0.97x (base 0.99x, -1.5%) 0.32x (base 0.32x, +0.3%) ok
objectAllocation 3 1.04x (base 1.11x, -5.7%) 0.97x (base 0.81x, +19.1%) ok
valueEscape 3 0.51x (base 0.51x, +0.1%) 0.09x (base 0.09x, -0.8%) ok
hashMapChurn 3 1.07x (base 1.18x, -9.4%) 0.07x (base 0.07x, +8.9%) ok
stringBuilding 3 0.89x (base 0.84x, +5.9%) 0.54x (base 0.46x, +16.8%) ok
recursion 3 1.21x (base 1.24x, -2.3%) 0.12x (base 0.12x, +0.7%) ok
quicksort 3 1.00x (base 1.01x, -1.0%) 0.11x (base 0.11x, +0.8%) ok

Result: no regression

@shai-almog
shai-almog merged commit f187022 into master Oct 16, 2026
48 of 53 checks passed
@shai-almog
shai-almog deleted the linux-loopback-mcp branch October 16, 2026 10:59
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.

1 participant