Repository navigation
Real-time threads: periodic SCHED_FIFO loops the collector never stops - #6138
Conversation
com.codename1.realtime runs a RealtimeTask on a thread of its own, released on an absolute clock, on PREEMPT_RT (and any) Linux and on the backend: - SCHED_FIFO priority, CPU pinning and isolation, mlockall(MCL_ONFAULT), priority-inheriting VM mutexes; statistics with a latency histogram. - The collector releases a real-time thread as soon as its stack is scanned (SATB keeps it sound) and never enters stop-the-world phases while one runs. - No allocation in a cycle: RealtimeAllocationVerifier fails the build on allocation reachable from cycle()/periodsMissed(); at run time the thread's page cache is swapped out, so an allocation the build could not see throws RealtimeAllocationError naming the class. - setMemoryLimit: ordinary threads get OutOfMemoryError instead of a struggling collector once resident memory is over the limit. - The simulator and other ports run the loop best-effort. vm/backend/demo/rtcheck is the check, run on the arm64 runner by embedded-linux.yml; developer guide chapter Realtime.asciidoc. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…e sections Red-team round 1: an allocation inside a non-zero budget refilled the budget, so only a budget of 0 was enforced (rtcheck now checks budget 2). Isolation now returns the core to the moved threads when the real-time thread ends; a virtual thread resumed from a trapped carrier gets the real page array; the RSS sample counter no longer drops bytes. Guide: parameters, life cycle, features. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…rs statistics and porting Red-team round 2: the over-budget path lifted the trap to build the error and nothing re-armed it, so a cycle catching RealtimeAllocationError allocated unchecked from then on. The trap is re-armed every period (rtcheck: catcher). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Cloudflare Preview
|
…e and IDEs - cn1:buildLinuxLocal / buildLinuxLocal, cn1:runOnDevice / cn1RunOnDevice and cn1:device-logs / cn1DeviceLogs; -Dcn1.board names the board and turns on the embedded build. - The executable survives the builder's temp dir (linux/target/linux-native). - A cross build with no cross compiler fails instead of using the host cc. - The device refuses a binary for another architecture before installing it; the service gets LimitRTPRIO/LimitMEMLOCK for real-time threads. - Archetype: build.sh/build.bat commands and IntelliJ, VS Code, NetBeans and Eclipse entries for Linux Local Build, Run on Device and Device Logs. - CI: the real-time step installs the backend; the guide's motor loop is an included, compiled snippet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…r commands Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Developer Guide build artifacts are available for download from this workflow run:
Developer Guide quality checks: |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
✅ ByteCodeTranslator Quality ReportTest & Coverage
Benchmark Results
Static Analysis
Generated automatically by the PR CI workflow. |
Flutter vs Codename OneSame 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. android9 interleaved rounds; host load 1.32, 2.03, 1.67
Compute -- the VM workloads (
Gate: within tolerance against
ios9 interleaved rounds; host load 36.14, 35.02, 26.57
Compute -- the VM workloads ( 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
javascript9 interleaved rounds; host load 2.4, 1.2, 0.48
Compute -- the VM workloads (
Gate: within tolerance against
linux9 interleaved rounds; host load 0.82, 3.23, 2.83
Compute -- the VM workloads (
Gate: within tolerance against
macos9 interleaved rounds; host load 5.06, 15.11, 17.72
Compute -- the VM workloads (
Gate: within tolerance against
windows9 interleaved rounds
Compute -- the VM workloads (
Gate: within tolerance against
Codename One wins 26 of 26 measured metrics across 6 platform(s). |
|
Compared 195 screenshots: 195 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
|
Compared 231 screenshots: 231 matched. |
# Conflicts: # scripts/initializr/common/src/main/resources/common.zip
A real-time thread that wakes while the collector scans its stack waits for the scan, and the collector is an ordinary thread that the busy threads can preempt inside that window. CI caught one 125ms stall of a 1kHz loop whose cycle never ran past 4us. The collector now runs SCHED_FIFO just under the held thread from raising its block to releasing it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
cmd.exe finds a goto label by re-reading the batch file in 512-byte blocks, and in an LF-only file it can miss a label that straddles a block boundary. The device targets moved one onto a boundary and `build.bat javascript` ran the android target on Windows. The archetype stores both launchers as CRLF, as mvnw.cmd already is, the Initializr zip carries them that way, and the telemetry injection matches its markers on LF and writes CRLF back. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Both class examples used `...` for the parts they left out, and the RealtimeTask one read I2C through a method that does not exist -- every I2C read returns a new array, which a cycle must not do. The task example is now the guide's motor loop, and the Realtime one passes a minimal task inline. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Compared 210 screenshots: 210 matched. Benchmark ResultsDetailed Performance Metrics
|
|
Compared 210 screenshots: 210 matched. Benchmark ResultsDetailed Performance Metrics
ParparVM vs HotSpot (JDK 25): Windows x64Runner CPU: AMD64 Family 25 Model 1 Stepping 1, AuthenticAMD (baseline 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
Result: no regression |
|
Compared 196 screenshots: 196 matched. Benchmark Results
Detailed Performance Metrics
ParparVM vs HotSpot (JDK 25): macOS arm64Runner CPU: Apple M1 (Virtual) (baseline 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
Result: no regression |
|
Compared 210 screenshots: 210 matched. Benchmark ResultsDetailed Performance Metrics
ParparVM vs HotSpot (JDK 25): Windows arm64Runner CPU: ARMv8 (64-bit) Family 8 Model D49 Revision 0, MICROSOFT CORPORATION (baseline 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
Result: no regression |
|
Compared 210 screenshots: 210 matched. ParparVM vs HotSpot (JDK 25): Linux x64Runner CPU: AMD EPYC 7763 64-Core Processor (baseline 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
Result: no regression |
|
Compared 210 screenshots: 210 matched. ParparVM vs HotSpot (JDK 25): Linux arm64Runner CPU: Neoverse-N2 (baseline 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
Result: no regression |
|
Compared 192 screenshots: 192 matched. Benchmark Results
Detailed Performance Metrics
|























Adds
com.codename1.realtime: periodic real-time threads for control loops on (PREEMPT_RT) Linux, the embedded port and the backend.SCHED_FIFOpriority, CPU pinning plus isolation (the core is given back when the thread ends),mlockall(MCL_ONFAULT), and priority-inheriting VM mutexes. Release is on an absolute clock, with missed-period reporting and latency/execution statistics plus a histogram.RealtimeAllocationVerifierfails the build on allocation reachable fromcycle()/periodsMissed(), unless it is marked@AllocationAllowed.RealtimeAllocationErrornaming the class. Per-period budgets are supported, and the check is re-armed each period, so it stays on even if the cycle catches the error itself.setMemoryLimit: ordinary threads getOutOfMemoryErrorinstead of a stalled collector. The limit is measured on resident memory, after collections and on the allocation slow path.Realtime.asciidoc, linked from Embedded Linux.vm/backend/demo/rtcheckruns inembedded-linux.ymlon the arm64 runner, as root. It covers latency under GC churn, the hidden-allocation trap, budgets, a cycle that catches the error, and the memory limit. The latency bound is loose (20ms) because runners are not PREEMPT_RT.Verified locally on macOS and in an arm64 Linux container: rtcheck passes. The SpotBugs, PMD, cast-semantics, header, ASCII and control-character gates pass, and
RealtimeAllocationVerifierTestpasses 7/7.🤖 Generated with Claude Code