[Based on #123] test/wasm: harden runtime lifecycle and host boundaries

[cpunion]

Depends on #123.

Problem

The refreshed wasm runtime can schedule, block, wake timers, collect suspended roots, and stop multiple workers, but its lifecycle acceptance coverage did not exercise several boundaries together. In particular, importing os in a J32/J64/P1 program failed to link because wasm did not provide os.runtime_args.

Changes

• expose Emscripten and WASI Preview 1 process arguments through the existing os.runtime_args runtime contract;
• select the no-fd-poller stubs for wasm without changing native poller selection;
• add one shared J32/J64/P1 hardening fixture covering arguments/environment, indirect method-value suspension, panic/defer/recover, suspended roots, 10,000 channel handoffs, blocked-G root retention, canceled shutdown timers, and C-boundary roots;
• execute the worker boundary under two-worker J32/J64 Node and COOP/COEP Chrome, and keep explicit P1 threads covered by the existing iwasm lane.

The independent diff over #123 is 10 files, +366/-4. The rejected prototype raised Emscripten maximum memory to 4 GiB; it is not included because 10,000 simultaneously blocked goroutines pass with the existing default configuration, so hardening adds no default wasm, native, or embedded artifact cost.

Validation

• go test -timeout 30m -p=1 ./internal/build -count=1 (953.050s)
• go test -p=1 ./internal/crosscompile ./internal/build focused source-selection tests on Go 1.26.5; the Go 1.24 selection test also passes
• go test -p=1 ./... in the runtime module on macOS arm64 and Ubuntu amd64 (2 CPUs, 6 GiB)
• Go 1.24 J32, J64, and P1 hardening execution/n- J32/J64 Node: default, -O0, -O3, ThinLTO, and full LTO hardening execution
• J32/J64 two-worker Node and Chrome execution
• P1 Wasmtime execution and validation
• 10,000 blocked-G J32 run: pass, about 1.385 GiB heap-system growth under the existing memory configuration
• direct runtime/wasm: stop all workers for garbage collection (based on #119) #123 artifact comparison: J32 172,625 B, J64 214,452 B, and P1 202,525 B are byte-identical; native runtime and Cortex-M4 artifacts are also byte-identical

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[github-actions]

LLGo baseline benchmarks

be56f590542f | workflow run | long-term charts

Program measurements

Platform	Workload	File size	vs main	Build	vs main	Run	vs main
Linux	cprintf	18816 B	+1.5% (worse)	361.161 ms	-12.4% (better)	1.298 ms	-16.3% (better)
Linux	fmtprintf	2219448 B	+0.3% (worse)	3.411 s	-11.5% (better)	2.439 ms	-25.8% (better)
Linux	println	71776 B	-1.2% (better)	345.410 ms	-13.7% (better)	1.608 ms	-3.9% (better)
macOS	cprintf	84672 B	+0.0%	477.912 ms	+15.3% (worse)	3.079 ms	-14.2% (better)
macOS	fmtprintf	2361968 B	+0.7% (worse)	2.657 s	-32.6% (better)	16.742 ms	-28.4% (better)
macOS	println	125712 B	-1.0% (better)	496.635 ms	+19.8% (worse)	5.168 ms	-28.8% (better)

Core language and compiler benchmarks

Platform	Benchmark	ns/op	vs main
Linux	BenchmarkLookupPCRandom	13.390 ns/op	-0.7% (better)
Linux	BenchmarkMergeCompilerFlags	150.800 ns/op	-2.4% (better)
Linux	BenchmarkMergeLinkerFlags	94.140 ns/op	-7.1% (better)
Linux	BenchmarkChannelBuffered	33.720 ns/op	-3.0% (better)
Linux	BenchmarkChannelHandoff	31060 ns/op	-3.0% (better)
Linux	BenchmarkDefer	43.440 ns/op	-22.9% (better)
Linux	BenchmarkDirectCall	1.558 ns/op	-0.3% (better)
Linux	BenchmarkGlobalRead	1.871 ns/op	+19.9% (worse)
Linux	BenchmarkGlobalWrite	2.487 ns/op	-0.3% (better)
Linux	BenchmarkGoroutine	44257 ns/op	-41.4% (better)
Linux	BenchmarkInterfaceCall	8.090 ns/op	+3.8% (worse)
Linux	BenchmarkRuntimeGetG	1.925 ns/op	-63.7% (better)
macOS	BenchmarkLookupPCRandom	10.750 ns/op	-13.6% (better)
macOS	BenchmarkMergeCompilerFlags	96.450 ns/op	-22.5% (better)
macOS	BenchmarkMergeLinkerFlags	63.730 ns/op	-8.1% (better)
macOS	BenchmarkChannelBuffered	20.780 ns/op	-25.1% (better)
macOS	BenchmarkChannelHandoff	6465 ns/op	-7.8% (better)
macOS	BenchmarkDefer	26.060 ns/op	-30.4% (better)
macOS	BenchmarkDirectCall	0.997 ns/op	-31.4% (better)
macOS	BenchmarkGlobalRead	1.007 ns/op	-16.8% (better)
macOS	BenchmarkGlobalWrite	1.054 ns/op	-29.1% (better)
macOS	BenchmarkGoroutine	26514 ns/op	-16.2% (better)
macOS	BenchmarkInterfaceCall	4.116 ns/op	-23.7% (better)
macOS	BenchmarkRuntimeGetG	2.006 ns/op	-22.2% (better)

Compared only with the latest matching platform in the main series.

Warning

• Persistent publishing is unavailable because no data token is configured.