![\"Путь](\"/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-коде динамические массивы, строки и некоторые объекты используют память, которой управляет сборщик. Документация D описывает automatic memory management как часть языка, но не обещает фиксированную задержку коллекции. Сборщик может удерживать память, остановить известные ему потоки на время сканирования и вернуть управление после обработки недостижимых объектов. Поэтому allocation и pause — разные наблюдения.
\nAllocation pressure означает, что путь часто просит новую память или создаёт много временных значений. Это гипотеза о причине. GC pause — наблюдение о работе сборщика и времени остановки. Чтобы связать одно с другим, нужны одинаковый вход, профиль процесса и повторяемый способ измерения. Число созданных объектов в учебной модели не является байтами, latency или временем CPU.
\nАтрибут @nogc полезен как проверяемое ограничение для отдельной функции. Компилятор запрещает в ней операции, которые обращаются к GC напрямую или через неразрешённый вызов. Но @nogc не делает автоматом безопасным FFI, не отменяет блокировку сокета и не доказывает отсутствие аллокаций в библиотеке, вызванной за другой границей. Это контракт участка D-кода, а не сертификат всего request path.
Рассмотрим учебный endpoint, который принимает два целых числа и возвращает их сумму. Вход — sum(19, 23). Успешный ответ — {"requestId":"runtime-training-42","total":42}. Ошибочный вход должен остановиться после validation и вернуть код ошибки. В модель добавим два варианта: 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 тестом до оптимизации |
В такой модели удобно ввести условный бюджет в шесть allocation units. Heavy-вариант получает двенадцать units, reuse — три. Это не лимит DRuntime. Это только порог, который помогает проверить развилку. Оба варианта должны иметь одинаковые work units, status и body. Если reuse «выигрывает» за счёт пропущенного validation или укороченного ответа, сравнение недействительно.
\nНиже — маленький пример на D. Он показывает, как отметить функцию, которая не должна обращаться к GC, и как оставить внешний вызов за отдельным контрактом. Код учебный: он не выполняет сеть, не вызывает C-библиотеку и не измеряет задержку.
\nimport core.stdc.stdlib : malloc, free;\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\nint handle(Request request)\n{\n auto total = addChecked(request.left, request.right);\n // foreign_sum и ownership указателя требуют отдельного contract test.\n return total;\n}Аннотация ограничивает только то, что компилятор может проверить в этой функции и её вызовах. Она не сообщает, сколько времени займёт foreign_sum, кто освобождает указатель и может ли внешняя библиотека ждать сеть. Если API принимает память GC, надо согласовать срок жизни и корень, который сборщик видит. Если библиотека владеет буфером, D-код не должен освобождать его своим аллокатором. Нарушение ownership — самостоятельная ошибка, даже когда GC не запускался.
Не стоит начинать с глобального GC.disable(). Такой вызов меняет условия всего процесса. Он может убрать наблюдаемую сборку на коротком тесте, но оставить рост heap и перенести проблему на более поздний request. Локальная гипотеза должна проверяться локальным изменением: убрать временную конкатенацию, переиспользовать буфер, ограничить размер входа или вынести внешний вызов за измеренную границу. Настройка runtime допустима только после профиля, с лимитом памяти и планом возврата.
Сначала зафиксируйте вход, результат и ошибочный результат. Затем запишите этапы в порядке выполнения. У валидного запроса должны быть decode → validation → compute → encode. У невалидного — decode → validation → encode-error; compute, FFI и I/O не должны появляться без отдельной причины.
После этого добавьте allocation units и рабочие units. В учебном примере heavy даёт 12 allocation units и пересекает порог 8, reuse даёт 3 и остаётся ниже. У обоих девять work units. Запись gc-boundary означает, что модель пересекла порог. Она не означает паузу, остановку потока или реальный запуск сборщика. Для production-вывода нужны данные настоящего DRuntime и настоящего процесса.
const trace = [\n 'decode',\n 'validation:ok',\n 'compute',\n 'allocation:12 units',\n 'gc-boundary:observed-in-model',\n 'ffi:not-performed',\n 'io:not-performed',\n 'encode:success',\n];\n\nassert(trace[$ - 1] == 'encode:success');Запись ffi:not-performed важна. Граница может быть частью архитектуры, но в данном прогоне вызов не выполнялся. Иначе читатель приписывает внешней библиотеке задержку, которой в тесте не было. То же относится к I/O. Намерение обратиться к database не является ожиданием ответа database.
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 с версией инструмента, окружением и фактическим измерением; учебная модель явно помечена как модель. Если хотя бы одно условие не выполнено, оптимизация не закрыта.
\n@nogc.