worker_threads: a worker never runs module init (`__perry_init_done_*` is process-wide), so it aliases the spawning thread's heap — object literals read back property-less (OpenCode TUI wall)

[proggeramlug]

Summary

A worker_threads worker does not get a fresh instance of the modules it imports. It sees the main thread's module-level bindings, including mutations the main thread already made — but not, apparently, everything those bindings point at. A memoizing closure therefore ends up with its "already computed" flag set and its cached value missing, and returns undefined forever.

Per the Node/Web worker model each worker has its own module registry and evaluates its own copy of the graph. bun does exactly that.

This is the OpenCode TUI wall, and the whole chain follows from it (see the end).

Reproducer

mod.ts — lazy is copied verbatim from opencode/packages/opencode/src/util/lazy.ts:

// @ts-nocheck
export function lazy(fn) {
  let value
  let loaded = false
  const result = () => { if (loaded) return value; value = fn(); loaded = true; return value }
  result.reset = () => { loaded = false; value = undefined }
  return result
}
export let counter = 0
export function bump() { counter++; return counter }
let initCount = 0
export const getLazy = lazy(() => { initCount++; return { made: "made", initCount } })
export function peekInit() { return initCount }

w.ts (worker):

// @ts-nocheck
import { parentPort } from "node:worker_threads"
import { getLazy, bump, counter, peekInit } from "./mod.js"
const say = (m) => { try { process.stderr.write("MS WORKER " + m + "\n") } catch {} }
say("counter seen at entry = " + counter)
say("peekInit at entry = " + peekInit())
say("getLazy() = " + JSON.stringify(getLazy()))
say("peekInit after = " + peekInit())
say("bump() = " + bump())
parentPort?.postMessage({ done: true })

main.ts:

// @ts-nocheck
import { Worker } from "node:worker_threads"
import { getLazy, bump, peekInit } from "./mod.js"
const say = (m) => { try { process.stderr.write("MS MAIN " + m + "\n") } catch {} }
say("getLazy() = " + JSON.stringify(getLazy()))
say("peekInit = " + peekInit())
say("bump() = " + bump())
say("bump() = " + bump())
const w = new Worker(new URL("./w.ts", import.meta.url))
const t = setTimeout(() => { say("TIMEOUT"); process.exit(3) }, 10000)
w.on("message", () => { clearTimeout(t); say("done"); process.exit(0) })

Measured (perry @ v0.5.1579 + local fixes, --platform bun, vs bun 1.3.14)

Main thread runs first and mutates the module: getLazy() memoizes, bump() twice.

#	cell	bun	perry
1	MAIN getLazy()	{"made":"made","initCount":1}	same	ok
2	MAIN peekInit()	1	1	ok
3	MAIN bump(), bump()	1, 2	1, 2	ok
4	WORKER counter at entry	0	2	✗
5	WORKER peekInit() at entry	0	1	✗
6	WORKER getLazy()	{"made":"made","initCount":1}	undefined	✗
7	WORKER peekInit() after	1	2	✗
8	WORKER bump()	1	3	✗

Cells 4, 5 and 8 show the worker observing the main thread's mutations: a fresh module would start at 0 and bump() would return 1.

Cell 6 is the damaging one. loaded reads as true in the worker (inherited), so lazy takes its if (loaded) return value path — but value comes back undefined. The memo is half-inherited: the flag crossed, the payload did not. Cell 7 confirms the factory then ran anyway (initCount went 1 → 2) while the caller still received undefined.

So it is not simply "state is shared": it is shared inconsistently, which is worse than either isolation or full sharing, because correct memoization code silently yields undefined.

Why this is OpenCode's blank TUI

worker imports Server
  -> Server.Default()  is  lazy(() => { const handler = HttpApiApp.webHandler().handler; ... })
  -> HttpApiApp.webHandler()  is  lazy(() => HttpRouter.toWebHandler(routes, ...))
  -> in the worker, webHandler() returns undefined     (this bug)
  -> `.handler` throws "Cannot read properties of undefined (reading 'handler')"
  -> the RPC handler in cli/tui/worker.ts rejects
  -> worker.ts installs no-op `unhandledRejection` / `uncaughtException` handlers,
     so the rejection is swallowed and no RPC reply is ever sent
  -> every SDK call from the TUI hangs; Sync's bootstrap() never completes
  -> store.status stays "loading", so Sync's `ready` getter stays false
  -> createSimpleContext renders `<Show when={init.ready === undefined || init.ready === true}>`,
     which withholds all 27 nested providers
  -> render() resolves, paints nothing, throws nothing: a blank screen with no error

Confirmed against the real modules at each step: a minimal driver importing OpenCode's real Server and calling Server.Default().app.fetch(request) inside a worker gives

