This is useful; I've been puzzled by the actual behavior of a garbage collector. For instance, you might be dismayed, after implementing generational GC, that it benchmarks worse compared to reconfiguring for pure mark and sweep. Some visualization could help explain why. Raw execution profiling isn't all that helpful because it is entangled with the program, so you have to rely on collecting and logging various statistics from the collector.
Yea kinda annoying by the time I finished reading/watching the no-gc and reference count gc the animations were all done. Even better if they were side by side.
Author here. That's a nice trick to put the animations side-by-side. Thanks!
I had looping versions of the images, but changed them to stop because it seemed confusing to not clearly see the initial and ending states. Refreshing the page to replay an image seemed to work ok, but maybe not in all browsers?
The github project has versions animating longer runtime programs. They are linked from the smaller images in the blog post and might be useful to open side-by-side when reading the text.
I've found that even in cases where a normal refresh won't restart the animations, a Ctrl-F5 will (forcing the images to be reloaded from the server, instead of cache). This is in Firefox on Arch.
On a total tangent, I've never been satisfied with the analogy of "garbage collection" for what memory managers do ... and tried to come up with something better [1]. Not surprisingly, it came up when I was actually washing dishes :)
Pure 2-space copy collectors are very rare. Typically they are generational, so most GCs end up only copying recently allocated data (which is much more likely to be garbage).
In general though, the more frequently you GC, the more time you spend overall doing GC. This is part of why reference counted implementations tend to be slower (amortized) than other GC algorithms.
