Serhat Şevki Dinçer, "why cant peterGo reproduce the crash?"
Because I have swap space. $ go build ssd.go $ cat /proc/swaps Filename Type Size Used Priority /dev/sda5 partition 7999484 0 -1 $ ./ssd 8 9 $ cat /proc/swaps Filename Type Size Used Priority /dev/sda5 partition 7999484 1723860 -1 $ Peter On Wednesday, May 3, 2017 at 11:24:40 AM UTC-4, Serhat Şevki Dinçer wrote: > > 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....@gmail.com > <javascript:>> 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" < >> jfcg...@gmail.com <javascript:>> написал: >> >> 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....@gmail.com >> <javascript:>> 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/topic/golang-nuts/HrZpsyfb3i0/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> golang-nuts...@googlegroups.com <javascript:>. >>> 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.