BUN  worker: app.fetch RESOLVED status=200   (2884-byte body)
PER  worker: THREW "Cannot read properties of undefined (reading 'handler')"

while perry's main thread reports typeof d.app.fetch === "function" and d.app keys=fetch,request, identical to bun.

Expected

Each worker should evaluate its own copy of the module graph: cells 4, 5 and 8 should read 0, 0, 1, and getLazy() should compute fresh in the worker rather than returning a half-inherited memo.

If full per-worker module instantiation is a large change, the half-inherited case is the urgent part — a closure variable whose sibling in the same closure did not cross is a silent-wrong-answer bug, not a performance or semantics trade-off.

Note

This is distinct from #10394 (async handlers never resuming after await). Both are real; OpenCode dies on this one first, before it ever reaches an await that needs resuming. I have corrected the OpenCode attribution on #10394 accordingly.

[proggeramlug]

Where the sharing comes from, and why the "half-inherited" symptom follows

Two facts from the tree, so this can be scoped rather than guessed at:

1. Module-level bindings are process-wide. crates/perry-codegen/src/codegen/module_globals_emit.rs emits each module-level binding via add_global with no thread-local attribute — there is no thread_local anywhere in that file. So one LLVM global backs the binding for every thread in the process.

2. The worker does not re-initialize an already-initialized module. In the reproducer the worker sees counter === 2 rather than 0, so export let counter = 0 never re-ran for the worker; it inherited the main thread's storage and the mutations applied to it.

Together those explain the damaging cell exactly. lazy's loaded and value are two closure variables. loaded is reached through the shared module global and reads true. value is a heap reference whose object does not resolve the same way from the worker, so it reads undefined. lazy then takes if (loaded) return value and hands back undefined — while initCount going 1 → 2 shows the factory subsequently ran anyway. Nothing throws; a correct memo silently yields nothing.

What a fix costs

Making each worker evaluate its own copy of the graph means per-thread storage for every module-level binding, plus per-thread module-initialized flags so the worker actually runs the initializers. That is a real runtime/codegen change, and it lands directly on a hot path: module-global reads are currently a plain load from a fixed address, and TLS-indirecting them is exactly the kind of cost this codebase optimizes hard elsewhere.

I am not attempting that as a drive-by patch. I would rather hand over an accurate map than a change that trades a visible bug for a performance regression or a subtler correctness one — I already did that once today on #10394, where a plausible-looking worker pump deadlocked the process and then segfaulted it, both measured.

If a narrower fix is wanted first

The half-inherited case is the part that produces wrong answers rather than merely surprising ones. Any change that makes the two sides consistent — either both crossing or neither — turns this from "memoized function returns undefined" into something a program can reason about. Full isolation is the correct semantics; consistency is the urgent part.

Verification note for whoever picks this up

The 8-cell reproducer in the issue body runs in 3 modules and takes seconds to compile, so it is a fast loop. The OpenCode end-to-end confirmation is the slow one (~45 min, 5997 modules): a driver importing the real Server and calling Server.Default().app.fetch(request) inside a worker, which throws Cannot read properties of undefined (reading 'handler') on perry and returns status=200 on bun.

[proggeramlug]

Sharper root cause: a closure created on the main thread is NOT CALLABLE from a worker

Two corrections to my own issue text, then the real finding.

Correction 1 — module globals are not "half-inherited". They cross completely and correctly. Reading each kind individually through an exported accessor:

read from worker	bun (fresh module)	perry
num (number)	0	42 — main's value
str (string)	init	mutated
typeof obj	null	object
obj.a	-	1
typeof fn	null	function

So heap references and functions in module globals are visible and intact from the worker. My earlier "the flag crossed, the payload did not" reading was wrong — that was an artifact of the failure below, not of partial state transfer.

Correction 2 — object allocation in a worker is fine. Object literals, arrays, nested returns, Map, string concat all match bun exactly in a worker. Not a heap/allocator problem.

The actual defect. A closure constructed on the main thread throws when invoked from a worker. mod.ts:

export function makeLazy(fn) {
  let value
  let loaded = false
  return {
    call: () => { if (loaded) return value; value = fn(); loaded = true; return value },
    peekLoaded: () => loaded,
    peekValue: () => value,
    peekValueType: () => typeof value,
  }
}
export const L = makeLazy(() => ({ made: "computed" }))
export function makeCounter() { let n = 0; return { inc: () => ++n, peek: () => n } }
export const C = makeCounter()

Main runs L.call() and C.inc() twice, then a worker imports L and C:

call from worker	bun	perry
L.peekLoaded()	false	THREW value is not a function
L.peekValueType()	"undefined"	THREW value is not a function
L.peekValue()	undefined	THREW value is not a function
L.call()	{"made":"computed"}	THREW value is not a function
C.peek()	0	THREW value is not a function
C.inc()	1	THREW value is not a function

