Go1.14 implements high-performance memory allocator

Preface:

The memory allocator has also been updated in version GO1.14. Previous versions of GO caused lock contention in mheap.lock in multiple GOMAXPROCS scenarios, so the new memory allocator addresses this problem.

The logic of go1.14 memory allocator optimization is simply to remove the concept of free memory ranges, track free memory using bitmaps, and allow P to cache a portion of bitmaps.

Cc/Archives /66…

Why is MHeap a bottleneck?

Although there is a concept of multilevel caching in go’s memory design (McAche, McEntral, Mheap), McAche is lock-free because it is bound to P. Each McEntral array has a single lock whose granularity is in size class. However, the Mheap structure is globally unique, and the associated memory allocation and release monopolizes mheap.lock.

The logic of go1.14 memory allocator optimization is simply to remove the concept of free memory ranges, track free memory using bitmaps, and cache a portion of bitmaps in P.

Source code analysis

(Write it later)…

Go official memory allocator design, Go proposal, github.com/golang/prop…

The performance test

Test scripts, logic is open coroutine continuous application object.

// xiaorui.cc

package main

import (
    "fmt"
    "sync"
    "time"
)

type node struct {
    ident   string
    context string
}

func run() {
    iter := 100000
    data := make(map[int]node, iter)
    ts := time.Now().String()

    for i := 0; i < iter; i++ {
        data[i] = node{
            ident: ts,
            context: ts + ts + ts,
        }
    }

    for i := 0; i < iter; i++ {
        delete(data, i)
    }
}


func batchRun() {
    wg := sync.WaitGroup{}

    for i := 0; i < 100; i++ {
        wg.Add(1)
        go func() {
            run()
            wg.Done()
        }()
    }

    wg.Wait()
}

func main() {
    start := time.Now()
    for i := 0; i < 100; i++ {
        batchRun()
    }

    cost := time.Since(start)
    fmt.Printf("time cost: %+v \n", cost)
}Copy the code

In the case of concurrent intensive memory allocation, THE performance of GO1.14 is faster. (Section size affects results)

// xiaorui.cc go 1.13 vs go 1.14 time cost: 1m11.458039901s time cost: 57.242940201s go 1.13 vs go 1.14 time cost: 2 m27. 298913751 s time cost: 1 m56. 458370589 sCopy the code

CPU consumption is not much different

By comparison with Golang Pprof top, go 1.14 has fewer runtime.futex calls than GO 1.13. The same results were obtained using Strace statistics.

---

xiaorui.cc