TL;DR
Fabrice Bellard published MicroQuickJS, a compact JavaScript engine designed for embedded systems that can run with as little as 10 kB of RAM and about 100 kB of ROM on ARM Thumb-2. The engine implements a subset of JavaScript near ES5, uses a tracing compacting garbage collector, and exposes a C API tailored to operate inside a provided memory buffer.
What happened
MicroQuickJS (MQuickJS) is a new, minimalist JavaScript runtime aimed at constrained devices. The implementation can execute scripts using very small memory footprints — examples show programs running with a 10 kB heap and the whole engine fitting in roughly 100 kB of ROM on ARM Thumb-2. It supports a stricter subset of JavaScript largely compatible with ES5 and disables several dynamic or error-prone features (for example, no value boxing, no with, arrays cannot have holes). The runtime offers a command-line REPL (mqjs) with options for evaluating code, saving bytecode, and restricting memory. Bytecode can be emitted for different word sizes and run directly from persistent storage after relocation. Internally, MQuickJS employs a tracing, compacting garbage collector, stores strings in UTF-8, avoids using the system malloc family, and provides a C API where callers supply the memory buffer for allocations.
Why it matters
- Enables running JavaScript on highly constrained embedded platforms with very low RAM and ROM requirements.
- A stricter language subset reduces runtime complexity and limits error-prone behaviors, which can be advantageous in embedded contexts.
- Bytecode output and ROM-resident standard library make fast startup and persistent deployment on read-only storage practical.
- The compacting GC and internal allocator reduce fragmentation, potentially improving long-running behavior on devices without OS-level memory management.
Key facts
- Reported minimum RAM usage for running programs: about 10 kB.
- Whole engine ROM footprint example: roughly 100 kB (ARM Thumb-2 code), including the C library.
- Language support: a stricter subset close to ES5 with selected ES5+ extensions; some constructs and features are forbidden.
- Memory model: engine uses its own allocator and a tracing, compacting garbage collector instead of reference counting.
- The VM does not rely on the CPU call stack for execution and stores strings internally in UTF-8.
- REPL binary is named mqjs and supports options like –memory-limit, -o to emit bytecode, and -m32 to force 32-bit bytecode.
- Bytecode depends on CPU endianness and word length; -m32 generates 32-bit bytecode for 32-bit targets.
- C API requires the caller to provide a memory buffer when creating a JSContext (no malloc/free used by the engine).
- Standard library is precompiled into C structures that can reside in ROM, minimizing runtime RAM usage.
- Bytecode is not guaranteed to be backward compatible and is not verified before execution; run only trusted bytecode.
What to watch next
- Potential ecosystem adoption by microcontroller and other embedded-device projects, and how tooling evolves to support it (not confirmed in the source).
- Whether future releases expand JavaScript coverage beyond the current ES5-focused subset (not confirmed in the source).
- Compatibility and deployment practices around bytecode given the lack of backward-compatibility guarantees and no bytecode verification.
Quick glossary
- REPL: Read-Eval-Print Loop — an interactive shell that reads user input, evaluates it, and prints the result.
- Bytecode: A low-level, platform-dependent representation of compiled code that a virtual machine can execute.
- Tracing compacting garbage collector: A GC approach that identifies live objects by tracing references and moves them to eliminate fragmentation and reduce memory overhead.
- ROM: Read-only memory or storage where code or data can be permanently stored and executed from in embedded systems.
- Strict mode (JavaScript): A language mode that enforces a subset of JavaScript semantics and disallows certain dynamic or unsafe language features.
Reader FAQ
Does MicroQuickJS implement modern ES6+ features?
No. The engine targets a stricter subset close to ES5 with a few selected extensions; broader ES6+ support is not confirmed in the source.
Can it run on 32-bit embedded targets?
Yes. The mqjs tool can emit 32-bit bytecode using -m32 so bytecode can run on 32-bit systems, and bytecode format depends on endianness and word length.
Does the engine use system malloc/free and standard C IO?
No. MQuickJS implements its own allocator and avoids using malloc(), free(), or printf(); the host must supply a memory buffer for the JSContext.
Is it safe to run arbitrary bytecode produced elsewhere?
No. The bytecode is not verified before execution and there is no backward compatibility guarantee; the source advises running only trusted bytecode.
MicroQuickJS Introduction MicroQuickJS (aka. MQuickJS) is a JavaScript engine targetted at embedded systems. It compiles and runs JavaScript programs using as little as 10 kB of RAM. The whole engine…
Sources
Related posts
- Bridge Anonymization: Local, reversible PII scrubber for translation pipelines
- Google TV Streamer drops to $80, undercutting its $100 launch price
- First clear images and specs surface for OnePlus Turbo smartphone