Runtime | Tony Bai

标签 runtime 下的文章

TB一周萃选[第7期]

一月 28, 2018
0 条评论

本文是首发于个人微信公众号的文章“TB一周萃选[第7期]”的归档。

img{512x368}

我看过小马哥(哈维尔·马斯切拉诺)踢球，
你看过小马哥踢球，
他看过小马哥踢球。
我们看过小马哥踢球，
你们看过小马哥踢球，
他们看过小马哥踢球！

— 改编自网络资料

都说三九天是一年中最冷的一段时间，但我们这里稍有偏差，就个人赶脚：四九、五九才是我们这里温度的最低点。这一周的感受用一句东北话来说就是嘎嘎冷！体感温度近零下30摄氏度：一开车门，好不容易凝聚在身体周遭的“热量”瞬间散失，似乎已经有10多年没有感觉到如此持续的寒冷了。

但巴萨新闻中的一则消息却让作为阿根廷和巴萨双重球迷的我感到了一丝温暖。北京时间本周五凌晨，在巴萨主场与西班牙人队的国王杯四分之一决赛前，梦三主力、巴萨后防中坚小马哥携着自己的家人在巴萨队友的列队欢迎下、在诺坎普主场球迷山呼海啸般的欢呼声中走入诺坎普，和大家做着最后的告别。对于一名职业球员来说，这已经算是在俱乐部层面能得到的最高荣誉了。

虽说梅球王是我的最爱，但小马哥也是我十分喜欢和尊敬的一名足球运动员，在他的身上你几乎能够看到一名职业运动员所有的“正能量”标签：高超的专业能力、职业、自律、低调、坚毅、领导力、热爱足球、热爱家庭、没有绯闻等。对于小马哥这样的功勋球员，以“不只是一家俱乐部(Mes que un club)”为使命的巴萨俱乐部也做出了最大的让步，为小马哥设定了较低的转会费，让他可以按照自己的意愿成功转会到中超的华夏幸福。

小马哥将自己职业生涯中最好的七年奉献给了巴萨，对巴萨的贡献可谓是居功至伟！看看小马哥为巴萨赢得的荣誉吧。

img{512x368}

感谢小马哥，祝福小马哥在后续的职业生涯中一切顺利！在中国生活的快乐！

一、一周文章精粹

1. Hello, 中国!

由于“众所周知”的原因，大陆地区的Gopher们在访问Go官方站点时十分困难。这一定程度上影响了Go在大陆地区的推广。但Go语言在大陆地区的发展势头让Go team看到了建立大陆地区mirror站的必要性。就在这一周，中国的Gopher们迎来了一个Go官方的好消息，那就是Go语言大陆地区官方网站上线了。网站的地址是https://golang.google.cn，这个网站目前就是Go官方站的mirror，很多深层的链接可能依然指向源站，不过迈出第一步总是好的。

文章链接：“Hello，中国!”

2. 尚未修复的逃逸分析缺陷(Escape-Analysis Flaws)

William Kennedy是著名的Go语言培训师，也是《Go in action》这本书的作者之一，他在Ardan Labs网站上撰写了许多篇关于Go语言的学习资料。其中最新的一篇“Escape Analysic Flaws”探讨了当前Go compiler(截至到Go 1.9)中依然存在的逃逸分析的缺陷，包括：

Indirect Assignment
Indirect Call
Slice and Map Assignments
Interfaces
Unknown

Go实际编码过程中减少在heap上的内存分配是提升性能，减少cost的好方法，通过William的分析，我们也期望能做到尽量避免逃逸的情况，但有些时候做起来很难。因此，让Go compiler自身变得更聪明才是终极解决方法。

文章链接：“Escape-Analysis Flaws”

3. Github用户使用的编程语言排名

国外友人Ben Fredericksont通过对2011以来github的public event数据的分析，得出了关于github上编程语言的使用变化趋势，包括：top ten活跃语言、主流语言的活跃程度变化趋势、2018值得学习的几个热门新语言、几门趋势下降很快的语言、科学计算语言的变化趋势、函数式语言的变化趋势等。

img{512x368}
图：2018值得学习的几个热门新语言

文章链接：“Ranking Programming Languages by GitHub Users”

4. Nonblocking I/O指南

