204515 2019-11-22 07:50:31 -0800 WebKit doesn't garbage collect MessageEvent objects with transferables quickly enough 2020-06-04 12:12:40 -0700 1 1 1 Unclassified WebKit New Bugs Safari Technology Preview Unspecified Unspecified RESOLVED DUPLICATE 203990 InRadar P2 Normal --- 1 mail webkit-unassigned cdumez webkit-bug-importer youennf ysuzuki oldest_to_newest 1592794 0 384152 mail 2019-11-22 07:50:31 -0800 Created attachment 384152 postMessage with a long list of transferables Over in the the Mapbox GL JS project, we've seen severe memory growth in WebKit and have been tracking the issue on https://github.com/mapbox/mapbox-gl-js/issues/8771. Severe memory growth means that the page's process can quickly jump to more than a gigabyte of memory when continually loading tiles (e.g. panning or zooming). We've observed that this only happens when using web workers. We use web workers to load and process tiled map data for use with WebGL, then send it to the main thread. A typical tile can have up to a few hundred ArrayBuffers. We are using `postMessage` with an array of transferable objects to avoid buffer copies. Furthermore, we've observed that _disabling_ transferable objects mostly fixes the memory growth issue and the process stays at ~500-600 MB. I've dug in to find out why this happens: When sending a message to another thread with `postMessage` (https://github.com/WebKit/webkit/blob/6a89f57fb9482c4f5afef8a863d7b0dc08ab7b94/Source/WebCore/workers/Worker.cpp#L133), WebKit creates a `SerializedScriptValue` object, passing in a list of transferable objects. The message gets serialized by the `CloneSerializer`, which adds indices to the ArrayBuffers stored directly in the `SerializedScriptValue` (https://github.com/WebKit/webkit/blob/6a89f57fb9482c4f5afef8a863d7b0dc08ab7b94/Source/WebCore/bindings/js/SerializedScriptValue.h#L120) object. The message with the `SerializedScriptValue` gets pushed to the worker's or main thread's queue. Once the event get's dispatched (https://github.com/WebKit/webkit/blob/6a89f57fb9482c4f5afef8a863d7b0dc08ab7b94/Source/WebCore/workers/WorkerMessagingProxy.cpp#L120), a new `MessageEvent` object is created, which obtains ownership of the `SerializedScriptValue`. WebKit doesn't seem to garbage collect `MessageEvent` objects frequently enough. I instrumented `SerializedScriptValue` and found that it can accumulate several thousand of those objects until GC kicks in, causing the process to allocate more and more memory. This means it's not technically a leak, but still causes excessive memory growth. A few other observations: The `MessageEvent` has to actually be dispatched into JS land. If there's no event listener, the `SerializedScriptValue`s get destructed immediately when the message is processed on the other thread. This means that the mere creation of a `MessageEvent` doesn't cause the leak. Memory grows regardless of whether the value is ever _deserialized_. I rebuilt WebKit with deserialization disabled entirely and still observed the memory growth caused by WebKit hanging on to `MessageEvent` objects. While the memory growth is impacted by the byte count of the transferred ArrayBuffers, the _number_ of elements in the transferables list has at least an equal effect. I created a small benchmark that allocates zero-size ArrayBuffer, then adds the same object 8192 times to the list of transferables. This causes the vector allocated to hold the ArrayBufferContent objects to become pretty large even if all of its members are zero because WebKit filters duplicates. When attaching a smallish ArrayBuffer to the `MessageEvent` object when it is _received_ by just executing `event.foo = new ArrayBuffer(32768)`, I was able to trigger GC of those `MessageEvent` objects much more frequently, mitigating the memory growth somewhat. This leads me to believe that GC isn't aware of the actual size of `MessageEvent` objects. It should be a combination of the byte size of the stored ArrayBuffers and the count of them. I've used the GC Heap Inspector and it looks like the `MessageEvent` objects aren't referenced from a GC root. The direction of transfer (worker → main, or main → worker) doesn't seem to matter for how frequently they are GCed. 1593055 1 webkit-bug-importer 2019-11-22 15:17:51 -0800 <rdar://problem/57442706> 1659239 2 ysuzuki 2020-06-04 12:12:40 -0700 *** This bug has been marked as a duplicate of bug 203990 *** 384152 2019-11-22 07:50:31 -0800 2019-11-22 07:50:31 -0800 postMessage with a long list of transferables long-transferable-list-leak-worker.html text/html 601 mail PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KICAgIDxtZXRhIGNoYXJzZXQ9J3V0Zi04JyAv PgogICAgPHRpdGxlPkxvbmcgVHJhbnNmZXJhYmxlcyBMaXN0PC90aXRsZT4KPC9oZWFkPgo8Ym9k eT4KCjxzY3JpcHQ+Cgpjb25zdCB3b3JrZXIgPSBuZXcgV29ya2VyKFVSTC5jcmVhdGVPYmplY3RV UkwobmV3IEJsb2IoW2AKCm9ubWVzc2FnZSA9IGV2ZW50ID0+IHsKICAgIC8vIE5lZWRlZCB0byBw cmV2ZW50IGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yMDM5OTAKICAg IGV2ZW50LmRhdGE7Cn07CgpgXSwgeyB0eXBlOiAnYXBwbGljYXRpb24vamF2YXNjcmlwdCcgfSkp KTsKCnNldEludGVydmFsKCgpID0+IHsKICAgIGNvbnN0IGJ1ZmZlciA9IG5ldyBBcnJheUJ1ZmZl cigwKTsKCiAgICBjb25zdCB0cmFuc2ZlcmFibGVzID0gW107CiAgICBmb3IgKGxldCBpID0gMDsg aSA8IDgxOTI7ICsraSkgewogICAgICAgIHRyYW5zZmVyYWJsZXMucHVzaChidWZmZXIpOwogICAg fQoKICAgIHdvcmtlci5wb3N0TWVzc2FnZSh7YnVmZmVyfSwgdHJhbnNmZXJhYmxlcyk7Cn0sIDEw KTsKCjwvc2NyaXB0PgoKPC9ib2R5Pgo8L2h0bWw+Cg==