What is your use case? The advantage of a GC over something like ARC is that you avoid having to worry about cycles in the heap. Recent GC work has reduced the traditional weakness of Tracing GCs--pauses--into a minimum (reports is 10 microseconds), so the need might not be there.
There is a paper, "A unified theory of Garbage Collection" (2004, Bacon, et.al.)[0], which explains that as you try to optimize something like ARC or a Tracing GC, they tend to end up looking much the same. In ARC, suppose you have a very large linked list of data, or a very large tree, and you remove the final pointer to that very large data structure. A naive ARC system has to remove all of that before it can continue, and this takes time. Your ARC now has pauses, much like a GC. In practice, the ARC has to stagger or cooperate this removal iteratively, but that makes it more in line with a cooperative tracing GC which doesn't stop the world. In short, the two approaches can end up being more similar than what you expect in the end. Go is already far in its optimization, so it is not that likely it would benefit from suddenly adding the other solution. The ideology is more to avoid allocating in the first place. Look at the sync.Pool API for instance, which is used in order to avoid blindly reallocating data all the time and adding GC pressure where it is not needed. [0] http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf On Thu, Feb 9, 2017 at 5:09 PM <kpr...@atlassian.com> wrote: > The feature I want most in go is automatic reference counting. I don't > really care how mainline GC works but I want the language to be open to the > possibility of ARC-GC. In order for that to be able to handle cycles you > need a weak_ptr type that can requires explicit graduation to a shared_ptr. > > What would it mean to add the weak keyword to standard go? As best I can > reason it would serve as ownership documentation under trace based and > little more so it wouldn't be harmful. At small run time cost you could > with a flag force non-nil values for all implicitly strong / shared > pointers which could aid in debugging. Is it a hopeless dream to think this > could get added one day? > > Thanks > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
