Stream: git-wasmtime

Topic: wasmtime / issue #8504 `-W max-table-elements` has no eff...

Wasmtime GitHub notifications bot (Apr 29 2024 at 20:04):

dicej opened issue #8504:

While working on resource support for the C# wit-bindgen generator, I created an example app targeting wasi:http/incoming-handler@0.2.0. However, wasmtime serve couldn't run it due to one of the tables containing more than 10000 entries:

 $ wasmtime serve target/stripped.wasm
Error: table index 0 has a minimum element size of 10511 which exceeds the limit of 10000

Next, I tried wasmtime serve -W max-table-elements=20000 target/stripped.wasm instead, but got the same error. Looking at the code, it seems that the pooling allocator is enabled by default for wasmtime serve, and since it has its own configuration knobs which are not controlled by e.g. -W max-table-elements, there's no way to change the limit from its default. There's also no way I can see to disable the pooling allocator, given that the only reference to the --pooling-allocator option is in old_cli.rs, which is disabled in the default build.

I'd suggest that -W options such as max-table-elements should be applied to the pooling allocator when it is enabled. We might also consider raising the default considering that even simple C# apps tend to exceed it (although we could instead consider that a bug in the C# Native AOT compiler).

Wasmtime GitHub notifications bot (Apr 29 2024 at 20:05):

dicej edited issue #8504:

While working on resource support for the C# wit-bindgen generator, I created an example app targeting wasi:http/incoming-handler@0.2.0. However, wasmtime serve couldn't run it due to one of the tables containing more than 10000 entries:

 $ wasmtime serve target/stripped.wasm
Error: table index 0 has a minimum element size of 10511 which exceeds the limit of 10000

Next, I tried wasmtime serve -W max-table-elements=20000 target/stripped.wasm instead, but got the same error. Looking at the code, it seems that the pooling allocator is enabled by default for wasmtime serve, and since it has its own configuration knobs which are not controlled by e.g. -W max-table-elements, there's no way to change the limit from its default. There's also no way I can see to disable the pooling allocator, given that the only reference to the --pooling-allocator option is in old_cli.rs, which is disabled in the default build.

I'd suggest that -W options such as max-table-elements should be applied to the pooling allocator when it is enabled. We might also consider raising the default considering that even simple C# apps tend to exceed it (although we could instead consider that a bug in the C# Native AOT compiler, e.g. insufficient dead code elimination?).

Wasmtime GitHub notifications bot (Apr 29 2024 at 20:29):

dicej edited issue #8504:

While working on resource support for the C# wit-bindgen generator, I created an example app targeting wasi:http/incoming-handler@0.2.0. However, wasmtime serve couldn't run it due to one of the tables containing more than 10000 entries:

 $ wasmtime serve target/stripped.wasm
Error: table index 0 has a minimum element size of 10511 which exceeds the limit of 10000

Next, I tried wasmtime serve -W max-table-elements=20000 target/stripped.wasm instead, but got the same error. Looking at the code, it seems that the pooling allocator is enabled by default for wasmtime serve, and since it has its own configuration knobs which are not controlled by e.g. -W max-table-elements, there's no way to change the limit from its default. There's also no way I can see to disable the pooling allocator, given that the only reference to the --pooling-allocator option is in old_cli.rs, which is disabled in the default build.

I'd suggest that -W options such as max-table-elements should be applied to the pooling allocator when it is enabled. We might also consider raising the default considering that even simple C# apps tend to exceed it (although we could instead consider that a bug in the C# Native AOT compiler, e.g. insufficient dead code elimination?). EDIT: I was building with -c Debug; the release build results in a table about half the size, which is well under the current default limit.

Wasmtime GitHub notifications bot (Apr 29 2024 at 21:08):

dicej commented on issue #8504:

As I noted in my edit above, building the C# app using -c Release ensured that the max table size in the component was well under the default limit, but then I ran into what appears to be an allocation failure during .NET runtime initialization, possibly due to the default memory pages limit being lower than what the .NET runtime needs. I'm going to test that theory using a custom build and report back here.

Wasmtime GitHub notifications bot (Apr 30 2024 at 02:33):

dicej commented on issue #8504:

Indeed, setting the memory pages limit to 1600 (i.e. 100MiB) allows the app the run without trapping.

Wasmtime GitHub notifications bot (May 03 2024 at 20:10):

alexcrichton closed issue #8504:

While working on resource support for the C# wit-bindgen generator, I created an example app targeting wasi:http/incoming-handler@0.2.0. However, wasmtime serve couldn't run it due to one of the tables containing more than 10000 entries:

 $ wasmtime serve target/stripped.wasm
Error: table index 0 has a minimum element size of 10511 which exceeds the limit of 10000

Next, I tried wasmtime serve -W max-table-elements=20000 target/stripped.wasm instead, but got the same error. Looking at the code, it seems that the pooling allocator is enabled by default for wasmtime serve, and since it has its own configuration knobs which are not controlled by e.g. -W max-table-elements, there's no way to change the limit from its default. There's also no way I can see to disable the pooling allocator, given that the only reference to the --pooling-allocator option is in old_cli.rs, which is disabled in the default build.

I'd suggest that -W options such as max-table-elements should be applied to the pooling allocator when it is enabled. We might also consider raising the default considering that even simple C# apps tend to exceed it (although we could instead consider that a bug in the C# Native AOT compiler, e.g. insufficient dead code elimination?). EDIT: I was building with -c Debug; the release build results in a table about half the size, which is well under the current default limit.

Last updated: Nov 22 2024 at 17:03 UTC