

C4: The Continuously Concurrent Compacting Collector (2011) [pdf] - todd8
http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf

======
todd8
This paper on C4 is cited by a member of the Go development team in this
interesting comment about the future of Go's garbage collector:
[https://groups.google.com/forum/#!msg/golang-
dev/GvA0DaCI2BU...](https://groups.google.com/forum/#!msg/golang-
dev/GvA0DaCI2BU/1EpYa8HbxdIJ)

~~~
nulltype
The more interesting part is probably that Gil Tene, one of the authors of C4
makes some good comments on it.

~~~
tomp
Although he's technically correct, I think he's missing the point.

> Neither the pauseless algorithm, nor more recent [generational] C4 algorithm
> impose any multi-core related performance overheads compared to the most
> efficient collectors out there. There are no added cross-thread
> synchronization of any kind compared to stop-the-world algorithms. In fact,
> the whole point of a concurrent algorithm like C4 is to dramatically reduce
> GC-related synchronization overhead [stop-the-world pauses are dramatic
> synchronization points between GC and mutator threads].

The main overhead of a concurrent, compacting collector is the need for read
barrier. You simply cannot move data while the program is running without
having a way of redirecting the read requests to the latest memory location.
It's true that it's technically not _multi-core_ related overhead (instead,
it's a _multi-threading_ related overhead), but the point is moot, since with
a single core, you don't need multiple threads (in a managed language, you can
simply use fibres (user-space threads), like Go or Haskell do). The only
reason to use a multi-threaded (concurrent) GC is to support multiple cores.

~~~
nulltype
I don't know enough about GC to argue about it, but the way I read his
response (including the next paragraph which is not about multicore) he seems
to claim that there is not a severe performance penalty for a C4 style
collector, contrary to the email from Ian Lance Taylor, so I'm not sure he
missed the point. He also has a graph showing supposedly how much it's not a
severe performance penalty.

He also has like 5 more responses, not just that one.

------
nickik
I recomend this paper to everybody, its fantastic. I really wish that
prossesor people and operating systes would pay more attention to the trend
towards managed languages.

Azul did a great job at implmenting there read barrier on diffrent maschines
but the needed to patch every distribution that they where running on.

We should get benefits of these kinds of collectors on every operating system.
I really hope that in the future we can get there.

~~~
pjmlp
A trend that started with Algol 68, followed by Mesa/Cedar at Xerox PARC,
Modula-2+ at DEC Systems Research Center, Modula-3 at Olivetti Research
Center, Oberon at Swiss Federal Institute of Technology, Sing# at Microsoft
Research.

Still, no one seems to listening.