Every closure, whether it captures an object or only a primitive. On the main thread all of these work (L.peekLoaded = true, C.inc = 1, 2).

value is not a function is the same message OpenCode's worker produces, and this is the mechanism behind webHandler() yielding undefined there: webHandler is lazy(...), i.e. exactly this shape, constructed during main-thread module evaluation.

Why the two facts are connected

Because perry does not instantiate the module graph per worker, the worker's import { L } from "./mod.js" hands it the main thread's closure objects rather than constructing its own. Those objects are then not callable from this thread. bun sidesteps it by giving each worker its own module instance, so the worker builds its own closures and never touches the main thread's.

So the fix direction in the issue body still stands — per-worker module instantiation — but the symptom to test against is much sharper than "state is shared": a closure value that crosses into a worker must be callable, or must not cross. Either would fix the reproducer; silently producing a non-callable function value is the part that turns into undefined returns and swallowed throws downstream.

Repro cost

3 modules, compiles in seconds. The full OpenCode confirmation is ~45 min / 5997 modules and shows Server.Default().app.fetch(request) throwing Cannot read properties of undefined (reading 'handler') in a worker versus status=200 on bun.

[proggeramlug]

Root cause is much narrower than either of my earlier readings: an imported function returning an OBJECT LITERAL yields an empty object in a worker

Please read this in place of my two previous comments — both were wrong about the mechanism, and this one is a 3-module reproducer with a clean cut line.

mod.ts:

// @ts-nocheck
export function makeString() { return "just-a-string" }
export function makeArray()  { return [1, 2, 3] }
export function makeData()   { return { a: 1, b: "x" } }
export function makeNested() { return { inner: { n: 7 } } }
export function makeWithFn() { return { f: () => 42 } }
export function makeCounter(){ let n = 0; return { inc: () => ++n } }

w.ts (worker) imports all six, calls each, and prints typeof, Object.keys, JSON.stringify.

imported function returns	bun	perry (in worker)
string	"just-a-string"	same	ok
array	keys=[0,1,2], [1,2,3]	same	ok
plain object {a:1,b:"x"}	keys=[a,b], {"a":1,"b":"x"}	keys=[], null	✗
nested object {inner:{n:7}}	keys=[inner]	keys=[], null	✗
object with a fn {f:()=>42}	keys=[f]	keys=[], null	✗
closure object {inc:()=>++n}	keys=[inc]	keys=[], null	✗

typeof is object in every perry row — the allocation happens, it just has no properties, and JSON.stringify of it is null.

Strings and arrays are unaffected. So this is specific to object literals constructed by code belonging to a module the worker did not evaluate.

What it is NOT (both measured, both things I previously claimed)

• Not closures crossing threads. A closure built inside the worker fails identically, and plain data objects fail too — no closure involved.
• Not module-global state. Reading module globals from a worker is completely correct, including heap values: typeof obj → object, obj.a → 1, typeof fn → function.
• Not object allocation in workers. Object literals, arrays, Map, nested returns and IIFEs written in the worker's own module all match bun exactly, including {f:()=>1}, {f(){}}, {f:function(){}} and capturing arrows.

The cut line is therefore: which module the constructing code belongs to, not what it constructs or what it captures.

Likely mechanism

Object literals appear to allocate against a per-module shape/class registered during that module's initialization. A worker evaluates its own entry module but not the rest of the graph, so a literal constructed by mod.ts code has no shape on this thread and comes out with zero properties. Arrays and strings don't go through that path, which is exactly the observed split. adopt_image(class_image) in the worker spawn path looks like the intended mitigation; it does not appear to cover anonymous object-literal shapes.

Why this is OpenCode's blank TUI

webHandler is lazy(() => …) and lazy returns an object literal from util/lazy.ts — a module the worker never evaluated. In the worker that object comes back with no properties, so webHandler() is effectively {}, .handler is undefined, and Server.Default() throws Cannot read properties of undefined (reading 'handler'). cli/tui/worker.ts installs no-op unhandledRejection/uncaughtException handlers, so the throw is swallowed, no RPC reply is sent, bootstrap() never completes, store.status stays "loading", ready stays false, and createSimpleContext's <Show when={init.ready}> withholds all 27 providers. render() resolves and paints nothing.

Severity

Any object returned across a module boundary into a worker is silently empty. No throw at the construction site, typeof still reports object, and the damage surfaces arbitrarily far away — here, as a blank screen with no error anywhere.

Retitling to match.

[proggeramlug]

Fully isolated: an INDIRECT call to an imported function, in a worker, returns an object with no properties

This supersedes everything above. The trigger is the call form, not the module, not closures, not module state.

mod.ts:

// @ts-nocheck
export function makeData() { return { a: 1, b: "x" } }

w.ts (worker) — every line calls the same function and prints Object.keys:

