syscall/js: huge copy overhead when passing byte slices over certain Go/JS boundaries

[leidegre]

This related to my effort to get Go WASM/JS to work with a WebWorker process.

What version of Go are you using (go version)?

go version devel +0e0cd70ecf Tue Jul 3 04:16:23 2018 +0000 windows/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

set GOARCH=wasm
set GOBIN=
set GOCACHE=C:\Users\leidegre\AppData\Local\go-build
set GOEXE=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=js
set GOPATH=C:\Users\leidegre\go
set GOPROXY=
set GORACE=
set GOROOT=C:\Users\leidegre\Source\go
set GOTMPDIR=
set GOTOOLDIR=C:\Users\leidegre\Source\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-fPIC -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\leidegre\AppData\Local\Temp\go-build097448038=/tmp/go-build -gno-record-gcc-switches
set VGOMODROOT=

What did you do?

Trying to pass an nil []byte slice from a WebWorker process to a web application.

What did you expect to see?

That gigabytes of memory is not allocated.

What did you see instead?

Gigabytes of memory is being allocated on each postMessage call. This crashes both Chrome and Firefox render process. Haven't tested Edge.

Additional findings

as soon as you console.log or pass a slice through a boundary context, for example postMessage there's copying associated with the ArrayBuffer. For some reason, the gigabyte ArrayBuffer (Go linear memory) gets copied as well and the heap just explodes typically grinding the web page to a halt or crashing the page.

I was able to work around this issue by passing the slice through this helper function first.

[worker.js]

function slice({ byteOffset, byteLength, buffer }) {
  return buffer.slice(byteOffset, byteOffset + byteLength)
}

[worker.go]

var x []byte
x = append(x, 2)
x = append(x, 3)
x = append(x, 5)
y := js.TypedArrayOf(x)
z := global.Call("slice", y)
y.Release()

global.Call("postMessage", z) // from WebWorker postMessage

Note that problem occur even if the slice is empty or nil. If worker.js, i.e. the WebWorker process does console.log at any time on any object that is backed by the ArrayBuffer you'll see crazy heap explosion and subsequent crashes. Not sure what to do about this but I thought I'd share my findings here. It's mostly a side effect of how things are not something Go/WASM is doing wrong but maybe this can be improved somehow? Passing values between Go/JS seems like a natural thing to do.

[leidegre]

@neelance this might interest you as well.

[neelance]

The buffer of the typed array is the whole WebAssembly memory. You take a slice of that buffer and then pass it to postMessage. I'm not sure how postMessage is supposed to work on buffers, but it is most likely the culprit. I guess it serializes the whole buffer, not only the slice. You should try to actually create a second buffer with only the data you need.

[agnivade]

@neelance - Feel free to comment if you want to prioritize it for 1.11.

[neelance]

If this is really due to postMessage, then it is working as intended from Go's point of view. postMessage shouldn't be used that way. @leidegre needs to evaluate if this is really the case, then we can close.

[leidegre]

I should probably have emphasized this a bit more but the issue is more subtle than postMessage. For example, if you do console.log on a slice, you run into the same issue and I suspect that there are additional edge cases lurking around the corner. If you trigger this behavior your whole app goes up in the air.

For example, take this program as an example

package main

func main() {
	var x []byte
	println(x)
}

You run that 3 or 4 times and the process hosting the page hard faults with an out of memory error and it is not limited to []byte an println([]int{}) is just as dangerous and please note that this behavior is not limited to WebWorker processes.

@neelance what do you think people will be doing with this, as soon as it's in the offical Go release? I think, at the very least, that this warrants a disclaimer. People will probably run into inexplicable crashes and having some guidance on this behavior accompanying the release, could be a good idea. Save some headaches.

I should also emphasize again that this workaround, where the slice is first explicitly copied into a memory segment managed by the JavaScript GC works really well. It doesn't have the same problem when passed to for example console.log or postMessage

[worker.js]

// I changed the name from slice to copy, becuase it is copying a portion of the ArrayBuffer
function copy({ byteOffset, byteLength, buffer }) {
  return buffer.slice(byteOffset, byteOffset + byteLength)
}

[worker.go]

var x []byte
x = append(x, 2)
x = append(x, 3)
x = append(x, 5)
y := js.TypedArrayOf(x)
z := global.Call("copy", y)
y.Release()

global.Call("postMessage", z) // from WebWorker postMessage

Additionally, the reason why I'm doing this, like this is that I'm having my Go program do expensive crypto stuff, stuff that isn't supported by any other major npm crypto package that I know of. Being able to leverage the Go standard library has tremendous value in this case. Also, there doesn't seem to be an obvious way to build a dynamic object in Go and have that pass the boundary, i.e. postMessage so I opted to pass already serialized JSON and use JSON.Parse on the browser receiving side. Since the json.Marshal Go function return []byte, error it was just natural to do it this way. If there is a standard way of serializing data to JSON in the library, I suspect, people will use it but you end up with []byte not string, if you convert this value to string before you send it, you avoid the issue entirely but if you don't you end up running out of memory very quickly.

[neelance]

You run that 3 or 4 times and the process hosting the page hard faults with an out of memory error and it is not limited to []byte an println([]int{}) is just as dangerous and please note that this behavior is not limited to WebWorker processes.

I can not reproduce this on Chrome, Firefox or Safari.

[leidegre]

@neelance that's new. What build where you using? I can test on additional systems. Also I will put up my repo somewhere for you to try.