would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[T L]

sometimes, I really want to some memory blocks be collected when they become unreferenced immediately..

[Axel Wagner]

As so often is the question: Why?

I don't believe this will ever be supported by gc; but if you think it's a good idea, you can of course do it and see whether it actually solves your problems (my prediction would be "there won't be a net change in problems", but am ready to be proven wrong).

On Thu, May 4, 2017 at 6:00 PM, T L <tapi...@gmail.com> wrote:

sometimes, I really want to some memory blocks be collected when they become unreferenced immediately..

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jesper Louis Andersen]

To see why the "immediately" solution is not adequate:

Step 1: Create a single linked list or a binary tree of a couple billion elements. Make sure there is only a single reference to the head element.

Step 2: Release the pointer to the head

Step 3: Twiddle your thumbs while your program is blocked since all elements needs to be immediately freed.

Alternative method:

Moon instructs a student --

One day a student came to Moon and said: “I understand how to make a better garbage collector. We must keep a reference count of the pointers to each cons.” Moon patiently told the student the following story: “One day a student came to Moon and said: ‘I understand how to make a better garbage collector...

On Thu, May 4, 2017 at 6:33 PM 'Axel Wagner' via golang-nuts <golan...@googlegroups.com> wrote:

As so often is the question: Why?

I don't believe this will ever be supported by gc; but if you think it's a good idea, you can of course do it and see whether it actually solves your problems (my prediction would be "there won't be a net change in problems", but am ready to be proven wrong).

On Thu, May 4, 2017 at 6:00 PM, T L <tapi...@gmail.com> wrote:

sometimes, I really want to some memory blocks be collected when they become unreferenced immediately..

--
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...@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...@googlegroups.com.

[T L]

On Friday, May 5, 2017 at 12:33:57 AM UTC+8, Axel Wagner wrote:

As so often is the question: Why?

I don't believe this will ever be supported by gc; but if you think it's a good idea, you can of course do it and see whether it actually solves your problems (my prediction would be "there won't be a net change in problems", but am ready to be proven wrong).

ARC is not part of GC.

The current official GC algorithm will tolerate the percentage of garbages set by GOGC environment variable.
The default value of GOGC is 100. That means most half of the memory allocated is garbage before gc starts.
Sometimes I want to make GOGC small. But small GOGC value will run garbage collector frequently and consume much CPU.

In fact, to find which memory blocks are garbages, most energy consumed by the garbage collector is wasteful.
For an extreme case, there are 9999 alive pointers which all reference very small memory blocks,
then a very large short-lived memory block is allocated and becomes unused soon.
If the garbage collector starts now, the collector will waste most time to find the only garbage.

If the runtime use ARC to manage pointer to the large short-lived memory block,
the memory block will be collected immediately after it becomes unused.
This will largely reduce burden of running garbage collector.

ARC would be a better option for game apps than GC, to keep the fps stable.
 

On Thu, May 4, 2017 at 6:00 PM, T L <tapi...@gmail.com> wrote:

sometimes, I really want to some memory blocks be collected when they become unreferenced immediately..

--
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...@googlegroups.com.

[T L]

On Friday, May 5, 2017 at 2:10:03 AM UTC+8, Jesper Louis Andersen wrote:

To see why the "immediately" solution is not adequate:

Step 1: Create a single linked list or a binary tree of a couple billion elements. Make sure there is only a single reference to the head element.

Step 2: Release the pointer to the head

Step 3: Twiddle your thumbs while your program is blocked since all elements needs to be immediately freed.

No, "immediately freed" doesn't mean all unused memory blocks should be released by consuming all CPU.
The unused memory blocks can be eventually collected by consuming a very small percentage of CPU.
 

[Sokolov Yura]

Where will you store reference counter for interior pointer?

type st struct { j int }
type at { i int; s st }
var a at
var s st
dealWithSt(&s)
dealWithSt(&a.s)

So, you have two choices:
- either you have to find base address for pointer on every rc increment/decrement - and it is quite expensive operation (with current GC it is done very rare),
- or you forbid interior pointers (and store a.s in separate location) - and then it is not Go language.

[oju...@gmail.com]

Maybe a 100µs GC would be fast enough for you to be at easy with your game FPS.

https://groups.google.com/forum/#!searchin/golang-dev/garbage$20collector$20microseconds%7Csort:relevance/golang-dev/Ab1sFeoZg_8/_DaL0E8fAwAJ

