0

Looking at Java/OpenJDK, it seems that every “new” garbage collection implementation is roughly one magnitude larger than the preceding one.

What are the sizes of Garbage Collector implementations in other runtimes like the CLR? Can a non-trivial improvement in garbage collection be equated with a sharp increase in the size/complexity of the implementation?

Going further, can this observation be made about Garbage Collector implementations in general or are there certain design decisions (in Java or elsewhere) which especially foster or mandate these size increases?

Kara
  • 6,115
  • 16
  • 50
  • 57
soc
  • 27,983
  • 20
  • 111
  • 215
  • 3
    “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” Bill Gates. – Hans Passant May 20 '13 at 12:51
  • 2
    Exactly, that's why I' asking. Even a linear increase of code translates to a more-than-linear increase of complexity. My question comes down to “can we do better in topic X, where we seem to experience a more-than-linear increase of code size?”. I'm sorry if this question is close-worthy to you. – soc May 20 '13 at 14:01

1 Answers1

1

Really interesting question... really broad but I'll try my best to give decent input.

Going further, can this observation be made about Garbage Collector implementations in general or are there certain design decisions (in Java or elsewhere) which especially foster or mandate these size increases?

Well java's garbage collector initially didn't support generations, so adding this feature made it grow in size. One other thing that adds to the size/complexity of the jvm garbage collector is its configuration. The user can tweak the gc in a number of ways which increases the complexity. See this doc if you really want to know all the tun-able features of the jvm garbage collector http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

This stackoverflow answer goes into this in a bit more depth https://stackoverflow.com/a/492821/25981

As to comparing size vs features...

Here is a very simple garbage collector for C: https://code.google.com/p/dpgc/

It has very few features and even requires the user to mark blocks as references are shared. It's size is very small weighing in at one C file and one header file.

Compare this to a fully featured gc as used in the .net framework. Below I've included a bunch of talks with the two architects of the .net garbage collector. http://channel9.msdn.com/Tags/garbage+collector

Specifcally this link: http://channel9.msdn.com/Shows/Going+Deep/Patrick-Dussud-Garbage-Collection-Past-Present-and-Future they discuss the evolution of the .net gc both interns of featuers and complexity( which is related to lines of code.)

Community
  • 1
  • 1
chollida
  • 7,834
  • 11
  • 55
  • 85
  • Very nice! I'm going through the links and the GC implementation is pretty interesting! – soc May 29 '13 at 18:58
  • What's your guess about the future? Will GCs keep growing in an unbounded fashion or will it be possible to tackle the increasing complexity, maybe by implementing improvements elsewhere (e. g. adding support for value types to the JVM to reduce the amount of produced garbage)? – soc May 29 '13 at 19:04
  • @soc I'm not an expert on what's the state of the art, but the jvm and clr are only going to get more complex. They are getting very divergent requirements. Things such as allocating many small blocks from functional languages, longer running processes, more real time applications, more user level control over when a gc happens and what is collected, more cores/threads, larger more complicated data structutres, and more mixed environment integration( think C bindings)) – chollida May 29 '13 at 19:53