Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Здесь мы подробно поговорим о том, каковы технические отличия между реализацией асинхронных стектрейсов по сравнению с реализацией традиционных стектрейсов, а также с какими сложностями можно столкнуться, реализуя такие асинхронные стектрейсы поверх корутин C++.
Обычные синхронные стектрейсы
При работе с обычными стеками, когда вы вызываете функцию, компилятор генерирует специальный код, и этот код автоматически поддерживает связный список кадров стека, а сам этот список является представлением стека вызовов. В начале каждого кадра находится структура, которая (как минимум, в архитектурах Intel) выглядит примерно так:
struct stack_frame {
stack_frame* nextFrame;
void* returnAddress;
};Обычно такая структура заполняется специализированными ассемблерными инструкциями. Например, в x86_64 вызывающая сторона выполняет инструкцию call, которая забрасывает возвращаемый адрес в стек, а затем перепрыгивает к входной точке функции. Затем первая инструкция вызываемой стороны забрасывает в стек регистр ebp (который обычно содержит указатель на актуальную структуру stack_frame), а после этого копирует регистр esp (тот, что содержит указатель на структуру stack_frame, которую мы только что заполнили) в регистр ebp.
Например:
caller:
...
call callee # Забрасывает в стек адрес следующей инструкции,
# заполняя член 'returnAddress' структуры 'stack_frame'.
# Затем перепрыгивает к адресу 'callee'.
mov rsp[-16], rax # Где-нибудь сохраняем результат
...
callee:
push rbp # Забрасывает rbp (указатель на stack_frame) в стек (заполняет член 'nextFrame')
mov rbp, rsp # Обновляет rbp, чтобы он указывал на новый stack_frame
sub rsp, 16 # Резервирует дополнительные 16 байт в пространстве стека
...
mov rax, 42 # Устанавливает возвращаемое значение в 42
leave # Копирует rbp -> rsp, выталкивает rbp из стека
ret # Выталкивает возвращаемый адрес с вершины стека и перепрыгивает к нему Когда отладчик или профилировщик захватывает стектрейс для заданного потока, он получает указатель на первый кадр стека из регистра ebp, относящегося к этому потоку, а затем начинает обход этого связного списка, пока не достигнет корня стека. Все возвращаемые адреса, встречаемые по пути, он при этом записывает в буфер.
Другие инструменты профилирования, которые затем вступают в дело, могут транслировать адреса в имена функций и/или номера файл+строка при помощи символизатора, использующего отладочную информацию о бинарном файле. Эта информация может логироваться или выводиться на экран, в зависимости от того, как будет полезнее при работе с конкретным инструментом.
Как правило, эти кадры стека находятся в единой непрерывной области памяти, а структура данных выглядит примерно так:
Если бы мы хотели обойти асинхронный, а не нормальный стектрейс, то все равно начали бы путь с обычных кадров стека, как и в нормальном стектрейсе. Корутина может вызывать нормальные функции, и нам требуется включить кадры с этими нормальными функциями в стектрейс. Правда, как только мы дойдем до кадра, соответствующего самой верхней корутине (в данном случае coro_function_1) мы не собираемся переходить по ссылке 'nextFrame' к методу coroutine_handle::resume, как это бы произошло при обходе нормального стека. Вместо этого нам нужна ссылка на ожидающую корутину. В этот момент истории нормального и асинхронного стектрейсов расходятся. Проход по асинхронному стектрейсу требует ответить на несколько вопросов:
Как определить, какие из кадров стека соответствуют асинхронным кадрам?
Как найти адрес следующего асинхронного кадра?
Как и где нам выделять пространство для хранения данных, относящихся к асинхронным кадрам?
Прежде, чем реализовать что-либо из этого, мы должны подробнее разобраться в том, как структурируются корутины.
В чем «стеки» корутин отличаются от нормальных стеков?
Когда вы вызываете корутину на C++, программа выделяет хранилище для кадра корутины. Как правило, пространство для этой цели мы получаем из кучи, но в некоторых случаях компилятор вправе и ничего не брать из кучи, обойдясь оптимизациями – например, встраивая операцию выделения в кадр вызывающей стороны.
Компилятор использует хранилище кадров корутин для хранения всего того состояния, которое должно остаться в неприкосновенности на тот период, пока работа корутины приостановлена – и быть доступна к моменту, когда работа корутины возобновится. Обычно в данном случае предусматривается хранилище для параметров функций, локальных переменных, временных файлов и всего прочего состояния, которое компилятор сочтет необходимым сохранить – например, в какой момент времени была приостановлена работа корутины.
Также кадр корутины включает место для хранения специального объекта, промиса корутины, который управляет ее поведением. Компилятор понижает вашу корутину до последовательности вызовов к методам в определенных ключевых точках объекта промиса корутины. Кроме того, в теле корутины содержится некоторый дополнительный код, написанный программистом. Промис корутины управляет поведением корутины, реализуя желаемое поведение в этих методах. Подробнее о том, как как устроен тип промиса, рассказано в статье Understanding the promise type.
Тип промиса определяется в зависимости от сигнатуры функции корутины, и в большинстве случаев тип корутины зависит исключительно от ее возвращаемого типа. Благодаря этому корутины, возвращающие заданный тип (напр., folly::coro::Task<T>) могут хранить на каждый кадр корутины дополнительную информацию: для этого члены данных добавляются к типу промиса.
При clang-подобной реализации компоновка кадра корутины для заданной функции корутины выглядит примерно так:
struct __foo_frame {
using promise_type = typename std::coroutine_traits<Ret, Arg1, Arg2>::promise_type;
void(*resumeFn)(void*); // coroutine_handle::resume() function-pointer
void(*destroyFn)(void*); // coroutine_handle::destroy() function-pointer
promise_type promise; // объект промиса корутины
int suspendPoint; // отслеживает, в какой точке была приостановлена работа корутины
char extra[458]; // дополнительное пространство для хранения локальных переменных, параметров,
// временных файлов, утекших регистров, т.д.
}; При приостановке корутины все состояние, нужное для вызова этой корутины, сохраняется в кадре корутины, и соответствующего кадра стека для этого нет. Однако, когда корутина возобновляется в заданном потоке, в результате в стеке именно этого потока активируется кадр стека для данной корутины (как и в случае с нормальной функцией). Именно этот кадр стека используется для хранения всех временных данных, срок жизни которых не достигает точки, в которой была приостановлена работа.
Если тело корутины выполняется непосредственно в данный момент, то указатель на актуальный кадр корутины обычно содержится в регистре. Это позволяет быстро ссылаться на состояние внутри кадра корутины. Однако, в некоторых случаях этот адрес также может утекать в кадр стека, особенно, когда корутина вызывает другую функцию.
Следовательно, когда корутина активна и вызвала другую функцию, компоновка памяти будет выглядеть примерно так:
В особенности отметим, что обход асинхронной версии стека приводит к тому, что нам приходится отклониться в память кучи, последовав по framePointer в coro_function_1. В отличие от указателя на актуальный кадр стека, который, как обычно предполагается, должен храниться в регистре rbp, не предусмотрено стандартного местоположения для указателя, который направлен на кадр корутины. Это по-своему сказывается на навигации от кадра стека к данным соответствующего асинхронного кадра.
Сцепление асинхронных кадров стека
Чтобы иметь возможность составить стектрейс, который представлял бы цепочку асинхронных вызовов, а не цепочку нормальных синхронных вызовов, мы должны быть в состоянии обойти цепочку кадров корутины, записывая возвращаемый адрес/адрес продолжения каждой корутины по пути.
Первый элемент загадки, разгадываемой в данном случае – это сохранение состояния, которое понадобится нам для обхода асинхронных кадров стека по асинхронному стектрейсу. Для каждого асинхронного кадра стека нам потребуется определить адрес следующего такого кадра, а также возвращаемый адрес актуального кадра стека.
Одно из ограничений, которое здесь нужно учитывать – в том, что код, который будет обходить стектрейс, не обязательно будет иметь доступ к отладочной информации по программе. Например, инструментам профилирования может потребоваться выбрать только смещения функций, а символизировать их позже, как это делается для синхронных стектрейсов. Мы должны иметь возможность обходить асинхронный стек, не прибегая к дополнительным сложным структурам данных, поскольку из-за таких структур обход стека может получиться излишне затратным. Например, профилировочные инструменты, построенные на основе Linux eBPF, должны иметь возможность выполняться за определенный конечный отрезок времени.
Технически, содержится достаточно информации в типе folly::coro::TaskPromise, относящемся к задаче folly::coro::Task, ее достаточно, чтобы перейти к следующему кадру, поскольку в этом типе уже хранится coroutine_handle для продолжения, а кадр корутины для этого продолжения уже кодирует информацию о том, какая точка приостановки работы какой корутины записаны в членах resumeFn и suspendPoint. Однако, мы сталкиваемся с определенными проблемами, если попытаемся использовать эту информацию напрямую при обходе асинхронного стектрейса.
Представление цепочки асинхронных кадров стека
Если у нас есть указатель на кадр корутины, сохраненный в coroutine_handle, то, теоретически, зная, какова компоновка объекта промиса, мы можем вычислить адрес члена 'продолжение' в составе промиса, где содержится адрес следующего кадра корутины – для этого просто прибавим постоянное значение смещения к указателю на кадр корутины.
Один из подходов, который нам может потребоваться – такой, чтобы промисы всех типов хранили coroutine_handle с продолжением в качестве первого члена данных:
template<typename T>
struct TaskPromise {
std::coroutine_handle<void> continuation;
Try<T> result;
...
};
struct __some_coroutine_frame {
void(*resumeFn)(void*);
void(*destroyFn)(void*);
TaskPromise<int> promise;
int suspendPoint;
};Затем, даже если конкретный тип промиса нам не известен, мы все равно будем знать, что его первый член данных – это coroutine_handle, и что промис ставится сразу же после двух указателей функций. С точки зрения отладчика, обходящего асинхронный стектрейс, можно предположить, что кадры корутин выглядят так:
struct coroutine_frame {
void(*resumeFn)(void*);
void(*destroyFn)(void*);
coroutine_frame* nextFrame;
};К сожалению, этот подход сбоит, когда тип промиса чрезмерно выровнен (overaligned) (то есть, его выравнивание превышает 2 указателя: 32 байт или более на 64-разрядных платформах). Такое может произойти, если тип folly::coro::Task<T> инстанцирован для чрезмерно выровненного типа, например, T, тогда матричный тип оптимизируется для использования с инструкциями SIMD.
В таких случаях компилятор вставляет заполнение между указателями функции и объектом промиса в структуре, так, чтобы добиться правильного выравнивания промиса. Из-за такой вариативности в компоновке становится гораздо сложнее определить, какое именно смещение позволит найти адрес следующего кадра корутины, поскольку это значение зависит от типа. Отладчику необходима информация о том, какова компоновка типа промиса, чтобы иметь возможность вычислить смещение.
Теоретически, можно было бы посмотреть значения указателей resumeFn/destroyFn, чтобы выяснить тип промиса, соответствующий телу корутины в таблице трансляции. Но это либо потребовало бы либо обращаться к отладочной информации, либо модифицировать компилятор, так, чтобы он кодировал эту информацию в составе бинарного файла. Невозможно рассчитывать, что отладочная информация всегда будет доступна, а модификация компилятора – это гораздо более крупный проект. Возможны и другие подходы, например, изменить интерфейс ABI кадров корутин, чтобы заполнение не делалось, но для этого также потребуется вносить изменения в компилятор, и получившаяся реализация будет зависеть от компилятора.
Вместо этого мы решили вставлять новую структуру данных `folly::AsyncStackFrame` в качестве одного из членов промиса корутины, создавая таким образом интрузивный связный список асинхронных кадров. Таким образом, структура приобретает следующий вид:
namespace folly {
struct AsyncStackFrame {
AsyncStackFrame* parentFrame;
// другие члены...
};
}И этот код можно добавить в качестве члена к объектам промисов, связанным с корутинами:
namespace folly::coro {
class TaskPromiseBase {
...
private:
std::coroutine_handle<> continuation_;
AsyncStackFrame asyncFrame_;
...
};Всякий раз, запуская дочернюю корутину при помощи co_awaiting, мы можем перехватить AsyncStackFrame этой дочерней корутины так, чтобы член parentFrame указывал на объект AsyncStackFrame родительской корутины.
При использовании отдельной структуры данных мы приобретаем значительную гибкость в том, как нам удается представлять асинхронные стектрейсы. Такой подход изолирует структуры данных от любых зависимостей, которые могут быть связаны с внутренним устройством компилятора, а в будущем также позволяет нам многократно использовать объекты AsyncStackFrame в асинхронных операциях, не связанных с корутинами. Это обходится нам сравнительно небольшими издержками, касающимися памяти и времени выполнения, поскольку теперь нам фактически приходится хранить и поддерживать два указателя на родительскую корутину. В будущем это решение может быть пересмотрено, если нам понадобится выжать из программы дополнительную производительность – для этого нам потребуется внести в компилятор изменения, которые упоминались ранее.
Итак, мы нашли способ, позволяющий представить цепочку асинхронных кадров. В таком виде отладчик может обходить данную цепочку, и ему не требуется ничего знать о типе конкретного промиса.