const k = (v) => (v && typeof v === "object") ? "[" + Object.keys(v).join(",") + "]" : "-"
say("direct            " + k(makeData()))
const alias = makeData
say("local alias       " + k(alias()))
const viaParam = (f) => f()
say("via parameter     " + k(viaParam(makeData)))
const holder = { m: makeData }
say("object property   " + k(holder.m()))
const arr = [makeData]
say("array element     " + k(arr[0]()))
say("via .call         " + k(makeData.call(null)))
say("direct again      " + k(makeData()))

call form (in the worker)	bun	perry
makeData() direct	[a,b]	[a,b]	ok
alias() local const alias	[a,b]	[]	✗
f() through a parameter	[a,b]	[]	✗
holder.m() object property	[a,b]	[]	✗
arr[0]() array element	[a,b]	[]	✗
makeData.call(null)	[a,b]	[]	✗
makeData() direct, afterwards	[a,b]	[a,b]	ok

The first and last rows bracket the failures: the direct form works before and after, so nothing is being corrupted — the indirect call simply produces a shapeless object.

On the MAIN thread every form is correct, including via-parameter. So the condition is worker and indirect call.

typeof is object and the allocation happens; the object has no properties, JSON.stringify gives null, Object.keys is empty. Silent: nothing throws at the construction site.

Corrections to my earlier comments on this issue

All three of my earlier mechanisms were wrong, and the measurements that killed them:

• Not closures crossing threads. A closure built inside the worker fails the same way, and plain data objects with no closure fail too.
• Not module-global state. Module globals read correctly from a worker, heap values included: typeof obj → object, obj.a → 1, typeof fn → function.
• Not per-worker module instantiation. adopt_image already shares the parent's ClassImageTables with the worker, enter_current_thread_image explicitly returns early when a thread already has one (its doc comment names the worker_threads case), and ANON_SHAPE_CLASS_IDS is an ImageTable, i.e. per image and therefore shared. The image plumbing is correct.

So this is not an architecture problem and not a module-isolation problem. It is the indirect-call lowering failing to stamp the returned literal's shape when it runs on a non-main thread.

Why it is OpenCode's blank TUI

lazy() returns { call, … } and callers invoke webHandler() — an indirect call through a module-level const. In the worker that returns a property-less object, so .handler is undefined, Server.Default() throws Cannot read properties of undefined (reading 'handler'), cli/tui/worker.ts's no-op unhandledRejection handler swallows it, no RPC reply is sent, bootstrap() never finishes, store.status stays "loading", ready stays false, and createSimpleContext's <Show when={init.ready}> withholds all 27 providers. render() resolves and paints nothing.

Repro cost

3 modules, seconds to compile. The direct vs alias pair on adjacent lines is the whole test.

[proggeramlug]

Correct rule: an object literal's STATIC SHAPE is lost when the constructing code runs on a worker thread. Inlining hides it.

My previous comment said the trigger was the indirect call. That was an artifact of the function I chose being inlinable. Here is the controlled version.

mod.ts — three functions returning the same literal shape, differing only in inlinability:

// @ts-nocheck
export function small() { return { a: 1, b: "x" } }
export function bigRec(n) {                      // recursive: resists inlining
  if (n > 0) return bigRec(n - 1)
  let s = 0
  for (let i = 0; i < 50; i++) { s += i * 3; if (s > 100000) s = 0 }
  return { a: 1, b: "x", s }
}
export function bigBody() {                      // large body: resists inlining
  let t = 0
  for (let i = 0; i < 200; i++) { t += (i % 7) * (i % 11); if (t > 99999) t -= 12345 }
  const o = { a: 1, b: "x", t }
  for (let i = 0; i < 5; i++) { o["k" + i] = i } // keys added DYNAMICALLY
  return o
}

The worker calls each directly and through a const alias, printing Object.keys:

call in worker	bun	perry
small() direct	[a,b]	[a,b]	ok — inlined into the worker's module
small() via alias	[a,b]	[]	✗
bigRec() direct	[a,b,s]	[]	✗ — direct, and still broken
bigRec() via alias	[a,b,s]	[]	✗
bigBody() direct	[a,b,t,k0,k1,k2,k3,k4]	[k0,k1,k2,k3,k4]	✗
bigBody() via alias	[a,b,t,k0,k1,k2,k3,k4]	[a,b,t,k0..k4]	ok

Main thread: all six correct.

Two things this pins down that the earlier framing got wrong:

1. bigRec() fails when called DIRECTLY. So the call form is not the trigger. small() direct only worked because it was inlined into w.ts, i.e. the literal was constructed by the worker's own module's code.

2. bigBody() keeps exactly the dynamically-assigned keys and loses exactly the literal ones. {a, b, t} — the static shape — is gone; k0..k4, added at runtime through o["k"+i] = i, are all present. The object is real and writable; only its literal-declared shape is missing.

