楔子
从现在开始,我们将剖析虚拟机运行字节码的原理。前面说了,Python 解释器可以分为两部分:Python 编译器和 Python 虚拟机。
编译器将源代码编译成 PyCodeObject 对象之后,就由虚拟机接手整个工作。虚拟机会从 PyCodeObject 中读取字节码,并在当前的上下文中执行,直到所有的字节码都被执行完毕。
那么问题来了,既然源代码在经过编译之后,字节码指令以及静态信息都存储在 PyCodeObject 当中,那么是不是意味着虚拟机就在 PyCodeObject 对象上进行所有的动作呢?
很明显不是的,因为尽管 PyCodeObject 包含了关键的字节码指令以及静态信息,但有一个东西是没有包含、也不可能包含的,就是程序在运行时的执行环境,这个执行环境在 Python 里面就是栈帧。
栈帧:虚拟机的执行环境
那什么是栈帧呢?我们举个例子。
name = "古明地觉" def some_func(): name = "八意永琳" print(name) some_func() print(name)
上面的代码当中出现了两个 print(name),它们的字节码指令相同,但执行的效果却显然是不同的,这样的结果正是执行环境的不同所产生的。因为环境的不同,name 的值也不同。
因此同一个符号在不同环境中可能指向不同的类型、不同的值,必须在运行时进行动态捕捉和维护,这些信息不可能在 PyCodeObject 对象中被静态存储。
因此虚拟机并不是在 PyCodeObject 对象上执行操作的,而是在栈帧对象上。虚拟机在执行时,会根据 PyCodeObject 对象动态创建出栈帧对象,然后在栈帧里面执行字节码。所以栈帧是虚拟机执行的上下文,执行时依赖的所有信息都存储在栈帧中。
因此对于上面的代码,我们可以大致描述一下流程:
- 首先基于模块的 PyCodeObject 创建一个栈帧,假设叫 A,所有的字节码都会在栈帧中执行,虚拟机可以从栈帧里面获取变量的值,也可以修改;
- 当发生函数调用的时候,这里是 some_func,那么虚拟机会在栈帧 A 之上,为 some_func 创建一个新的栈帧,假设叫 B,然后在栈帧 B 里面执行函数 some_func 的字节码指令;
- 在栈帧 B 里面也有一个名字为 name 的变量,但由于执行环境、或者说栈帧的不同,name 指向的对象也不同;
- 一旦函数 some_func 的字节码指令全部执行完毕,那么会将当前的栈帧 B 销毁(也可以保留),再回到调用者的栈帧中来。就像是递归一样,每当调用函数时,就会在当前栈帧之上创建一个新的栈帧,一层一层创建,一层一层返回;
虚拟机和操作系统
不难发现,Python 虚拟机执行字节码这个过程,就是在模拟操作系统运行可执行文件。比如:
程序加载
- 操作系统:加载可执行文件到内存,设置程序计数器。
- Python 虚拟机:加载 .pyc 文件中的 PyCodeObject 对象,初始化字节码指令指针。
内存管理
- 操作系统:为进程分配内存空间,管理堆和栈。
- Python 虚拟机:创建和管理 Python 对象,处理内存分配和垃圾回收。
指令执行
- 操作系统:CPU 逐条执行机器指令。
- Python 虚拟机:虚拟机逐条执行字节码指令。
资源管理
- 操作系统:管理文件句柄、网络连接等系统资源。
- Python 虚拟机:管理文件对象、套接字等 Python 级别的资源。
异常处理
- 操作系统:处理硬件中断和软件异常。
- Python 虚拟机:捕获和处理 Python 异常。
我们简单地画一张示意图,来看看在一台普通的 x64 机器上,可执行文件是以什么方式运行的,在这里主要关注栈帧的变化。假设有三个函数,函数 f 调用了函数 g,函数 g 又调用了函数 h。
首先 CPU 有两个关键的寄存器,它们在函数调用和栈帧管理中扮演关键角色。
RSP(Stack Pointer):栈指针,指向当前栈帧的顶部,或者说最后一个入栈的元素。因此随着元素的入栈和出栈,RSP 会动态变化。由于地址从栈底到栈顶是逐渐减小的,所以 RSP 会随着数据入栈而减小,随着数据出栈而增大。当然不管 RSP 怎么变,它始终指向当前栈的顶部。
RBP(Base Pointer):基指针,指向当前栈帧的基址,它的作用是提供一个固定的参考点,用于访问当前函数的局部变量和参数。当新的帧被创建时,它的基址会保存上一个帧的基址,并由 RBP 指向。
我们用一段 C 代码来解释一下。
#include <stdio.h> int add(int a, int b) { int c = a + b; return c; } int main() { int a = 11; int b = 22; int result = add(a, b); printf("a + b = %d\n", result); }
当执行函数 add 时,那么当前帧显然就是函数 add 的栈帧,而调用者的帧(上一级栈帧)显然就是函数 main 的栈帧。
栈是先入后出的数据结构,地址从栈底到栈顶是减小的。对于一个函数而言,所有对局部变量的操作都在自己的栈帧中完成,而调用函数的时候则会为其创建新的栈帧。
当执行函数 main 的时候,RSP 指向 main 栈帧的顶部,RBP 指向 main 栈帧的基址。然后在 main 里面又调用了函数 add,那么毫无疑问,系统会在地址空间中,在 main 的栈帧之上为 add 创建栈帧。然后让 RSP 指向 add 栈帧的顶部,RBP 指向 add 栈帧的基址,而 add 栈帧的基址保存了上一级栈帧(main 栈帧)的基址。
当函数 add 执行结束时,会销毁对应栈帧,再将 RSP 和 RBP 恢复为创建 add 栈帧之前的值,这样程序的执行流程就又回到了函数 main 里面,当然程序的运行空间也回到了函数 main 的栈帧中。
不难发现,通过两个 CPU 寄存器 RSP、RBP,以及栈帧中保存的上一级栈帧的基址,完美地维护了函数之间的调用链,这就是可执行文件在 x64 机器上的运行原理。
那么 Python 里面的栈帧是怎样的呢?
栈帧的底层结构
相较于 x64 机器上看到的那个简简单单的栈帧,Python 的栈帧实际上包含了更多的信息。注:栈帧也是一个对象。
// Include/pytypedefs.h typedef struct _frame PyFrameObject; // Include/internal/pycore_frame.h struct _frame { PyObject_HEAD PyFrameObject *f_back; struct _PyInterpreterFrame *f_frame; PyObject *f_trace; int f_lineno; char f_trace_lines; char f_trace_opcodes; char f_fast_as_locals; }; typedef struct _PyInterpreterFrame { PyCodeObject *f_code; struct _PyInterpreterFrame *previous; PyObject *f_funcobj; PyObject *f_globals; PyObject *f_builtins; PyObject *f_locals; PyFrameObject *frame_obj; _Py_CODEUNIT *prev_instr; int stacktop; uint16_t return_offset; char owner; PyObject *localsplus[1]; } _PyInterpreterFrame;
栈帧在底层由 PyFrameObject 表示,在 3.11 之前,所有字段都保存在该结构体中。但里面有一部分字段,在大部分情况下都用不到,比如一些用于 Debug 的字段。而这些不常用的字段,显然会导致内存浪费,因为创建栈帧时要为所有字段都申请内存空间。
于是从 3.11 开始,虚拟机将 PyFrameObject 里面的核心字段提取出来,形成了更加轻量级的 _PyInterpreterFrame,从而减少内存使用并提高性能。
- _PyInterpreterFrame:栈帧的核心结构,这是一个轻量级的 C 结构,只包含执行所需的基本信息,虚拟机会在内部使用它。
- PyFrameObject:完整的栈帧对象,在需要更全面的帧信息时使用。比如从 Python 级别获取栈帧时,拿到的对象在底层对应的就是 PyFrameObject 结构体。
通过这种拆分,虚拟机在大多数情况下只需使用轻量级的 _PyInterpreterFrame 即可,只有在需要完整的帧信息时,才会创建 PyFrameObject。
但要强调的是,由于 _PyInterpreterFrame 里面没有 PyObject,所以它不是 Python 对象,它只是包含了栈帧的核心结构,真正的栈帧对象仍是 PyFrameObject。只不过对于虚拟机而言,很多时候只需实例化 _PyInterpreterFrame 结构体,即可完成任务。
另外 _PyInterpreterFrame 除了更轻量、结构更紧凑、创建速度快之外,它对 CPU 缓存也非常友好。
我们知道 Python 对象都是申请在堆上的,栈帧也不例外,当调用嵌套函数时,这些栈帧对象会零散在堆区的不同位置,对缓存不友好。但 _PyInterpreterFrame 则不是这样,虚拟机为它专门引入了一个 Stack,这是一段预分配的内存区域,专门用于存储 _PyInterpreterFrame 实例。
当需要创建 _PyInterpreterFrame 实例时,只需要改动一下栈指针,内存便创建好了。当需要销毁时,直接将它从栈的顶端弹出即可,不需要显式地释放内存。并且由于 _PyInterpreterFrame 都是紧密排列在一起,所以对缓存也更加友好。
字段含义解析与代码演示
下面来看一下这两个结构体里面的字段都表示啥含义,不过在解释字段含义之前,我们需要先知道如何在 Python 中获取栈帧对象。
import inspect def foo(): # 返回当前所在的栈帧 # 这个函数实际上是调用了 sys._getframe(1) return inspect.currentframe() frame = foo() print(frame) """ <frame at 0x100de0fc0, file '.../main.py', line 6, code foo> """ print(type(frame)) """ <class 'frame'> """
我们看到栈帧的类型是 <class 'frame'>,正如 PyCodeObject 对象的类型是 <class 'code'> 一样,这两个类没有暴露给我们,所以不可以直接使用。
同理,还有 Python 的函数,类型是 <class 'function'>,模块的类型是 <class 'module'>。这些解释器都没有给我们提供,如果直接使用的话,那么 frame、code、function、module 只是几个没有定义的变量罢了,这些类我们只能通过这种间接的方式获取。
下面我们来看一下 PyFrameObject 里面每个字段的含义。
PyObject_HEAD
对象的头部信息,所以栈帧也是一个对象。
PyFrameObject *f_back
当前栈帧的上一级栈帧,也就是调用者的栈帧。所以 x64 机器是通过 RSP、RBP 两个指针维护函数的调用关系,而 Python 虚拟机则是通过栈帧的 f_back 字段。
import inspect def foo(): return inspect.currentframe() frame = foo() print(frame) """ <frame at 0x100de0fc0, file '.../main.py', line 6, code foo> """ # foo 的上一级栈帧,显然对应的是模块的栈帧 print(frame.f_back) """ <frame at 0x100adde40, file '.../main.py', line 12, code <module>> """ # 相当于模块的上一级栈帧,显然是 None print(frame.f_back.f_back) """ None """
所以通过栈帧,你可以轻松地获取完整的函数调用链路,我们一会儿演示。
struct _PyInterpreterFrame *f_frame
指向 struct _PyInterpreterFrame 实例,它包含了栈帧的核心结构。
PyObject *f_trace
追踪函数,用于调试。
int f_lineno
获取该栈帧时的源代码行号。
import inspect def foo(): return inspect.currentframe() frame = foo() print(frame.f_lineno) # 4
我们是在第 4 行获取的栈帧,所以打印结果是 4。
char f_trace_lines
是否为每一行代码调用追踪函数,当设置为真(非零值)时,每当虚拟机执行到一个新的代码行时,都会调用追踪函数。这允许调试器在每行代码执行时进行干预,比如设置断点、检查变量等。
char f_trace_opcodes
是否为每个字节码指令调用追踪函数,当设置为真时,虚拟机会在执行每个字节码指令之前调用追踪函数。这提供了更细粒度的控制,允许进行指令级别的调试。
所以不难发现,f_trace_lines 是行级追踪,对应源代码的每一行,通常用于普通的调试,如设置断点、单步执行等,并且开销相对较小。f_trace_opcodes 是指令级追踪,对应每个字节码指令,通常用于更深层次的调试,比如分析具体的字节码执行过程,并且开销较大。
import sys def trace_lines(frame, event, arg): print(f"行号:{frame.f_lineno},文件名:{frame.f_code.co_filename}") return trace_lines sys.settrace(trace_lines)
设置追踪函数一般需要通过 sys.settrace,不过不常用,了解一下即可。
char f_fast_as_locals
要解释这个字段,需要用到后续的知识,所以这里先简单了解一下即可。Python 函数的局部变量是采用数组存储的,以便快速访问,这就是所谓的 fast locals。
但有时候我们就是需要一个字典,里面包含所有的局部变量,这时候可以调用 locals 函数,将局部变量的名称和值以 key、value 的形式拷贝到字典中。而 f_fast_as_locals 字段则负责标记这个拷贝过程是否发生过。
然后再来看看 _PyInterpreterFrame 结构体里面的字段,我们说栈帧的核心字段都在该结构体中。
PyCodeObject *f_code
栈帧对象是在 PyCodeObject 之上构建的,所以它内部一定有一个字段指向 PyCodeObject。
import inspect def e(): f() def f(): g() def g(): h() def h(): frame = inspect.currentframe() # 获取栈帧 func_names = [] # 只要 frame 不为空,就一直循环,并将函数名添加到列表中 while frame is not None: func_names.append(frame.f_code.co_name) frame = frame.f_back print(f"函数调用链路:{' -> '.join(func_names[:: -1])}") f() """ 函数调用链路:<module> -> f -> g -> h """
模块 -> f -> g -> h,显然我们获取了整个调用链路,是不是很有趣呢?
struct _PyInterpreterFrame *previous
指向上一个 struct _PyInterpreterFrame,该字段底层没有暴露出来。
PyObject *f_funcobj
指向对应的函数对象,该字段解释器没有暴露出来。
PyObject *f_globals
指向全局名字空间(一个字典),它是全局变量的容身之所。是的,Python 的全局变量是通过字典存储的,调用函数 globals 即可拿到该字典。
# 等价于 name = "古明地觉" globals()["name"] = "古明地觉" # 等价于 print(name) print(globals()["name"]) # 古明地觉 def foo(): import inspect return inspect.currentframe() frame = foo() # frame.f_globals 同样会返回全局名字空间 print(frame.f_globals is globals()) # True # 相当于创建了一个全局变量 age frame.f_globals["age"] = 18 print(age) # 18
关于名字空间,我们后面会用专门的篇幅详细说明。
PyObject *f_locals
指向局部名字空间(一个字典),但和全局变量不同,局部变量不存在局部名字空间中,而是静态存储在数组中。该字段先有个印象,后续再详细说。
PyObject *f_builtins
指向内建名字空间(一个字典),显然一些内置的变量都存在里面。
def foo(): import inspect return inspect.currentframe() frame = foo() print(frame.f_builtins["list"]("abcd")) """ ['a', 'b', 'c', 'd'] """
和我们直接使用 list("abcd") 是等价的。
PyFrameObject *frame_obj
这个不用多说,负责指向 PyFrameObject 对象。
_Py_CODEUNIT *prev_instr
指向上一条已执行完毕的字节码指令,比如虚拟机要执行第 n 条指令,那么 prev_instr 便指向第 n - 1 条指令。由于每个指令都带有一个参数,所以 _Py_CODEUNIT 类型的大小是 2 字节。
int stacktop
表示运行时栈(后续详细说明)的栈顶相对于 localsplus 数组的偏移量。
uint16_t return_offset
表示 RETURN 指令相对 prev_instr 的偏移量,这个值只对被调用的函数有意义,它指示了函数返回后,调用者应该从哪里继续执行。它会在 CALL
指令(调用函数时)和 SEND
指令(发送数据到协程或生成器时)中设置。
这个设计允许更高效的函数返回处理,因为虚拟机可以直接跳转到正确的位置,而不需要额外的查找或计算。
def main(): x = some_func() # CALL 指令在这里 y = x + 1 # 函数返回后应该执行的下一条指令 def some_func(): return 42
当调用 some_func 时,虚拟机会执行 CALL 指令,在 CALL 指令中,会设置 return_offset。当执行完 some_func 的 RETURN 指令时,它会使用 return_offset 来决定跳转到调用者(main)中的哪个位置。
这种机制的优点是不需要在运行时计算返回位置,因为它已经在调用时预先计算好了,特别适用于处理生成器和协程等复杂控制流。
char owner
表示帧的所有权信息,用于区分帧是在虚拟机栈上的,还是单独分配的。
PyObject *localsplus[1]
一个柔性数组,负责维护 "局部变量 + cell 变量 + free 变量 + 运行时栈",大小在运行时确定。
以上就是栈帧内部的字段,这些字段先有个印象,后续在剖析虚拟机的时候还会继续细说。
总之我们看到,PyCodeObject 并不是虚拟机的最终目标,虚拟机最终是在栈帧中执行的。每一个栈帧都会维护一个 PyCodeObject 对象,换句话说,每一个 PyCodeObject 对象都会隶属于一个栈帧。并且从 f_back 可以看出,虚拟机在实际执行时,会产生很多的栈帧对象,而这些对象会被链接起来,形成一条执行环境链表,或者说栈帧链表。
而这正是 x64 机器上栈帧之间关系的模拟,在 x64 机器上,栈帧之间通过 RSP 和 RBP 指针建立了联系,使得新栈帧在结束之后能够顺利地返回到旧栈帧中,而 Python 虚拟机则是利用 f_back 来完成这个动作。
当然,获取栈帧除了通过 inspect 模块之外,在捕获异常时,也可以获取栈帧。
def foo(): try: 1 / 0 except ZeroDivisionError: import sys # exc_info 返回一个三元组 # 分别是异常的类型、值、以及 traceback exc_type, exc_value, exc_tb = sys.exc_info() print(exc_type) # <class 'ZeroDivisionError'> print(exc_value) # division by zero print(exc_tb) # <traceback object at 0x00000135CEFDF6C0> # 调用 exc_tb.tb_frame 即可拿到异常对应的栈帧 # 另外这个 exc_tb 也可以通过下面这种方式获取 # except ZeroDivisionError as e; e.__traceback__ print(exc_tb.tb_frame.f_code.co_name) # foo print(exc_tb.tb_frame.f_back.f_code.co_name) # <module> # 显然 tb_frame 是当前函数 foo 的栈帧 # 那么 tb_frame.f_back 就是整个模块对应的栈帧 # 而 tb_frame.f_back.f_back 显然就是 None 了 print(exc_tb.tb_frame.f_back.f_back) # None foo()
关于栈帧内部的字段的含义,我们就说完了。当然如果有些字段现在不是很理解,也没关系,随着不断地学习,你会豁然开朗。
小结
因为很多动态信息无法静态地存储在 PyCodeObject 对象中,所以 PyCodeObject 对象在交给虚拟机之后,虚拟机会在其之上动态地构建出 PyFrameObject 对象,也就是栈帧。
因此虚拟机是在栈帧里面执行的字节码,它包含了虚拟机在执行字节码时依赖的全部信息。