Boost JavaScript Serverless Performance with Noslate’s Cloud‑Native Runtime

Since the open‑source Midway framework in 2019, Alibaba has been deeply researching Node.js, contributing to TC39, the Node.js project, and collaborating with the Dragonfly community, achieving notable results in the Serverless field.

Today we introduce Noslate, a new product designed for cloud‑native and Serverless scenarios.

What is Noslate?

Visit the project for more details: https://github.com/noslate-project/noslate

JavaScript is the most widely used programming language. With the rise of cloud‑native and Serverless architectures, elasticity and efficiency have become new design goals. Noslate aims to improve JavaScript scheduling performance in cloud‑native environments and address diagnostic black‑box issues.

Noslate consists of three sub‑projects:

Node.js Distribution – optimized Node.js builds for cold‑start reduction.

Noslate Workers – a W3C web‑interoperable lightweight JavaScript container for seamless SSR and other lightweight tasks.

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

In short, Noslate provides a complete technical solution to make JavaScript the most flexible delivery language in the cloud‑native era.

Why Open Source?

Open sourcing strengthens productization and invites community contributions, while collaboration with Alibaba Cloud’s Dragonfly community and the Anolis OS enables deeper low‑level innovations.

1. Noslate Workers

Aworker is a W3C web‑interoperable runtime offering a lightweight, near‑zero cold‑start JavaScript Serverless environment that can be easily integrated into existing architectures.

Unlike traditional FaaS, Noslate Workers run as lightweight task units on top of regular application containers, providing high‑density mixing, isolation, and near‑zero cold‑start via a task‑state copy API.

Relationship to existing architectures:

Noslate Workers consist of two main components:

Aworker – lightweight, web‑interoperable JavaScript runtime.

Noslated – Serverless‑style scheduler and controller for Aworker.

About Aworker

Aworker provides a Web API‑standard runtime suitable for business logic that does not depend on system interfaces, implementing a Service Worker‑like API with Request‑Response services.

Compared to Node.js, Aworker offers higher‑level abstractions, no leakage of low‑level state, and achieves rapid horizontal and vertical scaling via Startup Snapshot and Warmfork, enabling millisecond‑level startup and high elasticity.

Feature Highlight 1: Warmfork

Fork(2) in Linux allows a new process to inherit the parent’s state without reinitializing from main(), copying PCB, stack, memory pages, and page tables, resulting in sub‑millisecond creation.

Node.js cannot easily adopt fork due to its multithreaded design based on libuv and V8 worker threads, which involve synchronous I/O handling and a multi‑threaded GC model.

Node.js’s single‑process, multi‑thread model is illustrated below:

Aworker adopts a single‑process, single‑thread model, extracting the worker thread into an independent process, enabling fork and eliminating main() startup overhead.

To support single‑threaded execution, Aworker replaces libuv’s synchronous file operations with Linux AIO (not POSIX AIO) and uses V8’s SingleThread mode, suitable for low‑end devices and Serverless resource models.

Process isolation and management are handled by Turf, a lightweight container manager compatible with OCI, offering lower overhead than traditional runc/rund containers.

Alinode Warmfork comparison:

Warmfork creates a “seed” process that can be cloned, allowing Aworker to capture its state for rapid duplication.

Warmfork workflow:

Feature Highlight 2: Startup Snapshot

Startup Snapshot preserves user code execution state, unlike CodeCache which only stores parsed code, enabling fast restoration of the entire application state.

Limitations include memory overhead and the need for deterministic state (e.g., IP, dates) during restoration.

V8’s Startup Snapshot Serializer traverses root objects, generating bytecode that can be replayed to reconstruct heap objects and references.

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

Noslated

Noslated is the core daemon managing Noslate Workers, providing instance scheduling, elastic scaling, configuration, and traffic management.

It consists of a Control Plane and a Data Plane.

Noslated supports three instance management modes:

Basic mode – traffic‑based scaling.

Throw mode – instances are destroyed after execution.

Reserved mode – reserved for historical compatibility (details on the website).

1. Basic Mode

When traffic arrives at the Data Plane without an available Worker, a requestQueueing event notifies the Control Plane, which decides scaling based on current load. New Workers connect to the Data Plane, initialize, and start processing queued requests. Idle Workers are garbage‑collected, and resources are reclaimed via Turf.

2. Throw Mode

For highly flexible scenarios, a lightweight script is executed in an isolated instance per request and destroyed afterward, enabling high‑density mixed‑task execution without affecting other requests.

Combining Warmfork and Startup Snapshot allows near‑instant Worker startup, minimizing latency for high‑density tasks.

3. Reserved Mode

Details are available in the official documentation.

2. Noslate Debugger

Noslate Debugger is an offline analysis tool for V8 applications that examines Corefiles (core dumps) to inspect structures, stacks, heap objects, and extract heap snapshots.

Inspect Node.js/V8 structures and stacks.

Examine V8 heap objects.

Export heap snapshots from Corefiles.

Obtain Corefiles transparently via the Arthur tool.

Supports official Node.js and AWorker LTS releases.

Future integration with the Easy Monitor project will further enhance Node.js/V8 diagnostics.

Advantage 1: Corefile‑based snapshots suit Serverless – they avoid the heavy runtime impact of traditional heap snapshots, reducing diagnostic latency to seconds or milliseconds.

Advantage 2: Minimal business impact – Corefile capture adds only tens of milliseconds overhead, unlike minutes for online heap snapshots.

Arthur uses fork to minimize pause time and LZ4 compression to reduce dump size; in production it adds ~31 ms latency and produces a 338 MB Corefile from a 1.44 GB process.

3. Node.js Distribution

The custom Node.js distribution reduces cold‑start latency by up to 100‑200% through Require relationship acceleration, Bytecode Cache, and ARM‑specific optimizations.

Cold‑Start Optimization

Profile‑Guided Optimization (PGO) records hot paths during an initial run, generates a cache file, and later memory‑maps it for fast startup, achieving 100‑200% improvement.

Platform‑Specific Optimizations

While Node.js supports multiple architectures, upstream versions often lack deep optimizations for new ARM instruction sets. Noslate’s Node.js builds add SIMD‑based zlib enhancements and other ARM‑specific tweaks for Alibaba Cloud Ampere and Yitian platforms, with ongoing work for additional architectures.

Learn More

For detailed information, refer to:

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]