Re:Go GC: Solving the Latency Problem in Go 1.5
by the8472 on Thursday July 09, 2015 @08:42AM
(#9857483)
> Generational, concurrent, real-time, whatever other clever properties: not important.
Those properties cut down the pause time in relation to the heap size. The more sophisticated your GC the larger your heap can be for the same pause time.
Until you reach the point where you have a fully-concurrent, pause-free GC.
Of course pause-free GCs aren't free lunch either. They incur increased memory traffic, require more CPU cycles per megabyte collected, require more headroom (i.e. larger memory footprint) to maintain their properties...
Re:Go GC: Solving the Latency Problem in Go 1.5
by dilap on Wednesday July 08, 2015 @11:52PM
(#9856063)
This works for erlang 'cuz it's functional. Not gunna work for something like Go.
Something like ARC would work for Go though (right?), & I agree it's a really nice approach, and I don't really get why it's not more widely used.
Re:Go GC: Solving the Latency Problem in Go 1.5
by vezzy-fnord on Thursday July 09, 2015 @12:04AM
(#9856086)
It works for Erlang because of its process model. I don't think it has anything to do with it being functional.
Re:Go GC: Solving the Latency Problem in Go 1.5
by dilap on Thursday July 09, 2015 @12:48AM
(#9856196)
Yup, you're right. I just meant that to have a program composed of many processes that can be stopped & collected independently, those processes have to communicate 'functionally', i.e., without shared mutable memory. (So this isn't a viable approach for languages like Go where all the goroutines share memory.)
Re:Go GC: Solving the Latency Problem in Go 1.5
by masklinn on Thursday July 09, 2015 @03:40AM
(#9856628)
> So this isn't a viable approach for languages like Go where all the goroutines share memory.
Something Go has been criticised for since it was originally unveiled back in 2009.
Re:Go GC: Solving the Latency Problem in Go 1.5
by chaotic-good on Thursday July 09, 2015 @03:46AM
(#9856645)
In erlang old data structures can't reference new data. This simplifies GC a lot.
Re:Go GC: Solving the Latency Problem in Go 1.5
by vezzy-fnord on Thursday July 09, 2015 @09:37AM
(#9857753)
Immutability is orthogonal to FP as a whole.
Re:Go GC: Solving the Latency Problem in Go 1.5
by fauigerzigerk on Thursday July 09, 2015 @04:59AM
(#9856841)
If that works or not depends on the application. It doesn't work for large in-memory datasets that are acessed by multiple processes.
Erlang doesn't do anything different in its GCing algorithms or anything; it just gives each (really tiny) process its own heap, so there's lots of heaps, which can each be GCed at some opportune time when that particular (tiny) process isn't scheduled. It's stop-the-world GC, but with high-granularity worlds.
This seems to suggest, to me, that the "problem" of GC is not in its implementation algorithm. Generational, concurrent, real-time, whatever other clever properties: not important. A GC pass is problematic in proportion to the size of the heap. So, make smaller heaps. The easiest way is smaller processes.