The --layouts padding object was linked directly before the program
object. The runtime is linked before the program object, so every layout
moved only the program's code and left each runtime function at the same
address. A change to the runtime's code size then moved its functions in
all layouts at once, and the verdicts could not tell that placement
change from a real one.
The padding object now goes before every other input on the link line,
so each layout shifts the runtime and the program code.
The macOS lane of pull requests and pushes to main runs the darwin suite in
three slices. Each slice runs differential.test.ts over a third of the
corpus while the darwin contracts run beside it. vitest runs one file's
cases in sequence, so a slice's corpus time is the sum of its case times:
in three green main runs, 587-891 s (plain) and 800-1,731 s (sanitized),
on 3-core runners whose contracts task ends after 46-180 s.
ciTestPlan now runs slice i of n as case shards 2i-1 and 2i of 2n in two
vitest processes: the first beside the side queue, the second in the side
queue after the darwin contracts. The halves of all slices are the case
shards of 2n slices, so every program still runs once.
The comment above darwinFiles now says which macOS suite each CI event
runs: pull requests and pushes to main run the darwin suite, and the
nightly schedule and manual runs with macos_full run the full suite.
tests/harness/effect-costs.json and effect4-costs.json were recorded on
2026-10-01 and give the fixtures' relative cost for balancedShardSelect
across the 16 Effect shards of each flavor. Against the fixture times of
three green main runs (38851650148, 38851726594, 38852266290), the old
tables put 1,171 s of plain and 1,295 s of sanitized fixture time on the
longest shard, against a mean of 1,027 and 1,111 s.
scripts/ci-effect-costs.mjs refreshes both tables from Effect job logs:
each fixture's plain and sanitized medians, summed in seconds, as the
tables recorded before. Fixtures without a measurement keep their value,
and fixtures that no longer exist are removed. With the refreshed tables,
the longest shard of the same measurements carries 1,082 s (plain) and
1,144 s (sanitized).
self-hosting-native-frontend.test.ts was one test of 577 s (plain) and 607 s
(sanitized) in the cost table, and 748 s on san 1/20 in run 38835202089; once
the other long files were spread, it alone bounded the Linux test lane. It
builds the compiler frontend into a native executable, then checks 17 corpus
programs and four other cases with it. Locally the build took about 189 s and
the checks 297 s (14-20 s per program).
The build and the checks move to tests/harness/native-frontend.ts without
changes to what they check; useNativeFrontend builds the executable in a
beforeAll of the calling suite. self-hosting-native-frontend.test.ts,
-programs.test.ts and -checks.test.ts each build once and run programs 1-6,
7-12, and 13-17 plus the four other checks, each check as its own test. The
diagnostics, library contract and FFI checks use project directories of their
own instead of rewriting one shared main.ts.
scripts/ci-test-costs.json replaces the old file's entry with estimates for
the three files (the build share of its measured cost plus each file's share of
the checks); the next refresh measures them, since vitest's file time includes
beforeAll. The largest side-queue share per shard at 20 shards goes from 580 to
367 s (plain) and from 608 to 432 s (sanitized), for two more builds per flavor.
npm-static.test.ts ran whole on one shard as an isolated suite: 406 s plain and
519 s sanitized in the cost table, and 672 s on san 2/20 in run 38835202089,
the second-longest job of that run.
skipUnownedTest (tests/harness/shard.ts), called from the suite's beforeEach,
balances the suite's tests across the shards of SCRIPTC_TEST_SHARD by their
measured milliseconds (tests/harness/npm-static-costs.json; an unmeasured test
weighs as much as the median) and skips the tests this shard does not own.
Repeated test.each titles get an occurrence suffix as their key. Without a
shard spec every test runs.
The CI plan runs the suite on every shard in its own vitest process
(caseShardedSideFiles) instead of on one owner. At 20 shards the largest
shares are 113 and 106 s plain and 181 and 137 s sanitized (the two published
Effect generator tests), and about 10 s elsewhere, plus about 11 s per shard to
collect the file. scripts/ci-test-costs.mjs also refreshes the per-test table
and drops side-queue files that no longer run whole.
The differential and llvm-differential corpus split their programs across the ten Linux test shards by a hash of
the program's name, so a shard's share of the measured work varied from 565 to 913 s (plain) and 868 to 1358 s
(sanitized). corpusSelect assigns programs longest first to the lightest shard by their measured cost per flavor
(tests/harness/corpus-costs.json: the differential plus llvm-differential milliseconds on a CI runner, medians of
four green main runs), giving 740-741 s and 1098-1099 s. Both harnesses still select identically, so a shard's
compile cache serves both. Programs without a measurement weigh as much as the median one.
scripts/ci-corpus-costs.mjs refreshes the table from downloaded CI shard logs.
The npm case fixtures lost their only native test with the native-only
compilation change. tests/harness/npm.test.ts runs every case again with the
default static npm compile and compares it with Node. A KNOWN table records
the cases the compile refuses (with the diagnostic code), the cases whose
run reaches a deferred refusal (the code in the program's output), and the
two that still diverge, which run as expected failures. The suite joins the
case-sharded CI corpus files.
Fixes from the run:
- A package imported only by subpath (`pkg/env.js` from a package with no
"main", "exports" or index file) was refused as having no runtime entry.
Eligibility now resolves the imported specifier when the root has none.
- diagnostics_channel: a throwing subscriber stopped publish, and a
throwing bindStore transform stopped runStores. Node runs the remaining
subscribers, skips that store, and reports each error as uncaught on a
next tick; the runtime now does the same.
- A '#' import that the package's "imports" field maps to another package
failed at run time with Node's "not defined" error, which Node does not
raise. It is now a compile-time SC1010 refusal.
- An uncaught runtime refusal whose code is an SC code now names the code.
- Mapping a type in the optional array-element analysis could lower an
unsupported local class and let its PoisonError escape as a compiler
crash; the analysis now treats that element ABI as unknown, so the
program fails with the recorded diagnostic.
- A lexical module binding initialized from an unchecked array element
holding a function failed validation (SC9001): its widened storage was a
union, which a TDZ guard cannot hold. Such bindings now keep checked-value
storage and their guard.
- A dynamically reached ArrayBuffer had no constructor property.
scr_runtime.h now includes 48 module headers (scr_core.h, scr_rc.h,
scr_string.h, scr_dyn.h, scr_http.h, ...) in dependency order and holds no
declarations. Each module header holds whole sections of the former file,
includes the headers whose names it uses, and compiles on its own.
Declarations, macros, struct layouts and inline bodies are unchanged. Five
blocks move to join their module: the class-hierarchy vtable header (into
scr_error.h, after the string core), the node:timers/promises pair (into
scr_async.h), the JSON.parse entry points and the JSON output buffer (into
scr_json.h, after the dyn declarations) and the EventTarget block (after
scr_json.h). No moved block uses or declares a name that a block it moves
past uses or declares. The string methods keep their position after the
class objects in scr_string_methods.h, because their struct ScrDyn
parameters rely on the file-scope struct ScrDyn declaration there.
The runtime ABI scan reads scr_runtime.h with its module headers expanded
in include order. A runtime test compiles every module header on its own.
scripts/runtime-header-hunks.mjs retargets a diff of the single-file
header onto the module headers.
The localeCompare table now covers U+0363-U+036F, U+00BC-U+00BE and
U+2044 FRACTION SLASH, so strings containing them follow Node's collation
instead of code-point order. A combining Latin letter is its letter's
primary at the letter's secondary, with a tertiary weight between the
letter's case forms where Node places it, and the combining class it
shares with the diacritics it reorders with. A vulgar fraction is the
elements of its compatibility decomposition (1, U+2044, 4), each with the
tertiary weight Node places the fraction at among that position's forms,
so it orders after both 1⁄4 and ¹⁄4. The generator's check adds the
fractions' slash and superscript spellings and the combining letters
around each diacritic. SC6003 and the limitations page describe the new
coverage.
The generated lookup indexes one dense table for every code point below
U+0370, with the gaps between ranges marked uncovered, and checks the
ranges above it (now U+2044) after that, so a Latin lookup is one
comparison instead of up to four.
The generated localeCompare table now agrees with Node on spellings that
tie at the primary and secondary levels. "l·" and "L·" collate as one
unit, equal to U+0140 and U+013F, through a contraction table. Precomposed
characters take their decompositions' elements after the case weights are
assigned, so U+0130 equals I + U+0307. Ligatures whose spelled-out letters
tie with them (ij and ij) get the case weight Node places them at among
their first letter's case forms, and ligatures with their own secondary
(Æ) keep their own case. The generator's check now also compares every
covered character's decompositions, case forms and ligature spellings in
four contexts. A per-thread class table lets the lazy primary comparison
find characters that need element lists with one lookup.
The pull request macOS lane runs the darwin suite: the differential corpus
plus every file whose assertions take darwin-specific branches. The library
suites (library-multi, library-callbacks, library-dispatch) take the Mach-O
localization and link arms on darwin, and the runtime string oracle checks
the arm64 parseInt answers, but none of them were in the list, so changes
that broke them on macOS reached main before a macOS run saw them. Add the
four files to darwinFiles.
LLVM 22 CMake exports reference the Polly libraries, so building the LLVM helper in a sandbox started from vercel/sandbox/universal fails without libpolly-22-dev. Custom images that already contain it are unaffected.
sync-versions stamps packages/threads with the CLI version (0.2.7 now),
the release workflow checks that version and publishes the package
before scriptc, and RELEASING.md lists it with the packages that always
release together. npm trusted publishing must be configured for
@scriptc/threads before the next release: a package without it fails
before upload.
Speed is a third native optimization posture next to release (default,
-O2) and dev (-O0). It is optimized exactly like release at the C/LLVM
level and is the switch for optimizations that trade executable size and
build time for run-time speed, so the default release build stays inside
the binary-size budget.
- backend/optimization.ts: the NativeOptimization type, its -O class, and
cache-key helpers. Release keeps its historical key shapes (absent).
- CLI: build/run/cache warm accept speed; usage text names the trade.
Bootstrap's routed executable cache mirrors the posture.
- Early executable cache keys and native-feature validation include speed,
so release, dev, and speed entries never satisfy one another.
- Runtime packs: an optional executable `speed` flavor (-O2, only beside
release). Speed links it when present and the release objects otherwise;
library modes link their release flavor. The sanitizer lane follows the
same flavor key.
- Library profiles accept "speed".
- WASI release-only linker flags apply to speed too.
- bench-runtime: --baseline-optimization/--candidate-optimization and a
per-contender cold_build_ms.
Release executables are byte-identical to the stack tip for all 14
benchmark workloads (macOS arm64, sha256 of executables built from both
trees).
The suite only had single-process CPU workloads. Add the two largest
real-world categories:
- http-api (kind "server"): a node:http JSON API in the static subset
(routing, query parsing, seeded catalog, per-cart state, typed JSON
bodies, ETag/If-None-Match, auth and request-id headers), driven by
clients/http-load.mjs, a raw-socket keep-alive HTTP/1.1 load client
that is identical for every server. 64 connections, 2 client threads,
4,000 untimed warmup and 40,000 measured requests on loopback. The
per-connection request schedule is seeded and server state is
partitioned per connection, so the response digest is deterministic.
Correctness compares server stdout, server stderr (minus the PORT
line), exit status, and client stdout with Node byte-for-byte. The
timed sample is the measured-phase wall time; a second table reports
req/s, p50/p90/p99 latency, client CPU, and peak RSS.
- cli-config (process, launches: 20): a deploy-plan CLI that reads a
~110 KB JSON manifest, validates, interpolates env values, and orders
80 services into dependency waves. Each sample is the median of 20
launches, so startup dominates.
The runner stays backward compatible: process workloads behave as
before, the JSON report keeps its fields and adds kind, launches,
category, server, node_peak_rss_bytes, and geomean_vs_node_by_category,
and the summary prints per-category geomeans (cpu, startup, server).
Node is the reference the project aims to beat. A single cold oracle
launch overstated its time; it is now warmed and sampled in the same
interleaved loop as the compiled executables, and the report adds a
per-workload candidate/Node ratio and its geomean. --no-node skips it.
Fourteen application-shaped workloads (JSON, regex, parsing and class
dispatch, sorting, rendering, collection pipelines, async fan-out,
Map/Set graphs, allocation, numeric kernels, exceptions, CSV, and the
two multi-module build benchmark apps on large inputs).
bench:runtime builds each workload with one or two checkouts, refuses to
time any executable whose stdout, stderr, or exit status differs from
Node, interleaves baseline and candidate launches, and reports medians
with bootstrap 95% confidence intervals, binary size, and peak RSS.
- Preserve callback identity, receiver binding, and class references across unions and collections.
- Track record field presence independently of undefined values and improve native runtime behavior.
- Expand differential coverage and streamline CI bootstrap and compiler rebuild checks.
- Add native worker execution with isolated module state, structured messages, and lifecycle controls.
- Support shared buffers and integer atomics with coordinated runtime ownership and cancellation.
- Extend compiler, runtime-pack, differential, and compatibility coverage for native concurrency.
- Split builtin lowering into focused API owners and keep module dispatch separate.
- Share byte conversion, receiver checks, and filesystem option parsing; remove redundant forwarding and clarify names.
- Preserve compiler output and diagnostics, with import boundaries enforced by the code-quality checks.
- Enforce oxlint and oxfmt for owned JavaScript and TypeScript with independent CI checks.
- Preserve compiler import boundaries and protected fixtures while cleaning up lint findings.
- Standardize source formatting and validate import, fixture, and embedded-source protections.
- Run command and self-rebuild checks independently in both validation lanes.
- Preserve complete local coverage and native package installation checks.
- Reject invalid phase selection and verify the CI matrix retains every contract.
Chris Tate