Go语言的默认的网络I/O编程模型是阻塞I/O，这可以大幅降低应用开发者在处理网络I/O时的心智负担。但这也仅限于“用户层面”，研究过Go runtime调度的gopher都知道，在runtime内部，关于网络I/O的调度实际上是Nonblocking的。imgix的工程师Cindy Sridharan曾全面细致总结了对Nonblocking I/O的技术要点的理解，这里推荐给大家。

img{512x368}

文章链接：“Nonblocking I/O”

5. 预测：2018年的最佳Linux发行版

Linux内核已经成为这个星球上使用最为广泛的操作系统内核了，无论是云服务器，还是桌面机，从移动终端到Iot设备，现代人身边10米范围内，一般总能找出一台运行着Linux内核的设备。而对于用户而言，看到的更多是基于Linux内核的各种发行版，比如：Ubuntu、CentOS等。年初JACK WALLEN在linux.com博客上撰文预测了2018年各个领域的最佳Linux发行版，包括从sysadmin、桌面版、server版、便携版、iot版等多个方面。这些预测基于distrowatch.com上各个发行版的人气排名。

文章链接：“best linux distributions for 2018”

6. 如何使用Go语言创建基于AWS Lambda的serverless应用

AWS Lambda宣布支持Go不久，各路关于如何使用Go在AWS Lambda创建serverless应用的资料便接踵踏来。这里推荐的就是其中的一篇。对于想使用Go在AWS Lambda上“尝鲜”的Gopher们，这是个不错的入门文章。

img{512x368}

文章链接：“Serverless Golang API with AWS Lambda”

7. JavaScript框架终极指南

JavaScript这门语言虽然“颜值”不那么高，但这并不妨碍它抱上浏览器这一“大腿”，并还进军了服务端市场。在这一过程中，JavaScript领域诞生了诸多Framework，最出名的莫过于三巨头：Angular、React和Vue.js这三个框架了。除此之外，还有太多我甚至没有听过名字的框架。这里推荐的“JavaScript框架终极指南”一文就是对JavaScript目前的主流框架的状态、优劣势进行详细总结说明的一篇文章，希望能帮助你挑选出最适合你的Js框架。

img{512x368}

文章链接：“The Ultimate Guide to JavaScript Frameworks”

二、一周资料分享

1. ROSCon 2017资料

ROS作为世界上应用最为广泛、最具影响力的开源机器人操作系统，它从2012年开始举办的ROSCon大会就备受关注，2017年ROSCon大会在加拿大温哥华举行。在人工智能、智能驾驶如此“热”的今天，ROS作为很多智能驾驶平台（比如百度的Apollo、tierIV的autoware等）的底层支撑组件自然吸引了自全世界范围内的学者和工程师的眼球和参与。这次大会的topic是干货满满，由于是ROS2发布正式版前的最后一次大会，因此涉及ROS2的topics十分多，算是为ROS2正式登场预热(注：ROS2在2017.12.10正式发布，代号：Ardent Apalone)。

img{512x368}

资料分享链接：“ROSCon 2017资料”

三、一周工具推荐

1. carbon：一款源码图片创建和分享的工具

在技术文章写作中，我们会有大量的代码截图的需求，但限于客观原因，截图的质量和风格难于把控。Carbon这个工具就是来帮助解决这个问题的。Carbon是一个在线服务，支持通过将源码文件拖拽到生成框中自动生成代码图片。Carbon支持几乎所有主流语言，并可以自动识别，并且Carbon支持多种风格的代码高亮样式，比如：Monokai、Solarized等。

img{512x368}
图：Carbon主页

img{512x368}
图：Carbon生成的Go源码图片

推荐工具链接：Carbon

四、一周图书推荐

1.《Hello World! Second Edition – Computer Programming for Kids and Other Beginners》

