"Внутренности" CPython, часть II

“Внутренности” CPython, часть вторая
Никита Лесников

Вспомнить все.
“Внутренности” CPython, часть вторая 2

Вспомнить все
Наверняка не все присутствовали на первой части моего
выступления

Это ведь было аж в июне

Это ведь было аж в июне
Поэтому кратко повторю, о чем мы собираемся разговаривать

CPython
Основная реализация на сегодняшний день

CPython
Написана на C

CPython
“Чистый” интерпретатор байткода, без JIT и AOT

CPython
“Чистый” интерпретатор байткода, без JIT и AOT
“Своя” VM, никаких отсылок к Java и .NET

Альтернативы
native+ - PyPy

native+ - PyPy
.NET - IronPython, Boo (правда, строго говоря это не Python)

native+ - PyPy
JVM - Jython

native+ - PyPy
JVM - Jython
Возможно другие. Они нас сегодня не интересуют.

native+ - PyPy
JVM - Jython
Возможно другие. Они нас сегодня не интересуют.
Мы рассматриваем внутреннее устройство CPython.

Все - объект
В CPython все является объектом

Конкретнее - PyObject*

Числа, строки, код, фреймы, модули - абсолютно все

Числа, строки, код, фреймы, модули - абсолютно все
Любой PyObject начинается одинаково:
#define PyObject_HEAD
Py_ssize_t ob_refcnt;
struct _typeobject *ob_type;

PyObject
ob_refcnt - reference count для управления памятью

PyObject
ob_type - type object, задающий поведение конкретного объекта

PyObject
ob_type - type object, задающий поведение конкретного объекта
То, что дальше, может быть чем угодно.

code object
Код в Python - тоже объект.

code object
Интерпретатор оперирует байткодом стековой машины.

code object
Инструкции занимают 1 байт, опционально принимают один
двухбайтный аргумент.

code object
Инструкции занимают 1 байт, опционально принимают один
двухбайтный аргумент.
Константы сложных типов хранятся “рядом” в code object,
обращение к ним происходит по индексу.

code object
def f(x): return (1,2,3)[x] + 1
0 LOAD_CONST 4 ((1, 2, 3))
3 LOAD_FAST 0 (x)
6 BINARY_SUBSCR
7 LOAD_CONST 1 (1)
10 BINARY_ADD
11 RETURN_VALUE
>>> f.__code__.co_consts
(None, 1, 2, 3, (1, 2, 3))

Стеки и фреймы.

Стековая машина
На уровне байткода CPython является стековой машиной.

Значения кладутся на стек, операции берут их с вершины стека,
иногда меняя порядок верхних элементов.

Значения кладутся на стек, операции берут их с вершины стека,
иногда меняя порядок верхних элементов.
Стек значений не имеет отношения к стеку адресов возврата - это
отдельная сущность.

Стековая машина, пример
def f(a,b,c): return a + b*c
0 LOAD_FAST 0 (a)
3 LOAD_FAST 1 (b)
6 LOAD_FAST 2 (c)
9 BINARY_MULTIPLY
10 BINARY_ADD
11 RETURN_VALUE

Нелокальный выход
Стек значений (value stack) существует в рамках одного
исполнения code object

Python поддерживает нелокальный выход (break, continue,
raise)

raise)
Необходимо “открутить” стек значений на момент входа в for,
while или локальный try

raise)
С++ использует для stack unwind при исключениях пометки в
“общем” стеке

raise)
С++ использует для stack unwind при исключениях пометки в
“общем” стеке
CPython использует для этих целей block stack.

Block stack
Block stack хранит в себе пары вида (адрес, глубина стека)

Block stack
Инструкции вроде break “откручивают” value stack до
запомненного значения глубины и делают goto на указанный
адрес в байткоде

Block stack
Инструкции вроде break “откручивают” value stack до
запомненного значения глубины и делают goto на указанный
адрес в байткоде
Давайте посмотрим как это выглядит

Block stack, пример
def f():
while 1:
return 2; continue; break
0 SETUP_LOOP 8 (to 11)
>> 3 LOAD_CONST 1 (2)
6 RETURN_VALUE
7 BREAK_LOOP
8 JUMP_ABSOLUTE 3
>> 11 LOAD_CONST 0 (None)
14 RETURN_VALUE

ceval.c
case SETUP_LOOP:
case SETUP_EXCEPT:
case SETUP_FINALLY:
PyFrame_BlockSetup(f, opcode, INSTR_OFFSET() + oparg,
STACK_LEVEL());
continue;