So the rule is: an object literal constructed by code belonging to a module the worker did not evaluate comes out without its static shape. Runtime-added properties are unaffected, which is why typeof is object, writes work, and nothing throws — the object is simply missing the keys it was declared with.

(The bigBody()-via-alias row being correct is unexplained by this rule and is worth a look; it is the one cell that does not fit, and may indicate more than one lowering reaching the same construction.)

Bearing on the fix

This is not per-worker module instantiation, and not the call lowering. It is the static-shape stamping for object literals not being valid for code executing on a non-main thread. adopt_image already shares ClassImageTables with the worker and ANON_SHAPE_CLASS_IDS is an ImageTable, so the anon-shape ids are shared; what does not survive is the literal's key/shape association at the construction site.

The two-line discriminator for any candidate fix: bigRec() called directly from a worker must return [a,b,s], and bigBody() called directly must return all eight keys rather than only the five dynamic ones.

[proggeramlug]

Negative result: NOT class-id collision with the worker's own module

The comment at class_registry/class_meta.rs:608 ("Class ids are handed out per module, so one module's anon-shape id can be the same number as another module's declared class") made collision an obvious suspect: the worker's entry module init would re-register colliding ids into the shared image and clobber the importee's shapes.

Measured, and it is not that.

Two workers, same mod.ts exporting the non-inlinable bigRec() that returns {a, b, s}:

• wclean.ts — imports bigRec and nothing else; declares no object literals or classes of its own.
• wdirty.ts — declares three of its own object literals first, then calls bigRec().

	bun	perry
main bigRec(3)	[a,b,s]	[a,b,s]
clean worker bigRec(3)	[a,b,s]	[]
dirty worker, own literals	[p,q], [r,s,t]	[p,q], [r,s,t] — correct
dirty worker bigRec(3)	[a,b,s]	[]

The clean worker fails identically, so nothing the worker module declares is involved. And the dirty worker's own literals are perfectly correct in the same run — only the imported module's literal is shapeless.

So the empirical rule stands unchanged and is now better bounded:

An object literal constructed by code belonging to a module the worker did not evaluate comes out with no static shape. Literals constructed by the worker's own module are correct, in the same worker, in the same run.

Hypotheses I have now tested and disproved on this issue

Recording these so nobody spends time re-running them:

1. Closures cannot cross threads — a closure built inside the worker fails too; plain data objects fail with no closure involved.
2. Module-level state is shared/half-inherited — module globals read correctly from a worker, heap values included.
3. Workers need per-module instantiation of the graph — adopt_image already shares ClassImageTables, enter_current_thread_image returns early when a thread has one (its doc names the worker_threads case), ANON_SHAPE_CLASS_IDS is an ImageTable.
4. The indirect call form is the trigger — bigRec() fails when called directly; small() only worked because it was inlined into the worker's own module.
5. Class-id collision with the worker's entry module — this comment.

What would settle it

Black-box probing has run out of discriminating power here. The next step is reading the object-literal allocation path — how the literal's key/shape association is resolved at the construction site, and what about that resolution is main-thread-conditional — with the bigRec() case under a debugger, comparing the allocated header's class id and keys pointer on the main thread versus in the worker.

Acceptance test for any fix, unchanged: bigRec() called directly from a worker must return [a,b,s], and bigBody() called directly must return all eight keys rather than only its five dynamically-assigned ones.

[proggeramlug]

Mechanism, from the code: module-init keys arrays live in the initializing thread's arena, and the shape store is thread-local

Two facts in the tree explain every observation on this issue.

1. The GC arena is per-thread. crates/perry-runtime/src/arena/block.rs declares its block state with thread_local! (lines 148, 939, 1010) and crate::perry_thread_local! (1025).

2. The shape store is per-thread. crates/perry-runtime/src/object/shapes_store.rs:490 is crate::perry_thread_local!.

Now the literal allocation path, object/alloc.rs::object_alloc_class_inline_keys_impl:

let used_preinstalled_shape = preinstalled_shape_id != 0
    && crate::object::shapes::try_birth_stamp_preinstalled_shape(
        ptr, preinstalled_shape_id, keys_array, logical_field_count as u32,
    );
if !used_preinstalled_shape {
    set_object_keys_array_with_live(ptr, keys_array, logical_field_count as u32);
}

with the comment above it:

The compiled entry point passes the ShapeId installed beside this canonical keys global at module initialization. Reuse that immutable descriptor directly when its keys facts and live-slot bound still match; learned instance widening, key-count drift, and worker-local first installs retain the exact mint-and-validate fallback.

So for a literal in mod.ts:

• keys_array is the canonical keys array GC-allocated during mod.ts's module init, i.e. in the arena of whichever thread ran that init — the main thread.
• preinstalled_shape_id was minted into that thread's thread-local shape store.

