Kotlin benchmarks fails with memory allocation when collector is not drc

[igoriakovlev]

Test Case

issue.zip

Steps to Reproduce

Run the following command:
wasmtime -W gc,exceptions,function-references --dir=/ $PWD/kotlin-wasm-benchmarks-wasmWasiBenchmark.wasm STUB $PWD/config.conf StringBenchmark microBenchmarks.StringBenchmark.stringConcatNullable

Expected Results

Benchmarks are running.

Actual Results

GC heap out of memory: no capacity for allocation of 96 bytes when -C collector=copying
wasm trap: allocation size too large when -C collector=null

Versions and Environment

Wasmtime version or commit: 46.0.1

Operating system: MacOS 26.5.1

Architecture: Apple Silicon

Extra Info

With -C collector=drc benchmarks works good. Seems since 46.0.1 the default GC was changed from drc to copying so tests are now fails.

[fitzgen]

Hm I'm having trouble reproducing. With both the copying and DRC collectors I get an uncaught exception from the Wasm program, with no diagnostics printed, sometime after the GC heap grows to 1MiB:

2026-06-29T21:46:14.381956Z TRACE wasmtime::runtime::store::gc:   -> grew GC heap by 0x80000 bytes: new size is 0x100000 bytes
Error: failed to run main module `kotlin-wasm-benchmarks-wasmWasiBenchmark.wasm`

Caused by:
    0: failed to invoke command default
    1: error while executing at wasm backtrace:
    0:  0xecd4a - <org.jetbrains.benchmarks:kotlin-wasm-benchmarks_wasmWasiBenchmark>!kotlinx.benchmark.generated.mainWrapper
    2: thrown Wasm exception

[igoriakovlev]

Hi. Looks like something wrong with the IO and preopens. I have inlined all IO so you can run this without config and with simple command:
wasmtime -W gc,exceptions,function-references ./kotlin-wasm-benchmarks-wasmWasiBenchmark.wasm

kotlin-wasm-benchmarks-wasmWasiBenchmark.wasm.zip

[fitzgen]

@igoriakovlev thanks! Will take a look again soon

[fitzgen]

Unfortunately, this is the copying collector behaving as expected. It divides the GC heap into two semi-spaces, so its maximum heap utilization is 50%. The GC heap is a Wasm linear memory, which means its maximum size is 4GiB, which means that the copying collector supports a 2GiB maximum live set (well, actually just under 2GiB). Looking at the GC logs, Wasmtime grows the GC heap to its maximum capacity, but the benchmarks fill up all of that space and on the next allocation attempt this triggers the GC heap out of memory trap:

2026-07-01T00:38:46.716561Z TRACE wasmtime::runtime::store::gc: Attempting to grow the GC heap by at least 0x60 bytes
2026-07-01T00:38:46.716570Z TRACE wasmtime::runtime::store::gc: ============ Begin GC ===========
	          GC heap capacity = 0x100000000 bytes
	last post-GC live-set size = 0x7fffffd0 bytes
	       GC heap utilization = 50.00%
...
2026-07-01T00:39:52.846487Z TRACE wasmtime::runtime::store::gc: ============ End GC ===========
	     GC heap capacity = 0x100000000 bytes
	post-GC live-set size = 0x7fffffd0 bytes
	  GC heap utilization = 50.00%

Error: failed to run main module `/Users/n.fitzgerald/Downloads/kotlin-wasm-benchmarks-wasmWasiBenchmark.wasm`

Caused by:
    0: failed to invoke command default
...
    2: GC heap out of memory: no capacity for allocation of 96 bytes

So in order to run these benchmarks with Wasmtime's copying collector, you'll have to adjust the program so that their working set size is below 2GiB (and ideally fairly comfortably below that, probably around 1GiB is safe, as any collector's performance will become pathological as you approach its maximum heap capacity).

The DRC collector does not divide the heap into two semi-spaces, so it can utilize the full 4GiB heap, and this is why the program completes under the DRC collector.