How Noslate Boosts JavaScript Performance for Cloud‑Native Serverless Apps

What is Noslate?

Noslate is a cloud‑native project aimed at improving the scheduling performance of JavaScript in serverless scenarios and solving diagnostic black‑box issues.

It consists of three sub‑projects:

Node.js Distribution – a custom Node.js build optimized for cold‑start in function‑compute.

Noslate Workers – a W3C Web‑interoperable lightweight JavaScript container (Aworker) with a scheduler (Noslated) for near‑zero cold start.

Noslate Debugger – an offline diagnostic tool based on Linux Corefile to trace and locate issues.

The overall goal is to make JavaScript the most flexible delivery language in the cloud‑native era.

Why Open Source?

Open‑sourcing strengthens productization and invites community contributions to refine the design.

Noslate Workers

Aworker provides a lightweight, near‑zero‑cold‑start JavaScript runtime that can be integrated into existing architectures.

It runs as a lightweight task unit above ordinary application containers, offering high‑density mixing, isolation, and near‑zero cold start via a task‑state copy API.

Components:

Aworker – lightweight, Web‑interoperable JavaScript runtime.

Noslated – serverless‑style scheduler and controller for Aworker.

About Aworker

Aworker implements Web API‑compatible Request‑Response services and uses Startup Snapshot and Warmfork to achieve millisecond‑level startup and high elasticity.

Feature Highlight 1: Warmfork

Warmfork leverages the Linux fork(2) semantics: the child inherits the parent’s state, memory pages are copied via Copy‑On‑Write, and process creation is sub‑millisecond.

Unlike Node.js, which cannot hold all multithreaded state in the main thread, Aworker runs a single‑process, single‑thread model and extracts the worker thread into an independent process, enabling fork and fast startup.

To manage these lightweight processes, the Turf container component creates new Aworker service processes via Warmfork, providing resource and environment isolation while remaining OCI‑compatible.

Feature Highlight 2: Startup Snapshot

Startup Snapshot captures the full execution state of user code, unlike CodeCache which only stores parsed code.

It serializes the V8 heap objects and their relationships into bytecode, allowing rapid restoration of the heap and global state.

These state‑copy APIs are documented in the official “State Copy API” chapter.

Noslated

Noslated is the control daemon for Noslate Workers, handling instance scheduling, elastic scaling, configuration, and traffic management.

It consists of a Control Plane and a Data Plane.

Instance management modes:

Basic mode – traffic‑driven scaling.

Throw‑away mode – instance terminates after execution.

Reserved mode – compatibility for historical scenarios.

1. Basic Mode

When traffic arrives and no worker can handle it, the Data Plane notifies the Control Plane, which scales out based on load. Idle workers are garbage‑collected and resources reclaimed.

2. Throw‑away Mode

For one‑off lightweight scripts (e.g., high‑density SSR), a fresh instance is created per request and destroyed after execution, leveraging Warmfork and Startup Snapshot for rapid startup.

3. Reserved Mode

Details are available in the official documentation.

Noslate Debugger

Noslate Debugger is an offline analysis tool for V8 applications that processes Corefiles (core dumps).

Inspects structures, stacks, and heap objects.

Exports heap snapshots.

Collects Corefiles transparently via the Arthur tool.

Supports Node.js and AWorker LTS releases.

By using Corefile snapshots, debugging incurs minimal impact on serverless workloads, reducing latency from minutes to seconds or milliseconds.

Corefile (GNU Corefile format) records a process’s memory and registers, serving as a complete snapshot for offline analysis.

Arthur captures Corefiles with low pause time (≈31 ms) and compresses them with LZ4, resulting in a 338 MB file for a process that originally used 1.44 GB of RAM.

Node.js Distribution

The custom Node.js build optimizes for elastic scenarios, accelerating module loading and bytecode caching, achieving 100‑200% cold‑start improvements, and includes ARM‑specific performance enhancements.

Cold‑Start Optimization

Profile‑Guided Optimization (PGO) records hot paths during an initial run and generates a cache file that is memory‑mapped on subsequent starts, doubling startup speed.

Platform‑Specific Optimizations

For ARM architectures, the distribution adds SIMD‑based zlib improvements and other optimizations, targeting Alibaba Cloud Ampere and Yitian platforms.

Learn More

GitHub: https://github.com/noslate-project/noslate

Website: https://noslate.midwayjs.org/

Dragonfly Community SIG: https://openanolis.cn/sig/web-platform

Mailing list: [email protected]

Acknowledgments

Thanks to Alibaba internal teams and contributors such as legendecas, mariodu, zhaolei0505, XadillaX, umuoy1, oraluben, hyj1991, etc.