Hacker News Reader

>> In what sense are they treated as one heap? How can they be, given that V8 uses a moving GC for its JavaScript heap? Does it just mean there's some mechanism for a C++ object to refer to a JavaScript object, and vice versa?

There's a dead comment below that I vouched that goes into some detail: https://news.ycombinator.com/item?id=49709739

Essentially yes, C++ objects can refer to JS objects and vice-versa, but they don't share a heap, since, as you noted, the V8 JS heap uses a moving collector. They pass the Tracer object back and forth between the JS heap and C++ heap during GC.

Node 26 added a bunch of profiling stuff that should make this a bit easier to pick apart. I'm being lazy and waiting for perfetto support on windows to get fixed so I haven't bothered yet

I think it's a good thing to separate requirements/problems/etc.

1: Java has an horrendeous amount of unnecessary garbage due to their erasing generic design (until Valhalla ever arrives), there was some old blog post that chronicled the creation of Dictionary for C#'s System.Collections.Generic (as opposed to the initial Java-like System.Collections) and how it reduced garbage-load by an magnitude.

Java chose compatibility (code continued running as before, with the added compiler checked type safety), so you could use the same Vector, List,etc classes but it also means a ton of boxed Integer,etc objects.

C# went for proper runtime generics, packable struct:s and deprecated their initial collection classes. C++ code with templates can similarly benefit from developer controlled memory usage in places.

You don't need the absolute best GC's when your language doesn't create the same amount of GC-pressure.

2: While the compaction of objects has benefits in compactation and later runtime it does add complications everywhere (you either need to halt while updating moving pointers or have read-barriers).

3: C++ collectors are tricky to get right since compilers don't support it (I'm a bit miffed that they didn't see the GC support through and now removed it), personally I dislike that Boehm has taken so much mindshare since it's lacking in many respects and has given GC's a bad reputation. Reading this article I think it fulfills most parts well (even if it's not 100% faitful to the "abstract" C++ model even if it's probably fine in practice).

4: Reading the article I'm also surprised by the usage of plain pointers, a wrapped pointer type could've provided some concurrent marking support also (assuming optimizing compilers doesn't mess it up), some older GC or other PLang papers measured a 10:1 memory read/write ratio of real world code, so write barriers (esp if only for reference) often aren't that expensive if you're gunning for better latency via concurrent marking.

5: JS <-> C++ is probably the biggest reason they've created their own GC, early JS engines (IE6 iirc) often did reference-counting in C++ and JS GC's and could end up with reference cycles forcing JS developers to avoid certain patterns.

Having unified reachbility in the object graph:s avoids these issues since liveness, in terms of managing moving objects in one heap.

Iirc you created JS-GC:reference objects in V8 interfacing code in the past, didn't check the internals but those objects probably registered themselves with the JS GC,either to be update the references or pin those objects temporarily, you need the interface somewhere, and if the GC's can cooperate at the same time it's an improvement overall.

One thing that people almost 100% of the time miss in the Java vs C# generics discussion, is that .NET was actually being designed with generics support, but they weren't ready on time for the 2001 launch, and there were some internal fighting of they should even be delivered, thus the work was only finalised on time for .NET 2.0.

This is documented by one of the authors, Don Syme of F#'s fame, on his blog posts and the F# HOPL paper.

Meanwhile Java went through Pizza and other alternative proposals until landing were it did.

However from my point of view both ecosystems could have been much better on version 1.0, had they taken the learnings from Cedar, Modula-3, Eiffel, Sather and Oberon, among other predecessors, regarding AOT compilation and value types, in GC enabled languages.

> You don't need the absolute best GC's when your language doesn't create the same amount of GC-pressure.

Conversely, if you language (e.g. LISP) does create a huge amount of GC-pressure, it will lead to the development of the absolute best of GC technology.

Edit: no need to downvote this, it won't change the fact that both GC itself and generational GC in particular was invented specifically to make it possible to run LISP programs on the actual existing hardware in reasonable time.

> You don't need the absolute best GC's when your language doesn't create the same amount of GC-pressure.

Oilpan manages DOM nodes in Chromium. Some webapps running on POS terminals like to create and destroy thousands of them very rapidly (I’ve seen such code generated by some Java->JS transpiler used by a customer). On lower-end devices this leads to long GC pauses (10-90s) blocking all interaction. This GC is a joke for the purpose it is being used, where the heap pressure is controlled from JS code from a webapp. A generational GC would have no problems with that. Seeing Oilpan described as “high-performance” in Google docs always makes me laugh, having profiled it for some customers in the past, who were having problems with it.

On your third point (compilers and Boehm): agreed on both counts. The C++11 "garbage collection support" (declare_reachable and friends) never got an implementation and C++23 removed it, so a collector for C++ has to live without the compiler - and Boehm, being conservative on the heap and stop-the-world, is what most people think that has to mean.

It doesn't. I've been building one as a plain header-only library (SGCL, https://github.com/pebal/sgcl - my project): the heap is traced precisely through per-type pointer maps the collector builds at runtime by elimination (a word ever seen holding a non-heap value is data, for good), marking and sweeping run concurrently with the mutators and in parallel over helper threads, cycles are generational, and nothing is ever moved. What it can't do without the compiler is the stacks, which it scans conservatively, like Go before 1.4.

On the "abstract model" point: you're right that it isn't 100% faithful either. The collector reads words of objects while other threads write them, relies on word-sized stores being what every real platform makes them, and reads stacks it does not own. The rules the program has to keep are few (a tracked pointer lives on a stack or in a managed object, never shares storage with data, destructors don't touch peers) and debug builds check them, but it is engineering on top of the platforms, not the standard.

I've spent the last few years on a library-only collector for C++ (SGCL, https://github.com/pebal/sgcl), also non-moving, so a few data points on the "can it compete" question. Disclosure up front: my project, and measured so far only on Apple Silicon/macOS, one machine, nothing tuned.

On the sweep: it's true that a non-moving collector's sweep is proportional to the number of dead objects, and a moving one's isn't. In practice that cost is small and parallel: the sweep walks per-page state bitmaps (about 1 ns per object), runs the destructors of the dead objects, and is spread over helper threads while the mutators keep running - nobody waits for it. What moving actually buys you is bump allocation and locality. Per-type pages with thread-local free bitmaps get allocation to about 5 ns per object on one thread and 9 ns on 24 threads, without a pause and without moving anything; ZGC does 3.6 ns and 26 ns on the same machine. On binary-trees at depth 21, ZGC is ahead on one thread (2.5 s vs 4.5 s) but with a 1.1 GB heap against 340 MB, and on four threads they tie (1.6 s each). Go, which is also non-moving, sits at 6.3 s / 219 MB there. So "non-moving" is not what decides it; the cost of the barrier, the marking and the sweep spread over cores decides it.

On destructors: they run on the collector's threads, in parallel, not on one thread, and the rule is the same as Oilpan's - a destructor must not touch other managed objects, because they may be dying in the same sweep. I don't have a Clang plugin to enforce it statically; there is a runtime check in debug builds and an explicit escape hatch (if_alive()) for the one legitimate case, a destructor asking whether a peer is still there. Oilpan's static verification is the nicer answer to that particular problem.

Where the approaches really differ is how the collector finds the pointers. Oilpan needs a Trace() method per class (or, as someone suggested above, reflection to generate them). SGCL builds a pointer map per type at runtime by elimination - a word that is ever found holding a value that isn't a managed address is data and leaves the map for good - so plain structs with tracked pointers in them just work, at the price of a couple of rules (no union of a pointer with data, stacks scanned conservatively). Different trade-off, not obviously worse.