On: Minimize Heap Allocations in Node.js

[cogman10]

I skimmed this [1] but I believe you are correct.

It's a generational moving GC which means bump allocation typically.

[1] https://v8.dev/blog/trash-talk

[rockwotj → cogman10]

Looking at the code it seems to use a linear allocation buffer: https://github.com/oilpan-gc/cppgc/blob/main/src/heap/cppgc/...

[Leszek → rockwotj]

You're looking at Oilpan, which is the C++ GC for Blink, not the one for V8.

But, the V8 one is very similar in many respects (the same team works on both), including linear allocation buffers.

[rockwotj → Leszek]

They are one and the same I as I understand it now:

https://v8.dev/blog/oilpan-library https://github.com/v8/v8/blob/main/include/cppgc/README.md

Quote for the frist article:

> We launched the library [Oilpan] in V8 v9.4 and enabled it in Blink starting in Chromium M94.

[Leszek → rockwotj]

It's a bit confusing, I agree -- Oilpan is part of the V8 sources for shipping-the-org-chart reasons, but it isn't actually the GC used by V8 itself for JavaScript objects and the JS heap, it's the GC used by Blink for DOM objects etc.

The biggest difference between the two is that JS objects are fully managed by the GC and V8 has full control over their layout and access (e.g. they are accessed via explicit pointer + field offset in the runtime), while Oilpan works on C++ objects; there's a billion consequences of this, in particular that JS objects are movable (because we can safely update pointers) and Oilpan objects aren't (because C++ can do pretty much whatever it wants).

[cogman10 → Leszek]

At one point, it was supposed to be the universal GC for chrome. In fact, that was cited as the major holdup for getting the DartVM into chrome, they wanted a unified GC between dart, v8, and the DOM.

[rockwotj → Leszek]

Thanks for clarifying!