都说00后是互联网时代的原住民，那么伴着这轮AI热，我们是否可以大胆地说2020后或2025后是AI时代的原住民呢。这让我仿佛看到了“超能陆战队”中男主小宏所使用的IT装备和掌握的编程技能。也许在未来10年后，编程就会像数学、语文一样成为在AI时代的基本技能。而这一切都要从娃娃抓起，从编程基础抓起。Sande父子合作编写的这本《Hello World》图文并茂地将孩子带入二进制的程序世界，孩子将在轻松惬意的氛围中学习基础的编程概念：如内存、循环、输入和输出、数据结构和图形用户界面等。对于如今智力水平普遍较高的孩子们来说，这些内容就像小游戏般容易掌握。书中使用的教学语言是Python，别忘了目前的Python可是AI时代的top3语言，并是AI第一语言的强有力的竞争者。

很多人说：当前儿童编程的第一语言是MIT的Scratch，我不能否认这一点，Scratch就是为Kids们所创造的，它是MIT继Seymour Papert教授在创建LOGO语言、探索儿童编程教育后的又一杰作。全图形化的编程教学让孩子们很是喜欢。但我个人觉得如果能结合一些真实代码，尤其是对于中高年级的学生来说，将是大有裨益的。

作为Gopher，我一直在想足够简洁的Go语言也是可以作为儿童编程教学语言的，希望能早日出现一门以Go语言为第一教学语言的儿童编程图书。

img{512x368}

图书链接：
《父与子的编程之旅 – 与小卡特一起学Python》
《Hello World! Second Edition – Computer Programming for Kids and Other Beginners》

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式：

微博：http://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：
img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Goroutine调度实例简要分析

十一月 23, 2017
13 条评论

前两天一位网友在微博私信我这样一个问题：

抱歉打扰您咨询您一个关于Go的问题：对于goroutine的概念我是明了的，但很疑惑goroutine的调度问题, 根据《Go语言编程》一书：“当一个任务正在执行时，外部没有办法终止它。要进行任务切换，只能通过由该任务自身调用yield()来主动出让CPU使用权。” 那么，假设我的goroutine是一个死循环的话，是否其它goroutine就没有执行的机会呢？我测试的结果是这些goroutine会轮流执行。那么除了syscall时会主动出让cpu时间外，我的死循环goroutine 之间是怎么做到切换的呢？

我在第一时间做了回复。不过由于并不了解具体的细节，我在答复中做了一个假定，即假定这位网友的死循环带中没有调用任何可以交出执行权的代码。事后，这位网友在他的回复后道出了死循环goroutine切换的真实原因：他在死循环中调用了fmt.Println。

事后总觉得应该针对这个问题写点什么? 于是就构思了这样一篇文章，旨在循着这位网友的思路通过一些例子来step by step演示如何分析go schedule。如果您对Goroutine的调度完全不了解，那么请先读一读这篇前导文《也谈goroutine调度器》。

一、为何在deadloop的参与下，多个goroutine依旧会轮流执行

我们先来看case1，我们顺着那位网友的思路来构造第一个例子，并回答：“为何在deadloop的参与下，多个goroutine依旧会轮流执行？”这个问题。下面是case1的源码：

//github.com/bigwhite/experiments/go-sched-examples/case1.go
package main

import (
    "fmt"
    "time"
)

func deadloop() {
    for {
    }
}

func main() {
    go deadloop()
    for {
        time.Sleep(time.Second * 1)
        fmt.Println("I got scheduled!")
    }
}

在case1.go中，我们启动了两个goroutine，一个是main goroutine，一个是deadloop goroutine。deadloop goroutine顾名思义，其逻辑是一个死循环；而main goroutine为了展示方便，也用了一个“死循环”，并每隔一秒钟打印一条信息。在我的macbook air上运行这个例子（我的机器是两核四线程的，runtime的NumCPU函数返回4）：

$go run case1.go
I got scheduled!
I got scheduled!
I got scheduled!
... ...

从运行结果输出的日志来看，尽管有deadloop goroutine的存在，main goroutine仍然得到了调度。其根本原因在于机器是多核多线程的（硬件线程哦，不是操作系统线程）。Go从1.5版本之后将默认的P的数量改为 = CPU core的数量（实际上还乘以了每个core上硬线程数量），这样case1在启动时创建了不止一个P，我们用一幅图来解释一下：

img{512x368}

我们假设deadloop Goroutine被调度与P1上，P1在M1(对应一个os kernel thread)上运行；而main goroutine被调度到P2上，P2在M2上运行，M2对应另外一个os kernel thread，而os kernel threads在操作系统调度层面被调度到物理的CPU core上运行，而我们有多个core，即便deadloop占满一个core，我们还可以在另外一个cpu core上运行P2上的main goroutine，这也是main goroutine得到调度的原因。