ceval.c, BREAK
case BREAK_LOOP:
why = WHY_BREAK;
goto fast_block_end;
fast_block_end:
while (why != WHY_NOT && f->f_iblock > 0) {
PyTryBlock *b = PyFrame_BlockPop(f);
if (b->b_type == SETUP_LOOP && why == WHY_BREAK) {
why = WHY_NOT;
JUMPTO(b->b_handler);
break; }

Другие хранилища
Помимо value stack и block stack, нужно еще хранить адреса
возврата, локальные переменные, лексическое замыкание

В прошлой части этой презентации рассказывалось, что
локальные переменные определяются на этапе компиляции и для
них заводится список фиксированного размера с обращением по
индексу за O(1)

Аналогично компилятор (в байткод) поступает и с лексическим
замыканием

Аналогично компилятор (в байткод) поступает и с лексическим
замыканием
Кроме того, code object может вызвать сам себя (рекурсия?) и
тогда обоим экземплярам нужны свои стеки.

frame object
Является хранилищем состояния для конкретного code object

frame object
Без code object не имеет смысла - все его параметры
определяются атрибутами исполняемого кода

frame object
Включает в себя value stack, block stack, locals, cellvars

frame object
Включает в себя value stack, block stack, locals, cellvars
Ссылается на предыдущий фрейм в стеке

frame object
frame object - полный аналог activation frame в С

frame object
Только в C activation frame расположен на общем стеке - адреса
возврата и локальные переменные идут “вперемешку”, и activation
frame волей-неволей уничтожается при выходе из функции
(последующие вызовы других функций его перетрут).

frame object
Только в C activation frame расположен на общем стеке - адреса
возврата и локальные переменные идут “вперемешку”, и activation
frame волей-неволей уничтожается при выходе из функции
(последующие вызовы других функций его перетрут).
В frame object есть ссылка f_back на предыдущий фрейм в стеке,
поэтому в CPython стек вызовов реализован как односвязный
список.

Почему односвязный список?
В отличие от contiguous представления стека в C, это позволяет
продлевать время жизни фрейма сколь угодно долго.

Каждый фрейм выделяется и освобождается как обычный
PyObject, в подходящем месте в памяти, совершенно
необязательно кого-то перетирать.

Каждый фрейм выделяется и освобождается как обычный
PyObject, в подходящем месте в памяти, совершенно
необязательно кого-то перетирать.
Это позволяет реализовать генераторы.

Генераторы
Это просто стек (в виде списка) фреймов, завернутый в объект
(genobject).

(genobject).
yield приостанавливает его выполнение, next() возобновляет c
того места, где в последний раз был вызван yield

(genobject).
yield приостанавливает его выполнение, next() возобновляет c
того места, где в последний раз был вызван yield
Стек фреймов живет столько, сколько живет genobject.

Генераторы и фреймы
code 1
code 2
code gencode 3
code 4
genobject
f_code
f_back
f_code
locals
f_back
f_code
f_back
f_code
f_back
f_code
f_back
f_code
f_back
f_code
f_back
f_code
f_back

Генераторы в CPython не столь общи, как хотелось бы

Во-первых, yield это statement, а не expression

Во-вторых, yield возможен только в самой функции-генераторе,
нo не в вызываемых ею

Во-вторых, yield возможен только в самой функции-генераторе,
нo не в вызываемых ею
Оба ограничения нефундаментальны

Генераторы - альтернативы
PEP 380 - официально принятый для Python 3 пропоузал,
который позволит реализовывать полноценные сопрограммы на
генераторах (как, например, в Lua)

greenlet - нативный модуль расширения для CPython,
реализующий кооперативную многозадачность через “срезание”
сишного стека

greenlet - нативный модуль расширения для CPython,
реализующий кооперативную многозадачность через “срезание”
сишного стека
stackless - форк CPython, развивающий идею “фреймы как
объекты” до полноценной кооперативной многозадачности

Объектная модель

Ранее мы уже упоминали, что все с точки зрения CPython есть
PyObject

PyObject
Также мы знаем, что в байткоде инструкция BINARY_ADD удаляет
два объекта с вершины стека, складывает их, после чего
помещает результат на вершину стека

PyObject
Сложение для чисел - это сложение, для строк - конкатенация, и
вообще мы можем переопределить __add__ у чего угодно

PyObject
Сложение для чисел - это сложение, для строк - конкатенация, и
вообще мы можем переопределить __add__ у чего угодно
Как интерпретатор узнает, что делать?

Type object, слоты, протоколы
В самом начале мы упомянули, что у PyObject обязательно
присутствует поле ob_type - ссылка на type object

Оказывается, в type object есть слоты, возвращающие реализации
требуемых операций (если те поддерживаются объектом, само
собой)

собой)
Интерпретатор просто вызывает нужные функции по указателям,
либо возвращает ошибку несовместимости типов.

собой)
Интерпретатор просто вызывает нужные функции по указателям,
либо возвращает ошибку несовместимости типов.
Рассмотрим на примере int object.

ceval.c
case BINARY_ADD:
w = POP();
v = TOP();
....
else {
slow_add:
x = PyNumber_Add(v, w);
}
...
SET_TOP(x);

abstract.c
PyObject * PyNumber_Add(PyObject *v, PyObject *w)
{
PyObject *result = binary_op1(v, w, NB_SLOT(nb_add));
...
return result;
}

