The key observation of a GC: It must match modern hardware, and it must match the programming language for which you write it for.
Historically, Java allocated all objects on the heap. This adds GC pressure and in order to remove such GC pressure, you are soon reaching for a generational GC model. Even if you undo that mistake later on, you still have the generational GC. Functional languages are very keen on adding GC pressure as well as they tend to allocate more data than imperative programs, because their data structures are persistent and not ephemeral. Furthermore, they usually have few to no pointers from the old/tenured generation into the young/new generation, which simplifies the need of the GC forward set between generations. This makes them highly amenable to generational collection. Some languages are not exposing pointers to the programmer at all. They can usually rearrange data on the heap freely and thus have an easier time with compaction. Some implementations even does hash-consing: we hash every object under compaction and if two objects happen to have the same structure, we can just point to the single object (this of course requires immutability of said data). Even better: suppose you allocate data inside a given "region" and you have a point in the program after which you can prove that nobody needs data in that region anymore. Then you can reclaim all of that region in O(1) time. And you can also just "reset" the region and reuse its contents again and again. In general this is known as "Region Inference" (Tofte, Talpin 1994) and in some cases it performs vastly better. Years later, Makholm, Niss and Henglein showed how you can relax the Tofte/Talpin rule of using the scope of the language as region boundaries to get improved inference. There are some similarities to generational collection as well as the request-region proposal I've heard rumored Hudson/Clements are working on (Typical examples: HTTP requests, game rendering of a frame or a tick in the game logic. I also know ITA used that trick manually in Common Lisp: http://www.paulgraham.com/carl.html , point 9) Also, hardware is interesting today. At $work, we regularly hit situations where Amdahl's law hits us. There is a bottleneck in the code base, which then limits CPU utilization and we can't get it past 70% even if we try. One core is tied up trying to squeeze data through the bottleneck, and the rest of the system sits patiently waiting until that is done. Optimization can help in some cases, especially through parallelisation, but there are also situations where it is hard to make code parallel, in which case you end up with ample excess CPU time for the GC. Finally, I think the choice in Go of focusing on low latency over throughput as a first target is spot on. Once achieved you can try to regain the throughput behind the scenes by algorithmic optimization. Which is bound to happen sooner or later. On Tue, Dec 20, 2016 at 5:56 AM Tyler Compton <xavi...@gmail.com> wrote: > > https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.c48w4ifa7 > > Thoughts? How accurate is this article? If it is, why, historically, is > the work being done on the GC so concentrated on pause times? > > For more discussion: > https://www.reddit.com/r/golang/comments/5j7phw/modern_garbage_collection/ > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