[feilengcui008]

If there are ARCs like shared_ptr in C++, I think there must be some kind of raw pointers not managed by gc, this means bringing more "unsafe". 

在 2017年5月5日星期五 UTC+8上午12:00:18，T L写道：

[T L]

On Thursday, May 11, 2017 at 8:48:05 PM UTC+8, JuciÊ Andrade wrote:

Maybe a 100µs GC would be fast enough for you to be at easy with your game FPS.

https://groups.google.com/forum/#!searchin/golang-dev/garbage$20collector$20microseconds%7Csort:relevance/golang-dev/Ab1sFeoZg_8/_DaL0E8fAwAJ

The 100µs is STW duration. I mean the fps may decrease some during the period of GC running.
 

[T L]

On Friday, May 12, 2017 at 10:42:24 PM UTC+8, feilengcui008 wrote:

If there are ARCs like shared_ptr in C++, I think there must be some kind of raw pointers not managed by gc, this means bringing more "unsafe". 

Yes. But "unsafe" != "not safe"
 

[oju...@gmail.com]

Any memory management strategy costs time. Reference counting is not cheap. Incrementing and decrementing millions of reference counters costs time. Please consider caching issues as well.

Go GC, as it currently stands, is very effective, as other people in this forum can confirm to you. Several Gigs of data and the only way to perceive any performance impact is by generating a profile chart! 

Only a practical test, tailored to your case, could tell if Go GC could degrade your fps. If by any chance you find a challenging situation I am sure the Go Team would be very eager to investigate, because it is increasingly difficult to find new challenges to the GC.

[T L]

On Saturday, May 13, 2017 at 12:02:39 AM UTC+8, JuciÊ Andrade wrote:

Any memory management strategy costs time. Reference counting is not cheap. Incrementing and decrementing millions of reference counters costs time. Please consider caching issues as well.

Go GC, as it currently stands, is very effective, as other people in this forum can confirm to you. Several Gigs of data and the only way to perceive any performance impact is by generating a profile chart! 

In fact, the need to ARC is not efficiency, it is predictability and consistency instead.
And I don't expect ARC to be the main memory collect way, but I think it can be a supplement.
For example, maybe two types, sync.Pointer and sync.WeakPointer can be added.
 

[Tamás Gulácsi]

Reference counting does not come without unforseen stalls - dereference a huge structure with millions of objects!

[T L]

On Saturday, May 13, 2017 at 1:26:31 PM UTC+8, Tamás Gulácsi wrote:

Reference counting does not come without unforseen stalls - dereference a huge structure with millions of objects!

Programmers can choose use ARC pointers or not.
 

[Sokolov Yura]

1. Go's GC is quite predictable.
2. Go's runtime has no deallocation without GC for simplicity. You want to return complexity to runtime.
3. Why not use other language? Go is quite opinionated by its creators. Either you share that opinion, or use other language.
For example, D language can use both GC and ARC (with template-defined custom pointer types). It also has fibers (but with fixed stack). Vibe.d adds async networking with sync interface. I think, you will be able to implement channels and select. Go ahead.

[T L]

But it looks the go ecosystem is larger and more active.  :(

[Dave Cheney]

Maybe that tells us something about the prescience of the design decisions made by Go's authors.

[Jesper Louis Andersen]

On Fri, May 12, 2017 at 4:55 PM T L <tapi...@gmail.com> wrote:

The 100µs is STW duration. I mean the fps may decrease some during the period of GC running.

This is true. But if a refcounter needs to use a bit of CPU power in the background to eventually collect data then it has the same problems with fps drops. And in general, refcount maintenance is more expensive than maintaining GC. There is a bit more instruction pressure in a system with refcounting.

I've mentioned "A unified theory of Garbage collection' by Bacon, Cheng, and Rajan (2004) before. In that paper they conjecture that refcounting and (mark'n'sweep) garbage collection are each others duals and that they tend to converge to the same methods. In short: it doesn't matter that much if you use one of the other in practice.

I'd have absolutely no qualms on using Go for a game now. A 100us stw pause can easily be hidden in a 16.7ms frame rendering time. And if you ask the GC itself, it usually reports how much time it is spending. I'd be much surprised if you don't have 16ms available per frame even in the worst situation.