go analysis memory mallocs

115 views
Skip to first unread message

刘桂祥

unread,
Sep 29, 2016, 2:14:06 AM9/29/16
to golang-nuts
// example1.go
package main


import "runtime"


func main
() {
    m
:= new(runtime.MemStats)
    runtime
.ReadMemStats(m)
    println
(m.Alloc, m.Mallocs)
    cap
:= 1024 * 1024 * 3
    s
:= make([]byte, cap)
    _
= s
    runtime
.ReadMemStats(m)
    println
(m.Alloc, m.Mallocs)
}

go run example1.go
32744 65
3178472 66

// example2.go
package main


import "runtime"


func main
() {
    m
:= new(runtime.MemStats)
    runtime
.ReadMemStats(m)
    println
(m.Alloc, m.Mallocs)
    cap
:= 1024 * 1024 * 4
    s
:= make([]byte, cap)
    _
= s
    runtime
.ReadMemStats(m)
    println
(m.Alloc, m.Mallocs)
}

go run example2.go
32744 65
4228984 77

why it have 12 times mallocs ??

Dave Cheney

unread,
Sep 29, 2016, 2:56:38 AM9/29/16
to golang-nuts
Be careful that the compiler isnt removing some or all of your program. Check the asm to assert that your program is not being optimised away.

Then check -gcflags=-m to see if the compiler is choosing a different escape analysis depending on the size of your allocation.

刘桂祥

unread,
Sep 29, 2016, 4:37:25 AM9/29/16
to golang-nuts
In my two examples, I use variable in makeslice that it will all escape to the heap ,  But I just want to use runtime.ReadMemStats to lookup it
and find strangely example2.go memstats.Mallocs is many times  don't know why ...

在 2016年9月29日星期四 UTC+8下午2:56:38,Dave Cheney写道:

Dave Cheney

unread,
Sep 29, 2016, 5:07:23 AM9/29/16
to golang-nuts
One way to do this might be to enable memory profiling in your program with the rate set to 1. Hopefully this will record the stack trace of every allocation. The data may need some interpretation
Message has been deleted

刘桂祥

unread,
Sep 29, 2016, 5:22:03 AM9/29/16
to golang-nuts
package main

import "runtime"

func init() {
    runtime.MemProfileRate = 1
}
func main() {
    m := new(runtime.MemStats)
    runtime.ReadMemStats(m)
    println(m.Alloc, m.Mallocs)
    cap := 1024 * 1024 * 4
    s := make([]byte, cap)
    _ = s
    runtime.ReadMemStats(m)
    println(m.Alloc, m.Mallocs)
}
go run example2.go
32744 65
4228984 76
sorry  add this to example2.go  and the results is a little different  but I also don't konw the reason to the results

在 2016年9月29日星期四 UTC+8下午5:07:23,Dave Cheney写道:

Dave Cheney

unread,
Sep 29, 2016, 5:30:54 AM9/29/16
to golang-nuts
Sorry, you'll have to work harder to generate a memory profile. My github.com/pkg/profile package may help automate some of the work, but may introduce a few allocations of its own which you will have to filter out.

刘桂祥

unread,
Sep 29, 2016, 9:00:25 AM9/29/16
to golang-nuts
package main

import "runtime"

func main() {
    m := new(runtime.MemStats)
    runtime.ReadMemStats(m)
    cap := 1024
    println("debug0")
    s := make([]byte, cap)
    println("debug1")
    _ = s
    runtime.ReadMemStats(m)
    println("memstats:", m.Alloc, m.Mallocs)
}

I use go1.4.2 and In go source code add mallocgc debug info 
here is the result:
debug0
mallocgc: 1024
mallocgc: 272
mallocgc: 32
debug1

I doubt there is other goroutine call the mallocgc  
 
but if I use go test -bench="." makeslice_test.go
func BenchmarkMakeSlice2(b *testing.B) {
    b.ReportAllocs()
    cap := 1024
    for i := 0; i < b.N; i++ {
        s := make([]byte, cap, cap)
        _ = s
    }
}
the output is:
14120 ns/op    1024 B/op       1 allocs/op
I infer the go test know all the mallocgc and also know which is  user's source code to call it  

my guess

在 2016年9月29日星期四 UTC+8下午5:30:54,Dave Cheney写道:

Dave Cheney

unread,
Sep 29, 2016, 9:04:58 AM9/29/16
to golang-nuts
You should use Go 1.7.1 or later. 

刘桂祥

unread,
Sep 29, 2016, 9:14:30 AM9/29/16
to golang-nuts

if use go1.7
in runtime/malloc.go file add mallocgc debug info and go install and go run x.go    I will get a error "signal: segmentation fault"
in go1.4.2 will not

func mallocgc(size uintptr, typ *_type, needzero bool) unsafe.Pointer {
    println("mallocgc:size=", size, "kind=", typ.kind, "needzero=", needzero)

在 2016年9月29日星期四 UTC+8下午9:04:58,Dave Cheney写道:
Reply all
Reply to author
Forward
0 new messages