Most dynamic runtimes (Python, Ruby, and even JS engines) handle concurrency through Global Interpreter Locks (GIL) or complex memory barriers because managing mutable state across threads is notoriously difficult.
With ProtoCore, I took a different path based on three pillars:
Immutability by Default: All core data structures are immutable. Instead of locking, we use structural sharing for memory efficiency. This inherently eliminates data races at the object level.
Hardware-Aware Memory Model: Objects are cache-line aligned (64-byte cells) to prevent false sharing and optimize cache locality.
Tagged Pointers: We use a 56-bit embedded payload for SmallIntegers, meaning zero heap allocation for most numeric operations.
To prove the architecture, I built ProtoJS. It uses QuickJS for parsing but replaces the entire runtime with ProtoCore primitives. This allows for real worker thread execution ("Deferred") where immutable objects are shared across threads without copying or GIL-related contention.
Current Status:
ProtoCore: 100% test pass rate (50/50 tests) and a comprehensive technical audit completed today.
ProtoJS: Phase 1 complete, demonstrating real parallel execution and sub-1ms GC pauses.
I’m an Electronic Engineer by training (now a university professor), and I wanted to see if applying low-level hardware principles could fix the high-level concurrency "mess."
I’d love to hear your thoughts on the trade-offs of this immutable-first approach in systems programming.
ProtoCore (The engine): https://github.com/numaes/protoCore ProtoJS (The JS runtime): https://github.com/gamarino/protoJS
gamarino•1w ago
Key Architectural Decisions:
Immutability-First: Every core data structure is immutable by default, utilizing structural sharing to remain memory-efficient. This allows us to run without a Global Interpreter Lock (GIL).
Hardware-Aware Design: Objects are allocated as 64-byte Cells, aligned with CPU cache lines to prevent false sharing and optimize cache locality.
Tagged Pointers: We use the lower bits for type tagging, allowing 56-bit integers to be stored directly in the pointer (zero-allocation for small integers).
Concurrent GC: A dedicated GC thread handles reclamation with minimal stop-the-world pauses (typically <1ms).
To demonstrate this, I built ProtoJS. It uses QuickJS for the frontend (parsing/bytecode) but replaces the entire runtime with ProtoCore primitives. This enables a unique "Deferred" execution model where we can ship bytecode to real worker threads and share immutable state with zero-copy overhead.
Project Status: ProtoCore has just passed a full technical audit with 100% test coverage (50/50 tests) and ~5,780 LOC of production-grade C++20. ProtoJS is currently in its Phase 1 (demonstrator), successfully proving parallel execution across thread pools.
I'm a university professor and electronic engineer based in Argentina, and I'm very interested in discussing the trade-offs of this "immutable-at-the-bottom" approach for future runtime development.