Context & Technical Highlights
I’ve been exploring the intersection of low-level hardware constraints and high-level dynamic runtimes. The goal with ProtoCore was to build a system where concurrency isn’t an afterthought, but a result of the memory model itself.
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.
The short pauses are a direct consequence of the immutable-by-default model. Once we collect the roots from thread stacks and global data during a brief Stop-The-World (STW) phase, those objects will not be modified by user threads. This allows the GC thread to perform the marking and sweeping phases in parallel with application threads without needing complex write barriers or locks.
Regarding mutability and cycles:
All mutable objects are managed through a centralized structure whose root is scanned during the STW phase.
Even this internal tracking structure uses immutable tree patterns, ensuring that once the GC starts its parallel phase, the pointers it is traversing remain stable.
Cycles are indeed possible in the object model, and the Mark-and-Sweep algorithm handles them naturally, ensuring that big systems with complex interactions don't leak memory.
The goal was to eliminate the standard synchronization overhead (locks/barriers) by leveraging the fact that 99% of the object graph is immutable and hardware-aligned.
What are the implications for an average Joe ruby/js developer if this matures to production grade? Could you explain like Im 5?
Context & Technical Highlights I’ve been exploring the intersection of low-level hardware constraints and high-level dynamic runtimes. The goal with ProtoCore was to build a system where concurrency isn’t an afterthought, but a result of the memory model itself.
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.
Clicky: https://github.com/numaes/protoCore https://github.com/gamarino/protoJS
> ProtoJS: Phase 1 complete, demonstrating real parallel execution and sub-1ms GC pauses.
Is it a moving GC or a non-moving GC? IIRC Golang use a non-moving GC to make pauses very short.
Is it possible to create cycles? I think I didn't use cycles since a long time ago, but it's useful for big systems with a lot of interacting objects.
It is a non-moving GC.
The short pauses are a direct consequence of the immutable-by-default model. Once we collect the roots from thread stacks and global data during a brief Stop-The-World (STW) phase, those objects will not be modified by user threads. This allows the GC thread to perform the marking and sweeping phases in parallel with application threads without needing complex write barriers or locks.
Regarding mutability and cycles:
All mutable objects are managed through a centralized structure whose root is scanned during the STW phase.
Even this internal tracking structure uses immutable tree patterns, ensuring that once the GC starts its parallel phase, the pointers it is traversing remain stable.
Cycles are indeed possible in the object model, and the Mark-and-Sweep algorithm handles them naturally, ensuring that big systems with complex interactions don't leak memory.
The goal was to eliminate the standard synchronization overhead (locks/barriers) by leveraging the fact that 99% of the object graph is immutable and hardware-aligned.