Re: [go-nuts] GC problem

Serhat Şevki Dinçer, FYI Swapfiles by default in Ubuntu http://blog.surgut.co.uk/2016/12/swapfiles-by-default-in-ubuntu.html "By default, in Ubuntu, we usually create a swap partition." "Starting from 17.04 Zesty Zapus release, instead of creating swap partitions, swapfiles will be used by

Re: [go-nuts] GC problem

Serhat Şevki Dinçer, "why cant peterGo reproduce the crash?" Because I have swap space. $ go build ssd.go $ cat /proc/swaps FilenameType SizeUsedPriority /dev/sda5 partition79994840 -1 $ ./ssd 8 9 $ cat /proc/swaps Filename

Re: [go-nuts] GC problem

TL;DR: It depends on the kernels configuration and the amount of swap space. Longer explanation: When a malloc() is granted by the kernel, it allocates the space virtually. It doesn't yet assign physical DRAM space to the allocation because it speculates that you are not going to use all the

Re: [go-nuts] GC problem

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 "Юрий Соколов" yazdı: > There is nowhere told that GOGC defines border that

Re: [go-nuts] GC problem

I don't think it is a GC bug, but rather a trade-off of several desirable properties. The system does the following: - allocates 2gb - Since the current heap size is 0 the 10% gc limit is reached and a GC is started concurrently with the program - While the program processes the array, the GC

Re: [go-nuts] GC problem

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

Re: [go-nuts] GC problem

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

Re: [go-nuts] GC problem

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

Re: [go-nuts] GC problem

What (i think) is happening is that the GC runs concurrently with your program. After the call f(8) you have 2.2 gigabyte memory allocated. When you start the call to f(9) the GC starts a mark phase, but concurrently to that your program allocates 2.2 gigabyte more space. And before it manages to

Re: [go-nuts] GC problem

I am unable to reproduce your issue. $ cat /proc/meminfo | grep 'MemTotal' MemTotal:3946772 kB $ uname -v -p -r -s Linux 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 $ go version go version go1.8.1 linux/amd64 $ cat ssd.go package main import ( "fmt"

Re: [go-nuts] GC problem

yazdı: Your program completes without any trouble on my machine, but do note if we enter the following in an emacs scratch buffer and hit C-j to use it as a glorified calculator: (/ (* 3e8 8) (* 1024 1024 1024)) 2.2351741790771484 If each element in your array

Re: [go-nuts] GC problem

Your program completes without any trouble on my machine, but do note if we enter the following in an emacs scratch buffer and hit C-j to use it as a glorified calculator: (/ (* 3e8 8) (* 1024 1024 1024)) 2.2351741790771484 If each element in your array takes up 8 bytes, which is the case for a

[go-nuts] GC problem

Hi, I have a gc.go: package main import ( "fmt" "runtime/debug" ) const N = 3e8 func f(x int) { ls := make([]uint64, N) for i := N - 1; i >= 0; i-- { ls[i] = uint64(i) } fmt.Println(ls[x]) } func main() { debug.SetGCPercent(10) f(8) f(9) } 1st call