abstract.c
static PyObject
*binary_op1(PyObject *v, PyObject *w, const int op_slot)
{
binaryfunc slotv = NULL;
...
slotv = NB_BINOP(v->ob_type->tp_as_number, op_slot);
...
if (slotv) {
x = slotv(v, w);
if (x != Py_NotImplemented)
return x;

intobject.c
static PyObject *
int_add(PyIntObject *v, PyIntObject *w)
{
register long a, b, x;
CONVERT_TO_LONG(v, a);
CONVERT_TO_LONG(w, b);
....
x = (long)((unsigned long)a + b);
if ((x^a) >= 0 || (x^b) >= 0)
return PyInt_FromLong(x);
....

Слоты и протоколы
Слоты и протоколы - это довольно низкоуровневая особенность,
которая из кода на Python не видна

Как она сочетается с наследованием и возможностью
переопределения через “магические” имена (вроде __add__?)

Как она сочетается с наследованием и возможностью
переопределения через “магические” имена (вроде __add__?)
В этом проявляется красота объектной модели Python.

type object == class
type object и классы - одно и то же.

(За исключением old style classes, которые все являются
объектами типа instance и фактически существуют только ради
совместимости с legacy кодом на Python < 2.5)

(За исключением old style classes, которые все являются
объектами типа instance и фактически существуют только ради
совместимости с legacy кодом на Python < 2.5)
При создании класса создается новый type object, который
наполняется содержимым из классов-родителей.

При наследовании классов все слоты type object копируются в
новый класс (typeobject.c):
static PyObject *
type_new(PyTypeObject *metatype,
PyObject *args, PyObject *kwds)
{
...
/* Put the proper slots in place */
fixup_slot_dispatchers(type);

При попытке переопределить метод в рантайме через выставление
“магического” атрибута класса в дело включается type_setattro,
определенный в слоте tp_setattro у типа класса

Да, у type object тоже есть тип, и это тоже type object :)

Да, у type object тоже есть тип, и это тоже type object :)
type_setattro знает про слоты и правильно их обновляет:
static int
type_setattro(PyTypeObject *type,
PyObject *name, PyObject *value)
{
...
return update_slot(type, name);

Кроме того, технические поля инстанса (вроде __dict__), также
являются с точки зрения типа обычными аттрибутами

Вкупе с дескрипторами, про которые много кто уже здесь
говорил, это дает поистине впечатляющие возможности

В частности, практически ко всему, во что можно впихнуть
заголовок PyObject, можно предоставить идиоматичную
питоновскую обертку, не меняя представления

В частности, практически ко всему, во что можно впихнуть
заголовок PyObject, можно предоставить идиоматичную
питоновскую обертку, не меняя представления
Это обуславливает такое количество библиотек - делать
интерфейсы для C/C++ библиотек довольно легко

slots
Чтобы поменять представление объекта в памяти, необязательно
лезть на уровень Python/C API

slots
Для объектов, которые создаются миллионами и редко меняют
набор полей, есть встроенная возможность избежать создания
__dict__ для каждого инстанса.

slots
Для этого в классе надо объявить атрибут __slots__, и в нем
объявить имена полей.

slots
Для этого в классе надо объявить атрибут __slots__, и в нем
объявить имена полей.
Тогда все инстансы будут хранить только ссылки на значения
атрибутов в определенном порядке, __dict__ будет создан только
при попытке выставить атрибут не из __slots__.

slots
>>> class SlotClass: __slots__ = "x", "y"
>>> X = SlotClass()
>>> X.x = 1; X.y = 2
>>> asizeof(X)
128
>>> class DictClass: pass
>>> Y = DictClass()
>>> Y.x = 1; Y.y = 2
>>> asizeof(Y)
480

Заключение

Напоследок хочу напомнить, что все рассказанное может быть
почерпнуто прямо из исходников CPython - они хорошо
задокументированы и читаются довольно легко

Лезть в исходники интерпретатора чтобы понять, как ведет себя
прикладной код - вполне себе реальный сценарий

Лезть в исходники интерпретатора чтобы понять, как ведет себя
прикладной код - вполне себе реальный сценарий
Если тема доклада вас заинтересовала, то от себя хочу
порекомендовать следующие ресурсы

“Python Innards”, Yaniv Aknin
http://en.wordpress.com/tag/pythons-innards/
Серия постов от Yaniv Aknin про байткод, стеки,
thread state и объектную модель в CPython.

“Python internals”, Eli Bendersky
http://tinyurl.com/pyinternals
Серия постов от Eli Bendersky про компилятор
Python, а также объектную модель Python 3.

“Understanding the Python GIL”, David Beazley
http://www.dabeaz.com/GIL/
Презентации David Beazley, касающиеся
особенностей реализации GIL в Python,
проливающие свет на его неочевидное поведение
(например, существенное замедление CPU-bound
многопоточного кода на многоядерных машинах)

Благодарю за внимание!

"Внутренности" CPython, часть II

More Related Content

What's hot

Viewers also liked

Similar to "Внутренности" CPython, часть II

More from Python Meetup

"Внутренности" CPython, часть II