Ok if GOGC is the trigger point, then out-of-memory error should be consistent on all Ubuntu 64-bit 4gb systems, right? If so, why cant peterGo reproduce the crash?
2 May 2017 16:08 tarihinde "Юрий Соколов" <funny.fal...@gmail.com> yazdı: > 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.
