Hacker News new | past | comments | ask | show | jobs | submit login
Visualizing Garbage Collection Algorithms (atomicobject.com)
329 points by silentbicycle on Sept 3, 2014 | hide | past | favorite | 22 comments



If you find this interesting, you might also enjoy "A Unified Theory of Garbage Collection" by Bacon et all: http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf


Also, "Uniprocessor Garbage Collection Techniques" (https://ritdml.rit.edu/bitstream/handle/1850/5112/PWilsonPro...) is a great survey paper, and _The Garbage Collection Handbook_ by Jones, et. al (http://gchandbook.org/) is an excellent book covering the field as of pretty recently.


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.


Very cool, it would be nice if the animations looped though!


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.


Paste this into your address bar, and press Ctrl-F5 to make it loop again.

  data:text/html,<img src="http://d37rcl8t6g8sj5.cloudfront.net/wp-content/uploads/NO_GC.gif" /> <img src="http://d37rcl8t6g8sj5.cloudfront.net/wp-content/uploads/REF_COUNT_GC.gif" /> <img src="http://d37rcl8t6g8sj5.cloudfront.net/wp-content/uploads/MARK_SWEEP_GC.gif" /> <img src="http://d37rcl8t6g8sj5.cloudfront.net/wp-content/uploads/MARK_COMPACT_GC.gif" /> <img src="http://d37rcl8t6g8sj5.cloudfront.net/wp-content/uploads/COPY_GC.gif" />


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.


Instead of looping immediately, you could make the last frame last like 6 seconds, and perhaps have a couple seconds of all-black at the beginning.


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.


Though in this particular case, just reloading the page restarted the animations just fine. Even so, I'll try C-F5 to see if that's better.


What you should do to fix that is to make the very last frame and very first frame much longer. That would make the loop obvious.

Nice graphics!


And I assume the gif that finishes first is the fastest?


That should be the very first one as it has no GC overhead whatsoever. But I guess that was obvious from the beginning.


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 :)

[1] http://sriku.org/blog/2014/07/06/dish-washing-versus-garbage...


nice. Shows why forcing GC frequently can be counter productive, esp with the copy collector


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.


Looks great! Thanks for making this.


great


ss


Obligatory Quote:

"If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell

Interestingly, this doesn't apply to Scala.


That's because the road to good code is through the gates of increasingly smarter type systems.


[Citation needed]

;)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: