3 ms·

Linus was quite specific about his problems with GCs. Just saying that "garbage collectors have improved" without specifics, and calling his arguments "old" doe

Linus was quite specific about his problems with GCs. Just saying that "garbage collectors have improved" without specifics, and calling his arguments "old" doesn't add much information. Can you tell us how they have improved in ways that address Linus's specific concerns? And explain how a generational garbage collector can effectively re-use freshly freed objects before they leave the cache? Which 2011 generational GCs take advantage of that idea?

ekidd 16y ago
Reusing hot memory is a pretty ancient GC technique, though the details have varied over the decades. You can Google "nursery generation" for some examples: http://www.google.com/search?q=gc+nursery+generation http://www.google.com/search?q=gc+nursery+generation The original theory was that most objects in a functional language are extremely short-lived, and you want to reclaim them quickly. But if you GC your nursery generation after every few kB of allocations, you'll also keep the memory in L1 and L2 cache. The ideal size of a nursery generation (and the value of reusing hot memory) should be measured empirically. Of course, most popular scripting language GCs are non-copying, reference-counting collectors, which means they ignore techniques that were well-understood back in the 80s. However, this has not been a barrier to the adoption of Python, Ruby, etc., because the business value of high-performance code is often minimal.
ori_b 16y ago
You can bypass the GC entirely, and keep the objects that really should be in cache live, and just reuse them. Not a pretty solution, but it's doable.
DanielRibeiro 16y ago
Yes I can: - [1, 2] The pauseless collector also has the highly desirable side-benefit of producing improved memory locality. This happens because the algorithm works by attempting to relocate groups of tightly-coupled objects into regions of adjacent memory, providing excellent paging and cache locality properties for those objects. This can also benefit highly multithreaded applications that operate on distinct sets of object data. If you read the whitepaper on Azul[3] you will get a glimpse of how things got a lot more involved. And all of this gets a lot more complicated when programmming for multiple cores[4]. But not everybody is using the Erlang VM or Sun's JVM (HotSpot). The point is generic: don't assume things are on your platform by watching other platforms. Don't use old data to guide your search, no matter how brilliant/famous the author is. [1]http://java.sun.com/products/hotspot/docs/whitepaper/Java_HotSpot_WP_Final_4_30_01.html http://java.sun.com/products/hotspot/docs/whitepaper/Java_Ho... [2]http://java.sun.com/docs/books/performance/1st_edition/html/JPAppHotspot.fm.html http://java.sun.com/docs/books/performance/1st_edition/html/... [3]http://www.infoq.com/articles/azul_gc_in_detail http://www.infoq.com/articles/azul_gc_in_detail [4]http://www.javacodegeeks.com/2011/04/erlang-vs-java-memory-architecture.html http://www.javacodegeeks.com/2011/04/erlang-vs-java-memory-a...

ekidd 16y ago

Reusing hot memory is a pretty ancient GC technique, though the details have varied over the decades. You can Google "nursery generation" for some examples: http://www.google.com/search?q=gc+nursery+generation http://www.google.com/search?q=gc+nursery+generation The original theory was that most objects in a functional language are extremely short-lived, and you want to reclaim them quickly. But if you GC your nursery generation after every few kB of allocations, you'll also keep the memory in L1 and L2 cache. The ideal size of a nursery generation (and the value of reusing hot memory) should be measured empirically. Of course, most popular scripting language GCs are non-copying, reference-counting collectors, which means they ignore techniques that were well-understood back in the 80s. However, this has not been a barrier to the adoption of Python, Ruby, etc., because the business value of high-performance code is often minimal.

ori_b 16y ago

You can bypass the GC entirely, and keep the objects that really should be in cache live, and just reuse them. Not a pretty solution, but it's doable.

DanielRibeiro 16y ago

Yes I can: - [1, 2] The pauseless collector also has the highly desirable side-benefit of producing improved memory locality. This happens because the algorithm works by attempting to relocate groups of tightly-coupled objects into regions of adjacent memory, providing excellent paging and cache locality properties for those objects. This can also benefit highly multithreaded applications that operate on distinct sets of object data. If you read the whitepaper on Azul[3] you will get a glimpse of how things got a lot more involved. And all of this gets a lot more complicated when programmming for multiple cores[4]. But not everybody is using the Erlang VM or Sun's JVM (HotSpot). The point is generic: don't assume things are on your platform by watching other platforms. Don't use old data to guide your search, no matter how brilliant/famous the author is. [1]http://java.sun.com/products/hotspot/docs/whitepaper/Java_HotSpot_WP_Final_4_30_01.html http://java.sun.com/products/hotspot/docs/whitepaper/Java_Ho... [2]http://java.sun.com/docs/books/performance/1st_edition/html/JPAppHotspot.fm.html http://java.sun.com/docs/books/performance/1st_edition/html/... [3]http://www.infoq.com/articles/azul_gc_in_detail http://www.infoq.com/articles/azul_gc_in_detail [4]http://www.javacodegeeks.com/2011/04/erlang-vs-java-memory-architecture.html http://www.javacodegeeks.com/2011/04/erlang-vs-java-memory-a...