Kestówv 0.5.1 — Peer Review Request

Muskogee → English: RedRoot
Muskogee → Japanese: レッドルート (Reddo Rūto)
Kestówv in katakana: ケツワ
Pronounced: Kest-oh-wa / Kist-oh-wa (Muskogee: ケツワ)

This PR is submitted for peer review of the Kestówv project.

In return for peer review, any code, logic, algorithm, or technique found here may be freely used, modified, and repurposed for the JRuby interpreter. The JRuby team developers and Headius Enterprises have full access to and utility of any Kestówv code, to use however they see fit to help improve JRuby itself.

What is Kestówv?

Kestówv is my first base for a full unified Ruby Native Machine — in the same spirit as the Lisp Machine and Smalltalk: a system where the language and the machine are designed together rather than layered on top of each other.

The JVM is not emulated hardware here — it is the hardware. JRuby's 1:1 thread mapping, System.nanoTime(), JMM §17.7 atomic double reads, heap introspection via Runtime, and System.gc() are treated as first-class architectural primitives, not implementation details to hide.

What's in this release

• Full kernel subsystem suite: MM (frame allocator, page table, slab, heap, VmRegion, CoW, OOM), Proc (Task, Pid, Credentials, Cgroup, Namespace, Exec), FS (VFS, TmpFs, HostFs, ProcFs), IPC (Pipe, Queue, Sem, Shm, Bus), Net (UnixHub, UnixSocket), Core (Wave scheduler, Klog, RunQueue, BinaryClassifier)
• Wave polyphase CPU scheduler with a live governor — distributes CPU work across threads in phase-offset sine waves to prevent thermal throttling; cooperates with the JVM GC via heap ratio monitoring
• Two-runtime live stress dashboard — JRuby kernel streams MessagePack metrics over a Unix domain socket to a CRuby ANSI TUI; 30 stress threads across all subsystems; 1.1 billion ops / 0 errors over a 30-minute soak run
• JVM heap leak resolution — five root causes identified and fixed; heap now shows a stable sawtooth GC pattern instead of monotonic growth to OOM past 300 seconds
• All IPC uses MessagePack — 4.2× faster serialisation, 1.32× smaller payloads vs. JSON

Version history context

• 0.1.0 — First Kestówv version; included the JRuby Builtins PR work
• 0.2.0–0.3.0 — JEP-380 PR work (Unix domain socket support)
• 0.5.1 — This release: full kernel, Wave governor, stable heap profile

What I'm Looking For

Any advice, tips, pointers, and feedback — especially on how to better integrate JVM features into Kestówv — is appreciated and encouraged.

Specific areas of interest:

• JVM internals that could serve as better architectural primitives
• JRuby-specific patterns or APIs worth building against
• Anything in the Wave scheduler or slab pool design worth rethinking
• Whether the two-runtime MessagePack IPC pattern has wider applicability in JRuby tooling

Running It

# Requirements: JRuby 9.4+, MRI Ruby, msgpack gem
cd Kestówv0.5.1
jruby boot/tui_stress.rb   # ANSI live dashboard (recommended)
jruby boot/tk_stress.rb    # Tk window variant

Docs: Kestówv0.5.1/docs/ — ARCHITECTURE, WAVE_SCHEDULER, MEMORY, PERFORMANCE, STRESS_DASHBOARD, IPC, BOOT_SEQUENCE.

🤖 Generated with Claude Code