Tips: 在mac os上查看你的硬件cpu core数量和硬件线程总数量：

$sysctl -n machdep.cpu.core_count
2
$sysctl -n machdep.cpu.thread_count
4

二、如何让deadloop goroutine以外的goroutine无法得到调度？

如果我们非要deadloop goroutine以外的goroutine无法得到调度，我们该如何做呢？一种思路：让Go runtime不要启动那么多P，让所有用户级的goroutines在一个P上被调度。

三种办法：

在main函数的最开头处调用runtime.GOMAXPROCS(1)；
设置环境变量export GOMAXPROCS=1后再运行程序
找一个单核单线程的机器^0^（现在这样的机器太难找了，只能使用云服务器实现）

我们以第一种方法为例：

//github.com/bigwhite/experiments/go-sched-examples/case2.go
package main

import (
    "fmt"
    "runtime"
    "time"
)

func deadloop() {
    for {
    }
}

func main() {
    runtime.GOMAXPROCS(1)
    go deadloop()
    for {
        time.Sleep(time.Second * 1)
        fmt.Println("I got scheduled!")
    }
}

运行这个程序后，你会发现main goroutine的”I got scheduled”字样再也无法输出了。这里的调度原理可以用下面图示说明：

img{512x368}

deadloop goroutine在P1上被调度，由于deadloop内部逻辑没有给调度器任何抢占的机会，比如：进入runtime.morestack_noctxt。于是即便是sysmon这样的监控goroutine，也仅仅是能给deadloop goroutine的抢占标志位设为true而已。由于deadloop内部没有任何进入调度器代码的机会，Goroutine重新调度始终无法发生。main goroutine只能躺在P1的local queue中徘徊着。

三、反转：如何在GOMAXPROCS=1的情况下，让main goroutine得到调度呢？

我们做个反转：如何在GOMAXPROCS=1的情况下，让main goroutine得到调度呢？听说在Go中 “有函数调用，就有了进入调度器代码的机会”，我们来试验一下是否属实。我们在deadloop goroutine的for-loop逻辑中加上一个函数调用：

// github.com/bigwhite/experiments/go-sched-examples/case3.go
package main

import (
    "fmt"
    "runtime"
    "time"
)

func add(a, b int) int {
    return a + b
}

func deadloop() {
    for {
        add(3, 5)
    }
}

func main() {
    runtime.GOMAXPROCS(1)
    go deadloop()
    for {
        time.Sleep(time.Second * 1)
        fmt.Println("I got scheduled!")
    }
}

我们在deadloop goroutine的for loop中加入了一个add函数调用。我们来运行一下这个程序，看是否能达成我们的目的：

$ go run case3.go

“I got scheduled!”字样依旧没有出现在我们眼前！也就是说main goroutine没有得到调度！为什么呢？其实所谓的“有函数调用，就有了进入调度器代码的机会”，实际上是go compiler在函数的入口处插入了一个runtime的函数调用：runtime.morestack_noctxt。这个函数会检查是否扩容连续栈，并进入抢占调度的逻辑中。一旦所在goroutine被置为可被抢占的，那么抢占调度代码就会剥夺该Goroutine的执行权，将其让给其他goroutine。但是上面代码为什么没有实现这一点呢？我们需要在汇编层次看看go compiler生成的代码是什么样子的。

查看Go程序的汇编代码有许多种方法：

使用objdump工具：objdump -S go-binary
使用gdb disassemble
构建go程序同时生成汇编代码文件：go build -gcflags ‘-S’ xx.go > xx.s 2>&1
将Go代码编译成汇编代码：go tool compile -S xx.go > xx.s
使用go tool工具反编译Go程序：go tool objdump -S go-binary > xx.s

我们这里使用最后一种方法：利用go tool objdump反编译(并结合其他输出的汇编形式)：

$go build -o case3 case3.go
$go tool objdump -S case3 > case3.s

打开case3.s，搜索main.add，我们居然找不到这个函数的汇编代码，而main.deadloop的定义如下：

