深度解密 Python 虚拟机的执行环境:栈帧对象

简介: 深度解密 Python 虚拟机的执行环境:栈帧对象


楔子


从现在开始,我们将剖析虚拟机运行字节码的原理。前面说了,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。

0e57f3c5bc400ced93b33bc13bdbb928.png

首先 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 对象,也就是栈帧。


因此虚拟机是在栈帧里面执行的字节码,它包含了虚拟机在执行字节码时依赖的全部信息。

相关文章
|
24天前
|
索引 Python
Python 对象的行为是怎么区分的?
Python 对象的行为是怎么区分的?
16 3
|
24天前
|
存储 缓存 算法
详解 PyTypeObject,Python 类型对象的载体
详解 PyTypeObject,Python 类型对象的载体
22 3
|
23天前
|
Python
深入解析 Python 中的对象创建与初始化:__new__ 与 __init__ 方法
深入解析 Python 中的对象创建与初始化:__new__ 与 __init__ 方法
15 1
|
24天前
|
缓存 Java 程序员
一个 Python 对象会在何时被销毁?
一个 Python 对象会在何时被销毁?
27 2
|
24天前
|
API Python 容器
再探泛型 API,感受 Python 对象的设计哲学
再探泛型 API,感受 Python 对象的设计哲学
18 2
|
24天前
|
API Python
当调用一个 Python 对象时,背后都经历了哪些过程?
当调用一个 Python 对象时,背后都经历了哪些过程?
18 2
|
24天前
|
存储 API C语言
当创建一个 Python 对象时,背后都经历了哪些过程?
当创建一个 Python 对象时,背后都经历了哪些过程?
15 2
|
24天前
|
存储 C语言 Python
解密 Python 的变量和对象,它们之间有什么区别和联系呢?
解密 Python 的变量和对象,它们之间有什么区别和联系呢?
16 2
|
24天前
|
机器人 关系型数据库 Python
【Python篇】Python 类和对象:详细讲解(下篇)
【Python篇】Pyt hon 类和对象:详细讲解(下篇)
21 2
|
24天前
|
算法 Python
【Python篇】Python 类和对象:详细讲解(中篇)
【Python篇】Python 类和对象:详细讲解(中篇)
20 2