Proposed New Go GC: Transaction-Oriented Collector

Interesting that they are publishing the algorithm before implementing it. I wish more people did this. This way, if the algorithm doesn&#x27;t work out, we&#x27;ll have some way of knowing. If they hadn&#x27;t published the algorithm, tried it, and then abandoned it, then nobody would have any way of knowing that there had been a negative result.<p>I don&#x27;t have high hopes for this algorithm, because my intuition is that transactions aren&#x27;t common enough to make a big difference. Looking forward to seeing the implementation and empirical data.

Interesting. The transactional hypothesis sounds like a refinement of the generational hypothesis.<p>Seems like the main advantage of this transaction oriented collector over a typical generational collector is that it precisely identifies the old-to-young pointers and thus may scan less total objects.

Looks a lot like an Arena allocator tied to a specific execution context.

I&#x27;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 &quot;share&quot; the contents with anyone else, and terminates when complete) but nonetheless I&#x27;m having a mental block. Can anyone clarify?<p>Note that I&#x27;m not saying that they should&#x27;ve used RAII along with existing GC, I&#x27;m just trying to distinguish the transaction concept and the RAII concept.

If you replace &#x27;transaction&#x27; with &#x27;stack&#x27;...

I&#x27;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&#x27;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.

A nice thing about this is that it keeps the collections happening while no users are waiting. Before seeing this I figured what they&#x27;d do for throughput might be more of a Java&#x2F;C#-like compacting young gen collection, which still introduces (short!) pauses.<p>Also, fun wrinkle: seems like <i>occasionally</i>, wrapping a slowish, mostly-self-contained, garbage-heavy function call in a goroutine could be a useful hint to this collector. It seems like it&#x27;s only useful when 1) a transactional GC on the calling thread or full GC would really be slower (e.g. calling thread keeps lots of live data so GC on it takes more work), and 2) the launch&#x2F;communication costs (expect at least µsecs) are small enough relative to gains. But interesting it&#x27;s even possible for it to work out that way.

I have a generational art program that I wrote under Go 1.4 which was absolutely crushed by 1.5&#x27;s GC. The program heavily abuses goroutines, so I&#x27;m cautiously optimistic that this optimisation would allow me to keep my version of Go current once again.

For folks looking for a collector with a similar ideal (though with a potentially more useful constraint model), you might see the Pony language [1] collector [2].<p>The essence being to take advantage of some form of isolation in a concurrent system to dynamically infer something that looks like scoping&#x2F;lifetimes.<p>[1]: <a href="http:&#x2F;&#x2F;www.ponylang.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.ponylang.org&#x2F;</a><p>[2]: <a href="http:&#x2F;&#x2F;blog.acolyer.org&#x2F;2016&#x2F;02&#x2F;18&#x2F;ownership-and-reference-counting-based-garbage-collection-in-the-actor-world" rel="nofollow">http:&#x2F;&#x2F;blog.acolyer.org&#x2F;2016&#x2F;02&#x2F;18&#x2F;ownership-and-reference-c...</a>

Somewhat off topic, but since there are growing opportunities for golang developers, I&#x27;m gonna ask a golang development question.<p>Is anyone using golang with a different language like C, rust, etc? Are you using it through linkage or through microservices?<p>What libraries are you using with golang that&#x27;s written in a different language. What does your company &#x2F;app &#x2F; system &#x2F; software do?<p>Do you recommend using libraries in a different language or using related golang libraries?

I&#x27;d like to see this tried, along with a couple of wrinkles. Could information from the escape analysis done by the Golang compiler be used to provide &quot;hints&quot; to the garbage collector to make it more efficient? Could such hints be combined with further hints from the programmer, such as &quot;finalize&quot; calls or tags? Could runtime tracing information be used to derive even more hints for more efficient GC?

I&#x27;ve been thinking about this before as RAII with optional deferring of recollection when batching would be advantageous , for instance when you have a high allocation pressure and small blocks.

We really need to stop thinking of memory as a &#x27;store&#x27;. Treat it as a cache and (a) GC naturally becomes a background process, and (b) you get persistent memory for free.

Finally a reason for me to consider using Go vs Java.

This is similar to &quot;stack promotion&quot; in Swift (<a href="http:&#x2F;&#x2F;fossies.org&#x2F;linux&#x2F;swift-swift&#x2F;lib&#x2F;LLVMPasses&#x2F;LLVMStackPromotion.cpp" rel="nofollow">http:&#x2F;&#x2F;fossies.org&#x2F;linux&#x2F;swift-swift&#x2F;lib&#x2F;LLVMPasses&#x2F;LLVMStac...</a>).<p>Objects that can be determined to stay within a local scope get allocated on the stack instead of a heap, so cleanup is very efficient.<p>The difference with Go is that decision is done at compile time in Swift and in runtime in Go.

Each release of Go seems to have yet another garbage collection algorithm, targetting a different use case each time. Presumably the previous use cases are left behind, ready for a future update going back to target them too. This leads to an infinite loop of GC alterations.<p>Does anyone feel confident that a &#x27;good enough for everyone&#x27; GC will ever be produced? If not, surely the language designers should settle on picking a type of program that they will optimise for, and sticking to it.

Nice... why hasnt the JVM ever done this?

why dont let programers choose transactions boundaries within a goroutine, so they can have fine grained control over allocations and deletions