I bisected the issue. Output:

You are probably looking for a change made after 167864 (known good), but no later than 167872 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/4ceb5c2d2087a23e5629427b398cc71f35b04287..67d13d556a713a64e41c2ff76f58f4839296f37e

This result may be bogus, as there's no obvious culprit in that range.

Yes, the result was bogus. I needed the --no-sandbox flag for older versions to stop the renderer from crashing at startup.

I haven't succeeded in bisecting because the regression happened a long time ago and many other bugs have existed in various versions which stop the repro from working.

There definitely were versions that worked.

Incidentally, garbage collection does free the memory when it happens (as long as DevTools is not open). But it doesn't trigger until several GB has been allocated, which is enough to crash most machines. I have been using ulimit -v 2000000 for testing as this causes the crash to happen reasonably quickly, and also avoids the OOM killer taking out other processes.

Assigning to yhirano who knows more about the interaction between GC and WebSockets.

It is similar to  issue 749482 . yukishiino@, can you take a look?

+keishi@ as a GC expert.

This is similar to  issue 339480  which was fixed as https://src.chromium.org/viewvc/blink?view=revision&revision=166825. The code is deleted by https://codereview.chromium.org/531183003.

As far as I investigated, blink::MessageEvent is consuming memory without reporting it to V8, hence V8 GC doesn't get scheduled.

The repro case doesn't use ArrayBuffer.  The message data is stored in blink::MessageEvent::data_as_string_ of type WTFString, and the memory usage is not reported to V8.

The situation looks quite similar to  Issue 749482  .  The common pattern is that Blink stores data internally without telling it to V8, and converts Blink-internal data to V8 representation lazily when accessed.  The repro cases never touches the data so there is no chance to report the memory usage to V8 nor increase the memory usage of V8 heap.

Thanks for digging!

Would it be possible to report the size of MessageEvent::data_as_string_ to V8 even before the MessageEvent is touched  by V8?

The point is that if some memory cannot be released without triggering a V8 GC, the memory should be reported to V8. Whether V8 has touched the data or not does not really matter.

Another option is to convert the WTFString to a v8::String and store it in data_as_string_ (i.e. change the type of data_as_string_ from WTFString to v8::String) and use wrapper-tracing to make the v8::String alive.  Then, V8 will be aware of the memory usage.  Since v8::String is NOT v8::Context-aware, it's not so dangerous.