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.
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.