Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

On Fri, May 12, 2017 at 4:55 PM T L 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

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

Maybe that tells us something about the prescience of the design decisions made by Go's authors. -- 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

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

On Saturday, May 13, 2017 at 3:42:36 PM UTC+8, Sokolov Yura wrote: > > 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. >

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

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

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

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. -- You received this message because you are

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

Reference counting does not come without unforseen stalls - dereference a huge structure with millions of objects! -- 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

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

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

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

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.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

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. > > >

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

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 On Friday, May 5, 2017 at 12:10:01 AM UTC-3, T L wrote: > > ARC would be

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

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() dealWithSt() So, you have two choices: - either you have to find base address for pointer on every rc increment/decrement - and it

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

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:

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

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

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

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

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

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