Proposed New Go GC: Transaction-Oriented Collector

Re:Proposed New Go GC: Transaction-Oriented Collector by cmurphycode on Friday June 24, 2016 @12:38PM (#11971208)

I'm having trouble understanding what the practical difference between the transaction concept and something like RAII. It may just be the example they chose (goroutine processes an incoming request, does not "share" the contents with anyone else, and terminates when complete) but nonetheless I'm having a mental block. Can anyone clarify?

Note that I'm not saying that they should've used RAII along with existing GC, I'm just trying to distinguish the transaction concept and the RAII concept.

[ Parent | on HN ]

Re:Proposed New Go GC: Transaction-Oriented Collector by pcwalton on Friday June 24, 2016 @12:43PM (#11971264)

RAII is completely static; the lifetimes of all (uniquely-owned) objects are determined at compile time with a set of rules based on the language syntax. But the "published"/"local" distinction as in this GC is dynamic: the compiler does not (and cannot) statically work out which objects are published and instead determines that at runtime.

This basic distinction leads to completely different implementations.

[ Parent | on HN ]

Re:Proposed New Go GC: Transaction-Oriented Collector by stormbrew on Friday June 24, 2016 @12:41PM (#11971238)

If you take the corollary to RAII (resource disposal is destruction) as a given, then this (and any other automatic GC) system does not fit it. In C++ RAII, deallocation and deinitialization happens deterministically. In this it does not.

[ Parent | on HN ]