In a worker, neither is valid for this thread: the shape id is absent from the worker's shape store so try_birth_stamp_preinstalled_shape declines, and the fallback then calls set_object_keys_array_with_live with a keys_array pointer belonging to another thread's arena. The object is allocated correctly in the worker's own arena and its slots are initialized, but it ends up with no usable key set — exactly what is observed: typeof is object, writes work, Object.keys is empty, JSON.stringify is null.

This accounts for every measurement on this issue

observation	explanation
literals from an imported module are shapeless in a worker	keys array + shape id belong to the main thread
literals from the worker's own module are correct, same run	their keys array was allocated during the worker's own module init, in the worker's arena
dynamically added keys (o["k"+i] = i) survive	allocated in the worker, nothing foreign involved
small() direct worked, bigRec() direct did not	small was inlined into the worker's module, so codegen emitted the literal against that module's own keys global; bigRec resisted inlining and kept mod.ts's
arrays and strings are unaffected	they do not go through the class-keys/shape path
main thread is always correct	it is the thread that ran the inits
adopt_image does not help	it shares ClassImageTables; the arena and the shape store are separate and thread-local

It also explains why this is silent: nothing throws, because from the allocator's point of view the fallback path ran normally.

Implications for a fix

The stamping is not "main-thread-conditional" by design — it is thread-conditional because two of its inputs are thread-owned. A fix has to make one of these true:

