python源码深度剖析_Python源码剖析——深度探索动态语言核心技术 | 学步园

8.3  Python虚拟机的运行框架

当Python启动后，首先会进行Python运行时环境的

初始化。注意这里的运行时环境是一个与上一节剖析的执行环境不同的概念。运行时环境是一个全局的概念，而执行环境实际就是一个栈帧，是一个与某个Code

Block对应的概念。这里不明白两者的区别不要紧，在以后剖析运行时环境初始化时我们就能弄清楚两者的区别和联系。运行时环境的初始化过程非常地复杂，

后面将用单独的一章来剖析，这里假设初始化的动作已经完成，我们已经站在了Python虚拟机的门槛外，只需要轻轻推动一下第一张骨牌，整个执行过程就像

多米诺骨牌一样，一环扣一环地展开。

这个推动第一张骨牌的地方在一个名叫PyEval_EvalFramEx的函数中，这个函数实际上就是Python的虚拟机的具体实现，它是一个非常巨大的函数，因此我们在列出其中的源代码时和以前有些不同。

PyEval_EvalFrameEx首先会初始化一些变量，其中PyFrameObject对象中的PyCodeObject对象包含的重要信息都被照顾到了。当然，另一个重要的动作就是初始化了堆栈的栈顶指针，使其指向f->f_stacktop：

[PyEval_EvalFrameEx in ceval.c]

co = f->f_code;

names = co->co_names;

consts = co->co_consts;

fastlocals = f->f_localsplus;

freevars = f->f_localsplus

+ co->co_nlocals;

first_instr = (unsigned char*)PyString_AS_STRING(co->co_code);

next_instr = first_instr +

f->f_lasti + 1;

stack_pointer =

f->f_stacktop;

f->f_stacktop =

NULL;   /* remains NULL unless yield suspends frame */

前面我们说过，在PyCodeObject对象的

co_code域中保存着字节码指令和字节码指令的参数，Python虚拟机执行字节码指令序列的过程就是从头到尾遍历整个co_code、依次执行字节

码指令的过程。在Python的虚拟机中，利用3个变量来完成整个遍历过程。co_code实际上是一个PyStringObject对象，而其中的字符

数组才是真正有意义的东西，这也就是说，整个字节码指令序列实际上就是一个在C中普普通通的字符数组。因此，遍历过程中所使用的这3个变量都是char*

类型的变量：first_instr永远指向字节码指令序列的开始位置；next_instr永远指向下一条待执行的字节码指令的位置；f_lasti指

向上一条已经执行过的字节码指令的位置。图8-5展示了这3个变量在遍历中某时刻的情形：

图8-5  遍历字节码指令序列

那么这个一步一步的动作是如何完成的呢，我们来看一看

Python虚拟机执行字节码指令的整体架构，其实就是一个for循环加上一个巨大的switch/case结构，熟悉Windows

SDK编程的朋友可以想象一下Windows下那个巨大的消息循环，就是那样的结构：

[ceval.c]

/* Interpreter main loop */

PyObject* PyEval_EvalFrameEx(PyFrameObject *f,

int throwflag)

{

……

why = WHY_NOT;

……

for (;;) {

……

fast_next_opcode:

f->f_lasti = INSTR_OFFSET();

//获得字节码指令

opcode

= NEXTOP();

oparg

= 0;

//如果指令需要参数，获得指令参数

if

(HAS_ARG(opcode))

oparg = NEXTARG();

dispatch_opcode:

switch

(opcode) {

case

NOP:

goto fast_next_opcode;

case

LOAD_FAST:

……

}

}

注意，这只是一个极度简化之后的Python虚拟机的样子，如果想一睹Python虚拟机的尊容，请参考ceval.c中的源码。

在这个执行架构中，对字节码的一步一步地遍历是通过几个宏来实现的：

[PyEval_EvalFrameEx

in ceval.c]

#define INSTR_OFFSET()  (int(next_instr -

first_instr))

#define NEXTOP()

(*next_instr++)

#define NEXTARG()   (next_instr += 2,

(next_instr[-1]<<8) + next_instr[-2])

在对PyCodeObject对象的分析中我们说过，

Python的字节码有的是带参数的，有的是没有参数的，而判断是否带参字节码是通过HAS_ARG这个宏实现的。注意，对不同的字节码指令，由于存在是

否需要指令参数的区别，所以next_instr的位移可能是不同的。但是无论如何，next_instr总是指向Python下一条要执行的字节码，这

很像x86平台上的那个PC寄存器。

Python在获得了一条字节码指令和其需要的指令参数后，会对字节码指令利用switch进行判断，根据判断的结果选择不同的case语句，每一条字节码指令都会对应一个case语句。在case语句中，就是Python对字节码指令的实现。

在成功执行完一条字节码指令后，Python的执行流程会跳

转到fast_next_opcode处，或者是for循环处，不管如何，Python接下来的动作都是获得下一条字节码指令和指令参数，完成对下一条指

令的执行。如此一条一条地遍历co_code中包含的所有字节码指令，最终完成了对Python程序的执行。

需要提到的一点是那个名叫“why”的神秘变量，它指示了在

退出这个巨大的for循环时Python执行引擎的状态。因为Python执行引擎不一定每次执行都会正确无误，很有可能在执行到某条字节码的时候，产生

了错误，这就是我们熟悉的那个“异常”——exception。所以在Python退出了执行引擎的时候，就需要知道执行引擎到底是因为什么原因结束了对

字节码指令的执行。是正常结束呢？还是因为有错误发生，实在是执行不下去了？why义无反顾地担负起这一重任。关于why在Python虚拟机中作用的详

细剖析，我们留到剖析异常机制时详细讲述。

变量why的取值范围在ceval.c中被定义，其实也就是Python结束字节码执行时的状态：

[ceval.c]

/* Status code for main loop (reason for stack

unwind) */

enum why_code {

WHY_NOT =   0x0001, /* No error */

WHY_EXCEPTION = 0x0002, /* Exception occurred */

WHY_RERAISE =   0x0004, /* Exception re-raised by 'finally' */

WHY_RETURN =    0x0008, /* 'return' statement */

WHY_BREAK = 0x0010, /* 'break' statement */

WHY_CONTINUE =  0x0020, /* 'continue' statement */

WHY_YIELD = 0x0040  /* 'yield' operator */

};

现在，想必大家已经对Python的执行引擎的大体框架了然

于胸了。在Python的执行流程进入了PyEval_EvalFrameEx中的那个for循环，取出第一条字节码之后，第一张多米诺骨牌已经被推倒，

命运不可阻挡地降临了。一条接一条的字节码像潮水一样汹涌而来，浩浩荡荡，横无际涯。