wasm: pass command line arguments and environment variables via go.importObject

[Zxilly]

Proposal Details

This proposal suggests a modification to the Go compiler's WebAssembly (Wasm) target to change the mechanism used for passing command-line arguments and environment variables.

In the current implementation of the Go compiler targeting Wasm, command-line arguments and environment variables are written directly into the linear memory of the WebAssembly module, with the combined size of these parameters being limited to 8192 bytes.

The size limitation of 8192 bytes for the combined environment variables and command-line arguments is restrictive, particularly when considering the capabilities of mainstream operating systems:

• Linux: MAX_ARG_STRLEN * 32, typically 128KB
• Windows: Has a maximum environment block size of 32,767 characters.
• macOS: I don't have a macOS device, but in GitHub Actions, the macOS runner can apparently also store environment variables that are longer than 8192

This restriction has caused some real trouble. When running unit tests on GitHub Actions, for example, the length of environment variables included by default in the runner has exceeded this limit.

https://github.com/evanw/esbuild/blob/9c13ae1f06dfa909eb4a53882e3b7e4216a503fe/Makefile#L55-L62

https://github.com/Zxilly/go-size-analyzer/blob/c4e4db97cc0383797c8b4960c55db529df451601/scripts/tests.py#L47-L74

https://github.com/agnivade/wasmbrowsertest/issues/30

https://github.com/golang/go/issues/49011

I propose to instead use go.importObject for passing these parameters. Glue js should perform dynamic allocation of environment variables and command line arguments as the wasm application tries to read them, and then provide the values to the wasm application using logic similar to syscall/js.copyBytesToGo.

[gabyhelp]

Related Issues and Documentation

• misc/wasm, cmd/link: Go 1.17.2 causes WASM builds to throw `command line too long` with many environment variables #49011 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

This seems like something that can be fixed internally without changing anything user-visible, so taking it out of the proposal process.

[ianlancetaylor]

CC @golang/wasm