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"
"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)
}
$ go run ssd.go
8
9
$
Peter
On Monday, May 1, 2017 at 10:09:02 AM UTC-4, Serhat Şevki Dinçer wrote:
>
> <jesper.lou...@gmail.com <javascript:>> 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 takes up 8 bytes, which is the case for a
> 64bit integer, then you need at least 2.2 gigabytes of memory to allocate
> the array.
>
> Thanks for the arithmetic help, yes I am allocating 2+ gb ram
>
> Looking at your output, it is clear your operating system is not allowing
> you to malloc some contiguous piece of space for this.
>
> My os IS allowing me to allocate the ram. Note that the "2nd" call fails.
>
> There are a couple of possible things to look out for:
>
> * 32bit systems can often allocate a constrained amount of memory in one
> go.
> * You may be limited articifically by the operating system, either through
> cgroups or the 'ulimit' facility, though the latter has a rather peculiar
> way of working on linux.
> * You may not have enough memory in your system.
>
> In practice, a garbage collector will usually seek to allocate more space
> than what is needed. If we run your program with
>
> Mine is a laptop with 4 gb ram & Ubuntu 64-bit 16.04
>
> [jlouis@lady-of-pain z]$ GODEBUG=gctrace=1 ./z
> gc 1 @0.000s 16%: 0.003+0+0.34 ms clock, 0.014+0/0/0+1.3 ms cpu, 0->0->0
> MB, 0 MB goal, 8 P (forced)
> gc 2 @0.020s 0%: 0.066+256+0.048 ms clock, 0.26+0/0.038/0.097+0.19 ms cpu,
> 2288->2288->2288 MB, 2289 MB goal, 8 P
> 8
> 9
>
> we can see the garbage collector collects twice. The first one is probably
> forced by the SetGCPercentage call. The second because of the rather large
> allocation that is happening. And the amount of needed memory more or less
> coincides with the 3e8 * 8 calculation above.
>
> If I have just the 1st call, there is no crash. After the 1st call
> returns, 2nd call should be able to succeed.
> So what's happening?
>
>
--
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.