TEXT main.deadloop(SB) github.com/bigwhite/experiments/go-sched-examples/case3.go
        for {
  0x1093a10             ebfe                    JMP main.deadloop(SB)

  0x1093a12             cc                      INT $0x3
  0x1093a13             cc                      INT $0x3
  0x1093a14             cc                      INT $0x3
  0x1093a15             cc                      INT $0x3
   ... ...
  0x1093a1f             cc                      INT $0x3

我们看到deadloop中对add的调用也消失了。这显然是go compiler执行生成代码优化的结果，因为add的调用对deadloop的行为结果没有任何影响。我们关闭优化再来试试：

$go build -gcflags '-N -l' -o case3-unoptimized case3.go
$go tool objdump -S case3-unoptimized > case3-unoptimized.s

打开 case3-unoptimized.s查找main.add，这回我们找到了它：

TEXT main.add(SB) github.com/bigwhite/experiments/go-sched-examples/case3.go
func add(a, b int) int {
  0x1093a10             48c744241800000000      MOVQ $0x0, 0x18(SP)
        return a + b
  0x1093a19             488b442408              MOVQ 0x8(SP), AX
  0x1093a1e             4803442410              ADDQ 0x10(SP), AX
  0x1093a23             4889442418              MOVQ AX, 0x18(SP)
  0x1093a28             c3                      RET

  0x1093a29             cc                      INT $0x3
... ...
  0x1093a2f             cc                      INT $0x3

deadloop中也有了对add的显式调用：

TEXT main.deadloop(SB) github.com/bigwhite/experiments/go-sched-examples/case3.go
  ... ...
  0x1093a51             48c7042403000000        MOVQ $0x3, 0(SP)
  0x1093a59             48c744240805000000      MOVQ $0x5, 0x8(SP)
  0x1093a62             e8a9ffffff              CALL main.add(SB)
        for {
  0x1093a67             eb00                    JMP 0x1093a69
  0x1093a69             ebe4                    JMP 0x1093a4f
... ...

不过我们这个程序中的main goroutine依旧得不到调度，因为在main.add代码中，我们没有发现morestack函数的踪迹，也就是说即便调用了add函数，deadloop也没有机会进入到runtime的调度逻辑中去。

不过，为什么Go compiler没有在main.add函数中插入morestack的调用呢？那是因为add函数位于调用树的leaf(叶子）位置，compiler可以确保其不再有新栈帧生成，不会导致栈分裂或超出现有栈边界，于是就不再插入morestack。而位于morestack中的调度器的抢占式检查也就无法得以执行。下面是go build -gcflags ‘-S’方式输出的case3.go的汇编输出：

"".add STEXT nosplit size=19 args=0x18 locals=0x0
     TEXT    "".add(SB), NOSPLIT, $0-24
     FUNCDATA        $0, gclocals·54241e171da8af6ae173d69da0236748(SB)
     FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
     MOVQ    "".b+16(SP), AX
     MOVQ    "".a+8(SP), CX
     ADDQ    CX, AX
     MOVQ    AX, "".~r2+24(SP)
    RET

我们看到nosplit字样，这就说明add使用的栈是固定大小，不会再split，且size为24字节。

关于在for loop中的leaf function是否应该插入morestack目前还有一定争议，将来也许会对这样的情况做特殊处理。

既然明白了原理，我们就在deadloop和add之间加入一个dummy函数，见下面case4.go代码：

//github.com/bigwhite/experiments/go-sched-examples/case4.go
package main

import (
    "fmt"
    "runtime"
    "time"
)

//go:noinline
func add(a, b int) int {
    return a + b
}

func dummy() {
    add(3, 5)
}

func deadloop() {
    for {
        dummy()
    }
}

func main() {
    runtime.GOMAXPROCS(1)
    go deadloop()
    for {
        time.Sleep(time.Second * 1)
        fmt.Println("I got scheduled!")
    }
}

执行该代码：

$go run case4.go
I got scheduled!
I got scheduled!
I got scheduled!

Wow! main goroutine果然得到了调度。我们再来看看go compiler为程序生成的汇编代码：

$go build -gcflags '-N -l' -o case4 case4.go
$go tool objdump -S case4 > case4.s

TEXT main.add(SB) github.com/bigwhite/experiments/go-sched-examples/case4.go
func add(a, b int) int {
  0x1093a10             48c744241800000000      MOVQ $0x0, 0x18(SP)
        return a + b
  0x1093a19             488b442408              MOVQ 0x8(SP), AX
  0x1093a1e             4803442410              ADDQ 0x10(SP), AX
  0x1093a23             4889442418              MOVQ AX, 0x18(SP)
  0x1093a28             c3                      RET

  0x1093a29             cc                      INT $0x3
  0x1093a2a             cc                      INT $0x3
... ...

TEXT main.dummy(SB) github.com/bigwhite/experiments/go-sched-examples/case4.s
func dummy() {
  0x1093a30             65488b0c25a0080000      MOVQ GS:0x8a0, CX
  0x1093a39             483b6110                CMPQ 0x10(CX), SP
  0x1093a3d             762e                    JBE 0x1093a6d
  0x1093a3f             4883ec20                SUBQ $0x20, SP
  0x1093a43             48896c2418              MOVQ BP, 0x18(SP)
  0x1093a48             488d6c2418              LEAQ 0x18(SP), BP
        add(3, 5)
  0x1093a4d             48c7042403000000        MOVQ $0x3, 0(SP)
  0x1093a55             48c744240805000000      MOVQ $0x5, 0x8(SP)
  0x1093a5e             e8adffffff              CALL main.add(SB)
}
  0x1093a63             488b6c2418              MOVQ 0x18(SP), BP
  0x1093a68             4883c420                ADDQ $0x20, SP
  0x1093a6c             c3                      RET

  0x1093a6d             e86eacfbff              CALL runtime.morestack_noctxt(SB)
  0x1093a72             ebbc                    JMP main.dummy(SB)

  0x1093a74             cc                      INT $0x3
  0x1093a75             cc                      INT $0x3
  0x1093a76             cc                      INT $0x3
.... ....

我们看到main.add函数依旧是leaf，没有morestack插入；但在新增的dummy函数中我们看到了CALL runtime.morestack_noctxt(SB)的身影。

四、为何runtime.morestack_noctxt(SB)放到了RET后面？

在传统印象中，morestack是放在函数入口处的。但实际编译出来的汇编代码中(见上面函数dummy的汇编)，runtime.morestack_noctxt(SB)却放在了RET的后面。解释这个问题，我们最好来看一下另外一种形式的汇编输出(go build -gcflags ‘-S’方式输出的格式)：

"".dummy STEXT size=68 args=0x0 locals=0x20
        0x0000 00000 TEXT    "".dummy(SB), $32-0
        0x0000 00000 MOVQ    (TLS), CX
        0x0009 00009 CMPQ    SP, 16(CX)
        0x000d 00013 JLS     61
        0x000f 00015 SUBQ    $32, SP
        0x0013 00019 MOVQ    BP, 24(SP)
        0x0018 00024 LEAQ    24(SP), BP
        ... ...
        0x001d 00029 MOVQ    $3, (SP)
        0x0025 00037 MOVQ    $5, 8(SP)
        0x002e 00046 PCDATA  $0, $0
        0x002e 00046 CALL    "".add(SB)
        0x0033 00051 MOVQ    24(SP), BP
        0x0038 00056 ADDQ    $32, SP
        0x003c 00060 RET
        0x003d 00061 NOP
        0x003d 00061 PCDATA  $0, $-1
        0x003d 00061 CALL    runtime.morestack_noctxt(SB)
        0x0042 00066 JMP     0

我们看到在函数入口处，compiler插入三行汇编：

        0x0000 00000 MOVQ    (TLS), CX  // 将TLS的值(GS:0x8a0)放入CX寄存器
        0x0009 00009 CMPQ    SP, 16(CX)  //比较SP与CX+16的值
        0x000d 00013 JLS     61 // 如果SP > CX + 16，则jump到61这个位置

这种形式输出的是标准Plan9的汇编语法，资料很少（比如JLS跳转指令的含义），注释也是大致猜测的。如果跳转，则进入到 runtime.morestack_noctxt，从 runtime.morestack_noctxt返回后，再次jmp到开头执行。

为什么要这么做呢？按照go team的说法，是为了更好的利用现代CPU的“static branch prediction”，提升执行性能。