Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

Any updates on ROC for golang? I think our services encountered some scalability issues, similar to https://github.com/golang/go/issues/17969 On Tuesday, May 16, 2017 at 10:06:25 PM UTC+8 Ian Lance Taylor wrote: > On Tue, May 16, 2017 at 2:01 AM, wrote: > > > > Generational and Compact gc have

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

On Tue, May 30, 2017 at 12:44 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote: > On Tuesday, May 16, 2017 at 4:06:25 PM UTC+2, Ian Lance Taylor wrote: >> >> On Tue, May 16, 2017 at 2:01 AM, wrote: >> > >> > Generational and Compact gc have already been thought best practice. But

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

On Tuesday, May 16, 2017 at 4:06:25 PM UTC+2, Ian Lance Taylor wrote: > > On Tue, May 16, 2017 at 2:01 AM, wrote: > > > > Generational and Compact gc have already been thought best practice. But > > golang doesn't adopt it. Who can tell me the reason? > > Now let's consider

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

The following article showing that a compacting gc can make the application run faster in some cases might be of interest as well: https://shipilev.net/jvm-anatomy-park/11-moving-gc-locality/ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

My feeling is a per-P bump-pointer allocation space can fit into the current go's GMP model for faster allocation than the current allocation path with span calculation and free slot search. But anyway the fragmentation is a big pain. I'm not sure the non-moving property of go GC is the design

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

To perform concurrent compaction/copying you should use Read Barriers. Read barrier is very expensive. It is less expensive in Java, cause pointers always looks into beginning of allocation (so redirect pointer is in known position). But it will be very expensive in Go cause of interior

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

On Tue, May 16, 2017 at 8:27 PM, wrote: > > It's not clear why when you use "a set of per-thread caches" you "lose > advantages of bump allocator". At any point of time, a single goroutine is > executed on a thread. The points when a goroutine gains and loses the >

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

It's not clear why when you use "a set of per-thread caches" you "lose advantages of bump allocator". At any point of time, a single goroutine is executed on a thread. The points when a goroutine gains and loses the execution context of a thread, and when it is transferred from one thread to

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

Thanks for your patient and wonderful reply. 在 2017年5月16日星期二 UTC+8下午10:06:25，Ian Lance Taylor写道： > > On Tue, May 16, 2017 at 2:01 AM, wrote: > > > > Generational and Compact gc have already been thought best practice. But > > golang doesn't adopt it. Who can tell me the

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

Thanks for your patient and wonderful reply. 在 2017年5月16日星期二 UTC+8下午10:06:25，Ian Lance Taylor写道： > > On Tue, May 16, 2017 at 2:01 AM, wrote: > > > > Generational and Compact gc have already been thought best practice. But > > golang doesn't adopt it. Who can tell me the

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

What a fantastic discussion. Thanks so much, folks! -- 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,

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

See also: Norman R. Nielsen. Dynamic memory allocation in computer simulation. Communications of the ACM, 20(11):864–873, November 1977. This was the first place I saw this result. A later improvement was realizing this allowed headerless BIBOP organization of allocated memory. I think the

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

The Johnstone / Wilson paper "The memory fragmentation problem: solved?" [1] is the original source. Modern malloc systems including Google's TCMalloc, Hoard [2], and Intel's Scalable Malloc (aka Mcrt Malloc [3]) all owe much to that paper and along with other memory managers all segregate

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

On Tue, May 16, 2017 at 9:06 AM Ian Lance Taylor wrote: > On Tue, May 16, 2017 at 2:01 AM, wrote: > > > > Generational and Compact gc have already been thought best practice. But > > golang doesn't adopt it. Who can tell me the reason? > > This has been

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

Thanks for the enlightening and interesting reply, Ian. One quick question: do you have a link or a short description of why “modern memory allocation algorithms, like the tcmalloc-based approach used by the Go runtime, have essentially no fragmentation issues”? I was curious, but a quick

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

This is a really great response. I appreciated the high-level overview in one place like this, and I feel like I learned something. Thanks for writing it up, Ian. On Tue, May 16, 2017 at 10:05 AM, Ian Lance Taylor wrote: > On Tue, May 16, 2017 at 2:01 AM,

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

On Tue, May 16, 2017 at 2:01 AM, wrote: > > Generational and Compact gc have already been thought best practice. But > golang doesn't adopt it. Who can tell me the reason? This has been discussed in the past. Ignoring details, the basic advantages of a compacting GC are 1)

[go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

Generational and Compact gc have already been thought best practice. But golang doesn't adopt it. Who can tell me the reason? -- 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,