There is nowhere told that GOGC defines border that could not be reached. GOGC defines proportion that triggers GC, ie GC is triggered AFTER GOGC proportion crossed, not before.
In fact, if you allocates by small portions, then GC tries to predict when you will reach this border, and tries to start earlier. But it doesn't stop your program if you run faster and cross this border, cause current Golang GC us concurrent and tries to minimize GC pause. How could it minimize GC pause if it ought to stop whole your program to not cross GOGC proportion? And you partially right: GC of old Go's versions may stop program before GOGC proportion crossed. So, if you try Go 1.0 most likely your programm will run. But new behaviour is much better. The point: you should know your instrument and environment. No one GC enabled runtime will be happy if you allocate huge arrays (perl/python/php are exceptions, cause they use reference counting). If you ought to allocate huge arrays in GC runtime, use off-heap allocation (Java men learn that hard way). For example, you may use mmap to allocate huge array. Or, I'll repeat my self, use datastructure without huge continuous allocation (ie slice of slices for your example). Then GC will have a chance to trigger ealier and free some memory before it exhausted. 2 мая 2017 г. 1:59 PM пользователь "Serhat Sevki Dincer" <jfcga...@gmail.com> написал: The allocation request (make) is made to the runtime which covers GC, right? GC percent is also set to 10%. After 1st call returns, my app has about 2gb ram allocated. When 2nd call requests allocation, runtime cannot: - first allocate another 2gb - free the 1st buffer later due to the definition of the GOGC (GC percent). I think this is a GC bug. 2 May 2017 07:09 tarihinde "Sokolov Yura" <funny.fal...@gmail.com> yazdı: GC is triggered *after* allocation than crosses boundary. So your second > allocation is actually tries to complete before first allocation freed. And > Ubuntu with 4GB memory doesn't allow to allocate 4GB memory cause > overcommit is not enabled by default. > > Use C/C++, or buy more memory, or change your datastructure from slice to > slice of slice and allocate second dimension lazely, or call runtime.GC() > explicitely between calls to f() (it will block until GC finishes). > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit https://groups.google.com/d/to > pic/golang-nuts/HrZpsyfb3i0/unsubscribe. > To unsubscribe from this group and all its topics, 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.
