![\"Сравнение](\"/assets/editorial/2021/d-runtime-allocation-profile-2021.svg\")
Сервис отвечает дольше обычного. В trace виден всплеск временных объектов, а рядом работает вызов внешней библиотеки. Команда говорит: «это GC в D». После этого легко отключить сборщик, переписать handler или увеличить таймаут. Ни одно действие не следует из одного симптома. Цена ошибки — потерянный запрос, рост памяти, зависший поток или часы оптимизации участка, который вообще не выполнялся.
\nНадёжный разбор начинается с одного request path. Нужно разделить четыре шага: decode, validation, compute и encode. Рядом надо явно отметить границы GC, FFI и I/O. Тогда вопрос меняется с «почему D медленный?» на «какой участок создал данные, какой запросил память, а какой вышел за пределы процесса?». Такой вопрос можно проверить.
В обычном D-коде динамические массивы, строки и объекты, созданные через new, могут использовать память, которой управляет сборщик. Официальное описание D говорит о сборке как о механизме с неопределённым моментом запуска: запрос дополнительной памяти может запустить цикл, а время цикла не имеет гарантированной верхней границы. При обычной реализации во время сканирования останавливаются потоки, известные сборщику. Поэтому allocation и pause — разные наблюдения, а название DRuntime ещё не является причиной задержки.
Allocation pressure означает, что путь часто просит новую память или создаёт много временных значений. Это гипотеза о причине. GC pause — наблюдение о работе сборщика и времени остановки. Чтобы связать одно с другим, нужны одинаковый вход, профиль процесса и повторяемый способ измерения. Число созданных объектов в учебной модели не является байтами, latency или временем CPU.
\nАтрибут @nogc полезен как проверяемое ограничение для отдельной функции: компилятор отклоняет известные GC-аллокации и вызовы функций без @nogc. У объявления внешней функции нет тела, которое можно проверить, поэтому пометка @nogc на FFI — договорённость между D и библиотекой, а не аудит её реализации. Она также не отменяет блокировку сокета, ожидание сети или правила владения буфером. Это контракт участка D-кода, а не сертификат всего request path.
Рассмотрим учебный endpoint, который принимает два целых числа и возвращает их сумму. Вход — sum(19, 23). Успешный ответ — {"requestId":"runtime-training-42","total":42}. Ошибочный вход должен остановиться после validation и вернуть код ошибки. В модель добавим два fixture-варианта: allocation-heavy создаёт больше временных значений, а reuse переиспользует промежуточный буфер. Оба обязаны выполнить одинаковые этапы и вернуть одинаковый результат.
| Симптом | Причина-гипотеза | Проверка | Действие |
|---|---|---|---|
| Растёт число временных объектов | Повторное создание строк или массивов | Сравнить allocation profile на одинаковом входе | Уменьшить временное состояние локально и повторить тест |
| Есть пауза около allocation | GC начал цикл после запроса памяти | Сопоставить профиль GC, thread stop и request trace | Проверить размер и частоту allocation; не отключать GC глобально |
| Долгий участок после перехода в C | FFI-вызов блокирует или копирует данные | Замерить границу до и после foreign call | Проверить ABI, ownership, timeout и error route |
| Путь ждёт внешнюю систему | Сеть, файл или database I/O | Разделить время ожидания и вычисления | Проверить timeout, retry и отмену отдельно от GC |
| Валидный и невалидный входы имеют один trace | Ошибка проходит в compute | Запустить error input и проверить отсутствие compute | Закрыть error route тестом до оптимизации |
В модели есть два разных порога. Первый — выбранный командой budget в шесть allocation units: он отвечает на вопрос «проходит ли fixture нашу проверку». Второй — условная model boundary в восемь units, которую trace помечает как повод проверить GC-гипотезу. Heavy-вариант получает двенадцать units и пересекает оба порога, reuse — три и не пересекает ни один. Ни один из порогов не является лимитом DRuntime. Оба варианта должны иметь одинаковые work units, status и body. Если reuse «выигрывает» за счёт пропущенного validation или укороченного ответа, сравнение недействительно.
\nНиже — маленький самодостаточный пример на D. Он показывает три разных утверждения: @nogc ограничивает проверяемую функцию, nothrow относится к исключениям, а extern(C) задаёт соглашение вызова. Ни одно из них само по себе не описывает задержку и владение памятью во внешней библиотеке.
struct Request\n{\n int left;\n int right;\n}\n\n@nogc nothrow\nint addChecked(int left, int right)\n{\n // Здесь нет dynamic array, new или вызова неизвестной функции.\n return left + right;\n}\n\nextern(C) @nogc nothrow\nint foreign_sum(const(int)* value);\n\n@nogc nothrow\nint callForeign(const(int)* value)\n{\n // Компилятор проверяет только контракт объявления.\n return foreign_sum(value);\n}\n\n@nogc nothrow\nint handle(Request request)\n{\n return addChecked(request.left, request.right);\n}Теперь пример самодостаточен на уровне типов: Request объявлен, а вызов FFI вынесен в отдельную функцию. Компилятор видит только объявление foreign_sum; реализация C может иметь свои аллокации и ожидание, если контракт библиотеки это допускает. extern(C) задаёт соглашение вызова, но не описывает ownership, срок жизни указателя, блокировку или timeout. Реальная C-функция должна подтвердить эти свойства отдельным контрактным тестом.
Если API принимает указатель на память GC, надо согласовать срок жизни и корень, который сборщик видит. Документация D отдельно предупреждает: если единственный указатель на объект хранится вне областей, которые сканирует GC, объект может быть освобождён. Для буфера, которым владеет C-библиотека, безопаснее использовать её аллокатор и её освобождение по явному контракту. D-код не должен освобождать такой буфер своим аллокатором. Нарушение ownership — самостоятельная ошибка, даже когда GC не запускался.
\nНе стоит начинать с глобального GC.disable(). Такой вызов меняет условия всего процесса: он отключает обычные циклы, но не запрещает GC-аллокации, а при невозможности получить память у ОС сборщик всё равно может запуститься как последний шанс. Короткий тест поэтому может скрыть паузу и одновременно увеличить heap. Локальную гипотезу проверяйте локальным изменением: уберите временную конкатенацию, переиспользуйте буфер, ограничьте размер входа или вынесите внешний вызов за измеренную границу. Настройка runtime допустима только после профиля, с лимитом памяти и планом возврата.
Сначала зафиксируйте вход, результат и ошибочный результат. Затем запишите этапы в порядке выполнения. У валидного запроса должны быть decode → validation → compute → encode. У невалидного — decode → validation → encode-error; compute, FFI и I/O не должны появляться без отдельной причины.
После этого добавьте allocation units и рабочие units. В учебном примере heavy даёт 12 allocation units и пересекает model boundary 8, reuse даёт 3 и остаётся ниже. У обоих девять work units. Запись gc-boundary означает, что fixture пересекла выбранный порог. Она не означает паузу, остановку потока или реальный запуск сборщика. Для вывода о production нужны данные настоящего DRuntime и настоящего процесса.
Удобный формат записи trace можно сделать обычным JSON, чтобы его можно было сохранить рядом с запуском и сравнить без интерпретации D-кода:
\n[\n {"stage":"decode"},\n {"stage":"validation","result":"ok"},\n {"stage":"compute","workUnits":9},\n {"stage":"allocation","units":12},\n {"stage":"gc-boundary","status":"observed-in-model"},\n {"stage":"ffi","status":"not-performed"},\n {"stage":"io","status":"not-performed"},\n {"stage":"encode","status":"success","total":42}\n]Это fixture, а не исполняемый D-код. Минимальная проверка его воспроизводимости — убедиться, что последний этап успешного прогона содержит total:42, FFI и I/O имеют статус not-performed, а значение gc-boundary нигде не выдаётся за измеренную паузу.
decode, validation, compute и encode. Отдельно отметьте GC, FFI и I/O.Модель не запускает D compiler, GC, HTTP, сеть, файл, database, foreign code или profiler. Она не измеряет throughput, latency, RSS, pause time, thread scheduling или размер heap. Учебные allocation units нельзя переносить в настройки процесса. Схема также не доказывает, что переиспользование буфера полезно для любого размера входа: оно может увеличить сложность, удерживать память дольше и создать ошибку среза.
\nОтрицательный путь должен остаться видимым. Если validation не проходит, handler не должен вызывать compute. Если allocation budget превышен, это повод остановить конкретную гипотезу и собрать профиль, а не повод отключить GC. Если FFI не имеет ясного ownership или timeout, безопасное действие — не расширять его использование. Если I/O не разделено на connect, wait и decode, сначала уточните измерение. Неопределённость — результат проверки, а не разрешение угадывать.
\nГотовность можно проверить тремя условиями. Один и тот же валидный вход даёт один и тот же status и body до и после изменения. Невалидный вход останавливается до compute и не создаёт скрытый внешний вызов. Для заявленной границы сохранён trace с версиями compiler и DRuntime, окружением и фактическим измерением; учебная модель явно помечена как fixture. Если хотя бы одно условие не выполнено, оптимизация не закрыта.
\n@nogc, и требование к вызываемым функциям.GC.disable(), аварийный запуск цикла при нехватке памяти и GC.minimize().