How does Chrome / V8 deal with large objects in javascript?

Question

I'm trying to understand garbage collection behaviour I'm seeing with Chrome / V8 on Windows 10. The scenario is that I have a small program that receives ~ 1MiB of image data from a websocket at a rate of about 60Hz. I'm using Chrome Version 81.0.4044.113 (Official Build) (64-bit)) and Windows 10 Pro 1903.

Minimal receiving code looks like this:

var connection = new WebSocket('ws://127.0.0.1:31333');

connection.onmessage = message => {
    var dataCopy = new Uint8Array(message.data, 0);
};

Profiling in Chrome shows a sawtooth of allocations rising until a major garbage collection occurs, repeating at regular intervals. The allocations are all exactly 176 bytes, which doesn't really match up with the expected 1 MiB.

profile heap graph

I found an excellent overview of V8 GC here . If I understand correctly it seems a little surprising that I'm seeing major GC events when a minor scavenge type GC could probably pick up those allocations. Additionally, as mentioned above, the allocations seen while profiling don't have the expected size of 1MiB.

Further research indicates that there's a "large object space" as described in this SO question. Unfortunately the wiki mentioned has moved since the question was asked and I can't find any references to "large object space" at the new location . I suspect the 1MiB allocation is probably big enough to qualify as a large object and if so I would like to confirm what the actual behaviour around those is.

So my questions are:

• Why do I see this behaviour with major GC's happening regularly?
• Why are the allocations smaller than expected?
• If it's related to large object handling are there any official resources that explain how large objects are handled in Chrome / V8 and what the limits around them are?

Answer 1

In the end I filed a bug for V8 here and the answer is that Major GCs are required because the message object is allocated on Blink's heap which requires V8 to perform a Major GC to cooperatively reclaim the memory. The 176 byte objects are likely pointers to the ArrayBuffer on the heap. There is an ongoing project to make Blink's GC generational which will eventually change this behavior.