• the canonical keys arrays for module literals are allocated somewhere every thread can read (a shared/immortal region rather than the initializing thread's arena), or
• a worker re-materialises the keys arrays and shape ids for modules it did not evaluate, or
• the fallback detects a foreign keys_array and mints a thread-local copy instead of installing the foreign pointer — the narrowest change, and it turns a silent wrong answer into a correct one at the cost of one mint per literal per worker.

The third seems the most contained and matches the comment's own framing ("worker-local first installs retain the exact mint-and-validate fallback") — that path exists, it just isn't reached with a usable keys array.

Acceptance test unchanged: in a worker, bigRec() called directly must return [a,b,s], and bigBody() called directly must return all eight keys rather than only its five dynamically-assigned ones.

[proggeramlug]

Measured, not inferred: the failing allocations receive the MAIN thread's keys array, which classifies as Unknown on the worker

I added a temporary diagnostic to object_alloc_class_inline_keys_impl printing the thread, the keys_array pointer, arena::classify_heap_generation(keys_array) and the preinstalled_shape_id, then ran the direct-vs-indirect reproducer. Every row lines up:

[keys-origin] thread=ThreadId(1) class_id=1 keys_ptr=0x3c199b80140 gen=Longlived  preinstalled_shape_id=2147486343
IN MAIN direct [a,b]  via-param [a,b]

[keys-origin] thread=ThreadId(2) class_id=1 keys_ptr=0x3c19e0001b0 gen=Longlived  preinstalled_shape_id=2147486343
IN WORKER direct            [a,b]
[keys-origin] thread=ThreadId(2) class_id=1 keys_ptr=0x3c199b80140 gen=Unknown    preinstalled_shape_id=2147486343
IN WORKER local alias       []
[keys-origin] thread=ThreadId(2) class_id=1 keys_ptr=0x3c199b80140 gen=Unknown    preinstalled_shape_id=2147486343
IN WORKER via parameter     []
[keys-origin] thread=ThreadId(2) class_id=1 keys_ptr=0x3c199b80140 gen=Unknown    preinstalled_shape_id=2147486343
IN WORKER object property   []
[keys-origin] thread=ThreadId(2) class_id=1 keys_ptr=0x3c199b80140 gen=Unknown    preinstalled_shape_id=2147486343
IN WORKER array element     []
[keys-origin] thread=ThreadId(2) class_id=1 keys_ptr=0x3c199b80140 gen=Unknown    preinstalled_shape_id=2147486343
IN WORKER via .call         []
[keys-origin] thread=ThreadId(2) class_id=1 keys_ptr=0x3c19e0001b0 gen=Longlived  preinstalled_shape_id=2147486343
IN WORKER direct again      [a,b]

Reading it:

• 0x3c199b80140 is the array the main thread used (ThreadId(1), Longlived there). Every worker allocation that receives this pointer classifies it Unknown — outside this thread's arena page ranges — and produces keys=[].
• 0x3c19e0001b0 is a different array, Longlived on ThreadId(2). Every worker allocation that receives it produces [a,b].
• Same class_id (1) and same preinstalled_shape_id (2147486343) on both, so neither the class id nor the shape id distinguishes the good rows from the bad ones — only the keys pointer's owning thread does.

So the failure is exactly: the allocation installs a keys array owned by another thread's arena, and the resulting object has no usable key set. try_birth_stamp_preinstalled_shape declines (the shape store is perry_thread_local!, shapes_store.rs:490), and the fallback set_object_keys_array_with_live then installs the foreign pointer.

The two pointers also confirm why "direct call" appeared to matter: the direct rows get a worker-local keys array because that construction was inlined into the worker's own module, so codegen emitted it against that module's keys global — which was allocated during the worker's own init, in the worker's arena. It was never about the call form.

This makes the narrow fix concrete

In object_alloc_class_inline_keys_impl, before installing:

if !used_preinstalled_shape {
    set_object_keys_array_with_live(ptr, keys_array, logical_field_count as u32);
}

the foreign case is detectable with the same call the diagnostic used —
matches!(crate::arena::classify_heap_generation(keys_array as usize), HeapGeneration::Unknown) —
and worth noting: threads share one address space, so the foreign array is still readable; it is the arena/GC attribution that makes it unusable, not the mapping. A thread-local copy of the keys array is therefore a normal read plus an allocation in this thread's arena, once per literal per worker, exactly the "worker-local first install" the existing comment already anticipates.

I am not sending that patch myself: this is the runtime's hottest allocation path, a wrong move here is heap corruption rather than a visible bug, and I have already had to revert one speculative worker-related change today. But the detection predicate, the failing call site and the acceptance test are all now pinned.

Acceptance test: in a worker, bigRec() called directly must return [a,b,s], and bigBody() called directly must return all eight keys rather than only its five dynamically-assigned ones.

(The diagnostic above is temporary and is not in any branch I am proposing.)

[proggeramlug]

The keys array is REBUILDABLE from static data — no cross-thread read is needed for a fix

One more piece that should make the fix cheaper and safer than copying a foreign array.

object/alloc.rs:425:

pub extern "C" fn js_build_class_keys_array(
    class_id: u32,
    field_count: u32,
    packed_keys: *const u8,
    packed_keys_len: u32,
) -> *mut ArrayHeader

and from codegen/mod.rs:1075:

Per-class keys-array globals: each class gets a single internal global @perry_class_keys_<modprefix>__<class> that holds the shared keys_array pointer (built ONCE at module init via js_build_class_keys_array). Every new ClassName() site then emits a direct global load + inline allocator call…

So the inputs to the keys array are packed_keys — a static constant in the binary's rodata, process-wide, immutable, and safe to read from any thread — plus two integers. The array itself is merely a materialisation of that constant into some thread's arena.

That changes the shape of the fix. It does not need to read or copy another thread's heap object. A worker can rebuild its own keys array from the same static bytes, which is exactly what js_build_class_keys_array already does on the main thread at init, and what it already does for the worker's own module's classes.

js_build_class_keys_array also already consults a cache and calls remember_class_keys_array(class_id, field_count, cached), so there is an existing per-class memo to hang a per-thread materialisation off.

Two candidate fixes follow, both avoiding set_object_keys_array_with_live's descriptor-publication invariants entirely:

1. Codegen — instead of emitting a plain load of @perry_class_keys_* at each construction site, emit a load plus a thread-ownership check that falls back to js_build_class_keys_array with the same static packed_keys operands (already available at the site, since they are what init passes). Cost is one predictable branch on the hot path.

2. Runtime, at module init — have a worker materialise the keys arrays for the modules it imports but did not evaluate, from the same static data, before running its entry. This keeps the hot path exactly as it is today.

Option 2 looks closest to the existing design: the global would then hold a per-thread array in every thread, which is what the direct-call rows already demonstrate works (keys_ptr=0x3c19e0001b0 gen=Longlived on the worker → [a,b]).

Either way the fix does not touch the birth-stamp path, does not dereference foreign memory, and is validated by the same two-line test: in a worker, bigRec() direct must return [a,b,s] and bigBody() direct must return all eight keys.

I am stopping here rather than implementing: choosing between those two is a design call about where per-thread materialisation belongs, and the person who owns this area will make it in minutes where I would be guessing. Everything needed to act is now on this issue — reproducer, measured mechanism with pointer evidence, five disproved hypotheses, the call site, the detection predicate, the static-data insight, and the acceptance test.

[proggeramlug]

The keys-array construction already lives in a dedicated, parameterless init function — which is where a worker-side fix can hook

Closing the loop on where the per-thread materialisation belongs, since that was the open design question.

crates/perry-codegen/src/codegen/string_pool.rs:1704:

let init_fn = llmod.define_function(&init_name, VOID, vec![]);
let _ = init_fn.create_block("entry");

The js_build_class_keys_array call sequence for class_keys_init_data is emitted into this function — a per-module, parameterless, void init routine — not interleaved with user module-body code. That is the important structural fact: materialising a module's keys arrays does not require running any of that module's user code, so doing it on a worker cannot re-run user side effects or disturb module-global state (which, as measured earlier on this issue, is shared and must not be re-initialised).

That makes the worker-side option concrete: a worker materialises the keys arrays for the modules it did not evaluate by invoking those existing init routines on its own thread, before running its entry. Each call is js_build_class_keys_array over packed_keys — a static rodata constant — so it allocates in the calling thread's arena and mints into that thread's shape store, which is exactly the state the working rows already demonstrate (keys_ptr=0x3c19e0001b0 gen=Longlived on the worker → [a,b]).

Two caveats for whoever implements it, both from this same function:

• It is a combined routine — it also performs string-pool and class-metadata initialisation, so it is not obviously idempotent as a whole. Re-running it wholesale on a worker may need the keys-array portion split out, or those other steps made re-entrant.
• The per-class typed-shape mask globals emitted just above it (raw_f64_mask_global_name_from_keys_global, mask_global_name_from_keys_global) are rodata constants, so they are already thread-safe to read and need no per-thread copy.

And ruling out the runtime-only alternative I floated earlier: CLASS_KEYS_BY_ID (object/alloc.rs:23) is process-wide but stores (keys_array_ptr, field_count) — the pointer, not the packed bytes — and shape_cache_get reads crate::state::state(), which is per-thread. So there is no process-wide record of the packed keys reachable from the allocation path; a fix cannot be made purely inside object_alloc_class_inline_keys_impl. It has to come from either codegen (rebuild at the construction site) or worker-start materialisation (this comment).

That is everything I can establish from outside the shape/GC invariants. Summary of what this issue now carries: a 3-module reproducer compiling in seconds; the measured mechanism with pointer evidence (same class_id, same preinstalled_shape_id — only the keys pointer's owning thread differs); five disproved hypotheses; the failing call site; the detection predicate; the static-data insight; the location of the existing init routine; and a two-line acceptance test.

[proggeramlug]

The fix already exists in the codebase — the unpromoted object-literal path is thread-safe; only the promoted anon-shape-class path is not

This is the most actionable thing I have found and it changes the fix from "design something" to "make one path match the other".

There are two lowerings for an object literal.

Path 1 — expr/object_literal.rs:455, thread-safe today:

let keys_global = format!("@{}", keys_entry.bytes_global);   // rodata, packed "k1\0k2\0"
let obj_handle = ctx.block().call(
    I64,
    "js_object_alloc_with_shape",
    &[(I32, &shape_id_str), (I32, &n_str), (PTR, &keys_global), (I32, &keys_len_str)],
);

It passes the static packed-keys bytes and a content-derived shape_id. The runtime materialises the keys array itself and caches it in the thread-local shape cache. Nothing thread-owned crosses the boundary, so this path is correct in a worker by construction.

Path 2 — the promoted anon-shape-class path, broken:

js_object_alloc_class_inline_keys_stamped(class_id, parent_class_id, field_count, keys_array, preinstalled_shape_id) takes a built *mut ArrayHeader, loaded from the process-wide @perry_class_keys_<modprefix>__<class> global, which holds whichever thread ran that module's init. This is the path my diagnostic instrumented, and the one that fires for the failing rows (class_id=1, keys_ptr = the main thread's array, gen=Unknown on the worker).

So the asymmetry is the bug: one path carries immutable rodata and lets each thread materialise, the other carries a thread-owned heap pointer.

What this implies for the fix

The narrowest change is to give the class/anon-shape path the same contract the literal path already has: pass (packed_keys, packed_keys_len) alongside — or instead of — the prebuilt array, and let the callee resolve per thread. js_build_class_keys_array(class_id, field_count, packed_keys, packed_keys_len) already does exactly this and is already per-thread idempotent — it probes the thread-local shape cache first and only builds on a miss:

let cached = shape_cache_get(shape_id);
if !cached.is_null() { remember_class_keys_array(class_id, field_count, cached); return cached; }

so the hot path stays a thread-local cache hit (documented as ~3 ALU ops + 1 load + 1 cmp + 1 branch), not a rebuild. The static operands are already present at every construction site — they are what module init passes today.

That avoids both options I sketched earlier: no TLS indirection on the keys global, and no classify_heap_generation probe on the hot path. It makes the broken path use the mechanism the working path already proves out.

Validation

bigRec() called directly from a worker must return [a,b,s]; bigBody() direct must return all eight keys rather than only its five dynamically-assigned ones. 3 modules, seconds to compile. Then the perry suite, then an OpenCode build where the acceptance signal is the TUI painting Ask anything / 1.18.30 instead of a blank screen.

I am not landing this myself: routing a new operand through every anon-shape construction site touches the allocator's birth-stamp contract, and I have already had to revert one speculative worker-related change today. But whoever owns this area now has a same-file precedent for the correct shape of it.