Re:Proposed New Go GC: Transaction-Oriented Collector
by kevan on Friday June 24, 2016 @01:43PM
(#11971840)
I'm not at all an expert in this area but to me this sounds like a similar concept as Rust-esque ownership, at least internally in the runtime. If the runtime knows that an object wasn't shared by its goroutine owner and the owner goes out of scope then cleanup becomes (theoretically) much faster, if only because scope is greatly limited vs GC that has to scan the entire heap.
[ Parent
| on HN ]
Re:Proposed New Go GC: Transaction-Oriented Collector
by pcwalton on Friday June 24, 2016 @02:54PM
(#11972421)
It's no more similar to Rust than any generational collector is (which is to say: not much at all). Rust's memory management story is primarily static, while this is dynamic.
Re:Proposed New Go GC: Transaction-Oriented Collector
by cwzwarich on Friday June 24, 2016 @03:19PM
(#11972627)
Rust's memory management story is not primarily static. Anything that is allocated on the stack or anchored by a stack allocation is dynamic; it can fail, and Rust checks for failure at runtime.
Re:Proposed New Go GC: Transaction-Oriented Collector
by dikaiosune on Friday June 24, 2016 @04:11PM
(#11973056)
But rust determines at compile time when almost all allocations need to be freed (the exceptions being Rc/Arc reference counting boxes), whereas it seems like a transaction/request GC would discover that at runtime.
In other words, the allocations and deallocations are determined statically, they aren't static allocations in and of themselves.