3 ms·
Go is a language built on concurrency. Today's computers are usually allocated a lot of memory resources. Garbage collection is required but even a hybrid STW
by ChikkaChiChi 12y ago
Go is a language built on concurrency. Today's computers are usually allocated a lot of memory resources.
Garbage collection is required but even a hybrid STW only reduces latency but doesn't eliminate it. Nor is there seemingly any foreseeable way of allowing developers to issue a GC request in a timely fashion.
What if, prior to enacting GC, Go concurrently shifted from it's current memory allocation to an exact clone, cleaned up, then shifted back? Or maybe it cleans as it's cloning, enabling a shift to a newer, cleaner allocation? Sure, there would be latency during the switch, but it would be considerably less than stopping everything and waiting for GC to finish.
- howeyc 12y agoplease forgive my ignorance, but aren't you basically describing a "mark and sweep"[1]? [1] https://en.wikipedia.org/wiki/Mark_and_sweep#Moving_vs._non-moving https://en.wikipedia.org/wiki/Mark_and_sweep#Moving_vs._non-...
- aidenn0 12y agoI think that's closer to Cheney's algorithm (which is one of the easier ones to make bounded-latency actually).
- ChikkaChiChi 12y agoI'm new to these concepts, so please forgive me for coming up with something that already exists. I guess then the question becomes why would the roadmap avoid such an implementation?
- hedgehog 12y agoC4 is a well known pauseless GC, the paper is good and digging through the citations will get you pretty caught up on the theory and practice: http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf http://www.azulsystems.com/sites/default/files/images/c4_pap...