На 31 июля 2026 года строгий аудит проходит 133 из 358 созданных материалов. Остальные 225 не считаются «почти готовыми»: их нужно заменить, а не косметически удлинить.
На 31 июля 2026 года строгий аудит проходит 136 из 358 созданных материалов. Остальные 222 не считаются «почти готовыми»: их нужно заменить, а не косметически удлинить.
<code>cover</code>, <code>excerpt</code>, <code>readingMinutes</code> и
<code>contentHtml</code>. Отдельная проверка подтвердила отсутствие
<code>date</code> и <code>author</code> во всех трёх revision. Базовый архив
сохраняет их исходными.
## Проход 1. Тон, структура и объём — пройдено
| Revision | Проблема и цена в первых двух абзацах | M4 и практическая граница | Body |
| --- | --- | --- | --- |
| Practice | Endpoint объявляют «тормозящим из-за runtime D» без входа, result и границы; цена — случайная глобальная правка | Один request, явный result, budget и owner следующей проверки | **8 109** знаков |
| Mechanism | Слово «быстро» скрывает decode, validation, compute, encode и внешние границы; цена — оптимизация ломает error route или объясняет FFI GC-ом | Trace одного handler, одинаковый result двух вариантов, структура до измерения | **8 544** знака |
| Field | Heavy-ветка пересекает учебный budget и оставляет GC boundary; цена — назвать его паузой или обвинить dependency без вызова | Evidence → contract → units → отдельная граница → обратимый change | **9 633** знака |
- Во всех текстах есть ситуация и стоимость ошибки в начале, таблица,
содержательный <code>figure</code> с <code>alt</code>/<code>figcaption</code>,
исполнимый JS-фрагмент, нумерованный маршрут «симптом → причина → проверка
→ действие», ограничения и отдельный раздел источников.
- Голос М4 октября 2021: короткая техническая речь, одна граница на абзац,
условные выводы вместо выдуманного опыта. Новое умение логично продолжает
предыдущие материалы о данных и событиях: автор изолирует request path и
его контракт, прежде чем рассуждать о runtime.
- На первом автоматическом проходе draft gate указал, что practice и mechanism
не называли проблему буквальным словом в первых 800 знаках. Формулировки
исправлены. В том же self-review обнаружено расхождение: в prose и графике
было написано 11 work units при фактических 9. Все упоминания исправлены,
затем полный draft audit повторён с итогом PASS.
Вердикт: **пройдено**. Нет SLA, production-метрик, benchmark results,
реального профиля или заявления, что runtime сам по себе делает endpoint
быстрее.
## Проход 2. Техника, историческая точность и fixture — пройдено
Сквозная <code>runDRuntimeServiceFixture()</code> выполняется в одном
Node-процессе. Один valid in-memory request проходит
<code>decode → validation → compute → encode</code>; между compute и encode
trace явно сохраняет FFI/I/O boundaries c
<code>invocation: "not-performed"</code>. Invalid request проходит
<code>decode → validation-error → encode-error</code> и не доходит до
compute, FFI или I/O.
| Инвариант | Фактический результат fixture |
| --- | --- |
| Handler result одинаков | обе valid-ветки вернули status 200 и один body с <code>total:42</code> |
| Allocation budget видим | heavy: 12 units при budget 6, вне budget; reuse: 3 units, внутри budget |
| Работа handler не подменена оптимизацией | у valid-веток одинаковые 9 work units |
| GC не выдан за замер | heavy пересекает порог 8 и получает <code>gc-boundary</code> с <code>not-a-runtime-pause</code> |
| FFI/I/O boundary видимы | обе success-ветки содержат две boundaries, но ни одна не выполняет внешний вызов |
| Error route не скрыт | invalid input возвращает status 400 и имеет <code>validation-error</code>/<code>encode-error</code> |
Финальный запуск подтвердил **12 из 12** истинных assertions. Fixture не
запускает D compiler, D runtime, GC, HTTP, file, network, FFI, foreign code,
profiler, benchmark или внешний процесс. Его units не называются bytes,
CPU, latency, временем или паузой.
Исторические и технические claims ограничены первичными/официальными
официальный выпуск от 9 августа 2021 года, существовавший до всех
октябрьских дат партии;
- [DRuntime core/memory.d at the 2.097.2 snapshot](https://github.com/dlang/druntime/blob/f978df34a48613492240e8398227419b14002bef/src/core/memory.d) —
immutable исходник для исторической проверки терминов.
Все пять ссылок получили HTTP 200 в link preflight. Первые три зафиксированы
на commit <code>d5798c666479e8c4c918221e10ebf997b1f5f89f</code>, на который
указывает тег D 2.097.2; снимок DRuntime отдельно зафиксирован на commit
<code>f978df34a48613492240e8398227419b14002bef</code>. Ни release number, ни
документация не используются как источник несуществующего benchmark,
прошлой pause или поведения воображаемого сервиса.
Вердикт: **пройдено**. Технические результаты относятся ровно к
детерминированной модели, а исторические формулировки не переносят текущую
документацию на незафиксированный запуск 2021 года.
## Проход 3. SVG, ссылки и preflight — пройдено
- В каждом SVG есть <code>title</code>, <code>desc</code> и
<code>role="img"</code>. Visuals поясняют разные вопросы: путь request,
сравнение units и маршрут rollback-safe диагностики.
- Первый mobile render выявил неясные боковые стрелки в request/diagnosis,
переполнение длинных footer-подписей и пересечение колонок в allocation
profile. Стрелки заменены последовательным маршрутом, подписи разбиты на
<titleid="title">Сравнение учебных allocation units для двух вариантов одного request</title>
<descid="desc">Две колонки сравнивают allocation-heavy и reuse для decode, validation, compute и encode. Heavy получает 12 units и пересекает условный порог 8, reuse получает 3 units. У обоих одинаковый result и 9 work units. Числа не являются байтами, временем или benchmark.</desc>
<titleid="title">Безопасная диагностика учебного request в D-сервисе</title>
<descid="desc">Вертикальный маршрут диагностики начинает с сохранения результата, error route и trace. Затем он проверяет contract handler, allocation budget, условную границу GC и неисполняемые FFI/I/O boundaries. Каждый шаг задаёт обратимое действие и запрещает менять runtime глобально без отдельного evidence.</desc>
<titleid="title">Один учебный request в D-сервисе: основной путь, модельные allocations и внешние границы</title>
<descid="desc">Вертикальная схема показывает путь decode, validation, compute и encode для одного учебного request. На пути видны model allocation units, условная граница GC и неисполняемые FFI и I/O boundaries. Ошибка validation уходит в encode-error и не доходит до compute.</desc>
note:'неизменяемый исходник официальной спецификации из тега v2.097.2; он задаёт терминологию automatic memory management, но не профиль конкретного запущенного сервиса',
};
constdNoGcFunctions={
title:'D 2.097.2: source snapshot of @nogc function specification',
note:'неизменяемый исходник официальной спецификации атрибута <code>@nogc</code>; он ограничивает проверяемый D-код и не доказывает свойства внешней библиотеки или операции ввода-вывода',
};
constdApplicationBinaryInterface={
title:'D 2.097.2: source snapshot of Application Binary Interface specification',
note:'неизменяемый исходник официальной границы ABI для взаимодействия с C ABI целевой системы; наличие границы не говорит о стоимости или безопасности конкретного foreign call',
};
constdRelease0972={
title:'D 2.097.2: официальный release record',
url:'https://dlang.org/changelog/2.097.2.html',
note:'выпуск опубликован 9 августа 2021 года и служит проверяемой дооктябрьской точкой для терминов; статья не выводит из номера версии benchmark или runtime profile',
note:'точная фиксация исходника DRuntime, на которую указывал тег v2.097.2; используется для исторической проверки терминов, не как замена измерения приложения',
excerpt:'Практический способ разобрать один сервисный запрос в D: отделить результат handler от учебного бюджета allocation units, отметить границы GC, FFI и I/O и подготовить следующий проверяемый шаг.',
readingMinutes:14,
},
[
paragraph('В сервисе появляется фраза «этот endpoint тормозит из-за runtime D». Проблема не в том, что в ней упомянут GC. В ней нет входа, результата, границы и доказательства. Цена такой формулировки — случайная правка: отключить что-то глобально, переписать FFI-вызов или добавить кеш, а затем не суметь объяснить, какой участок запроса вообще изменили.'),
paragraph('Для начала я бы не пытался измерить весь сервис и не переносил ожидание «быстро» из PHP или JavaScript. Возьмём один учебный request: <code>decode → validation → compute → encode</code>. Рядом отметим две видимые границы — FFI и I/O — но не выполним ни foreign call, ни ввод-вывод. В этой статье allocation и work считаются детерминированными единицами модели. Это не байты, не время CPU, не latency и не профиль настоящего runtime.'),
heading('Сначала формулируем вопрос, который можно закрыть'),
paragraph('У одного endpoint должна быть короткая карточка. Что приходит на вход? Какой успешный результат остаётся неизменным? Где request может закончиться ошибкой? Какая граница интересует сейчас: построение временных объектов, наблюдаемая точка GC, вызов за ABI или выход в I/O? Пока в карточке смешаны все эти вопросы, команда сравнивает несравнимое: правило validation, стоимость encoding и поведение внешней библиотеки.'),
paragraph('Такое сужение не обедняет расследование. Оно отделяет контракт handler от гипотезы о ресурсе. Если оба учебных варианта возвращают один body, но один превышает выбранный allocation budget, мы получили повод посмотреть на создание промежуточного состояния. Мы ещё не получили право назвать вариант медленнее, включать настройку DRuntime или обещать паузу в продуктивном процессе.'),
dataTable(
'Карточка одного учебного request',
['Поле','Фиксируем в модели','Зачем это нужно','Чего это не доказывает'],
[
['Вход','<code>sum(19, 23)</code> и идентификатор request','оба варианта получают одинаковые данные','формат настоящего HTTP-запроса или его нагрузку'],
['Успех handler','<code>{"requestId":"runtime-d-training-42","total":42}</code>','сравниваем оптимизацию при равном результате','корректность любого бизнес-правила'],
['Бюджет','<code>6 allocation units</code>','есть явный порог для учебной развилки','байты памяти, latency или CPU'],
['GC boundary','пересечение порога <code>8</code> в trace','видно, где модель ставит вопрос о GC','реальную паузу, алгоритм или schedule сборщика'],
['FFI / I/O','intent записан как boundary, invocation = <code>not-performed</code>','внешняя граница не исчезает из диагноза','вызов библиотеки, сеть, файл или блокировку'],
],
),
paragraph('У карточки нужен владелец следующей проверки, но не обязательно «владелец всего runtime». Автор handler отвечает за равенство result и error route. Тот, кто знает внешний contract, отвечает за отдельную проверку FFI или I/O. Если владельца ещё нет, boundary так и записывают неизвестной, а не подменяют её словом «D». Это снимает ложный выбор между «оптимизировать всё» и «ничего не делать»: можно сохранить контекст одного request и передать только нужный вопрос следующему человеку.'),
heading('Выбираем наблюдаемый профиль, а не название оптимизации'),
paragraph('В модели есть два варианта. <code>allocation-heavy</code> добавляет временные единицы на decode, validation, compute и encode. <code>reuse</code> записывает меньше единиц там, где мы условно переиспользовали промежуточное состояние. У обоих одинаковые вход, work units и ответ. Значит, сравнение не прячет изменение результата за словом «оптимизация».'),
paragraph('Бюджет здесь намеренно маленький и проектный. Его задача — сделать проверку бинарной: первый путь за границей, второй внутри. В реальном проекте такой порог сначала выбирают из цели конкретного endpoint и затем подтверждают инструментом, который подходит версии compiler, DRuntime и окружению. Не надо брать учебное число 6 как настройку heap, лимит процесса или триггер GC. Это номер строки в договоре fixture, а не команда для запуска.'),
'Схема одного учебного сервисного запроса: decode, validation, compute и encode образуют основной путь; рядом явно отмечены model allocation, условная граница GC и неисполняемые FFI/I/O boundaries. Ошибка validation идёт в encode-error и не доходит до compute.',
'Схема фиксирует маршрут и ответственность шага. Цветная отметка GC — порог учебных allocation units, не запись о паузе настоящего D runtime.',
),
heading('Фиксируем результат и trace одним JS-примером'),
paragraph('Fixture находится в этом же revision-модуле, поэтому пример можно исполнить без компилятора D и без инфраструктуры. Он не измеряет собственные JavaScript allocations. Он читает уже собранную модель и проверяет её assertions. Если кто-то поменяет путь так, что reuse начнёт давать другой body, тест остановится даже при красивом меньшем числе units.'),
codeBlock(fixtureRunExample),
paragraph('Результат таблицы должен быть простым: <code>allocation-heavy</code> даёт тот же body, но 12 условных allocation units и выход за budget 6; <code>reuse</code> даёт тот же body, 3 units и остаётся внутри. Work units равны. Это сделано специально: если у вариантов разный output или разная работа handler, обсуждать allocation рано. Сначала возвращаем одинаковый контракт, потом меняем гипотезу о промежуточном состоянии.'),
heading('Как связать такую карточку с D, не выдумывая свойства runtime'),
paragraph('Официальная спецификация D описывает automatic memory management и отдельно атрибут <code>@nogc</code>. Для инженерного разговора отсюда полезна граница: ограничение на D-код не делает безопасной неизвестную часть за вызовом. Точно так же D ABI описывает взаимодействие с C ABI целевой системы, но один факт пересечения ABI не говорит, выделяет ли память библиотека, блокирует ли она поток и какой контракт ownership у её параметров. Эти вопросы нужно записать в trace и проверить на выбранной версии, а не угадывать по названию языка.'),
paragraph('Для исторической точки practice-заметки от 7 октября использован выпуск D 2.097.2, опубликованный до этой даты. Release record и точный снимок <code>core/memory.d</code> нужны здесь только для проверки терминов. Это не попытка восстановить профиль старого процесса: без исходника request, compiler options, линковки, операционной системы и данных такое утверждение было бы выдумкой. Поэтому следующий шаг остаётся узким: взять один живой endpoint и добавить к нему такой же request trace, а фактическое измерение провести отдельным инструментом и отдельно сохранить его условия.'),
heading('Маршрут: симптом → причина → проверка → действие'),
orderedList([
'<strong>Симптом.</strong> Назовите один endpoint и один видимый результат: какой body или error code он должен вернуть. Не начинайте со слова «runtime».',
'<strong>Причина-гипотеза.</strong> Выберите один слой: временные объекты на пути decode/compute/encode, условная GC boundary, FFI boundary или I/O boundary. У каждой версии должна быть отдельная карточка.',
'<strong>Проверка.</strong> Прогоните одинаковый in-memory input через два учебных варианта. Убедитесь, что body, status и work units совпали, а trace содержит все выбранные границы.',
'<strong>Действие.</strong> Если только allocation budget различается, подготовьте локальный change, который сохраняет output. Не меняйте глобальную GC-конфигурацию и не переписывайте foreign code до отдельного доказательства.',
'<strong>Повторная проверка.</strong> После change повторите исходный input, сохраните trace до/после и добавьте error input. Успех без error route не закрывает handler.',
'<strong>Следующий уровень.</strong> Лишь затем выбирайте реальный profiler и записывайте compiler, DRuntime, платформу, вход и окно наблюдения. Учебная fixture к этому готовит вопрос, но не заменяет ответ.',
]),
heading('Ограничения и следующий проверяемый шаг'),
paragraph('Эта модель не запускает D compiler, D runtime, GC, HTTP, сеть, файл, database, FFI, profiler или benchmark. Её <code>gc-boundary</code> — запись о пересечении заданного порога; она не подтверждает pause. Её FFI и I/O entries — неисполненные границы; они не подтверждают вызов, ownership, retry или блокировку. Она также не моделирует concurrency, backpressure, scheduler, исключения D, сериализацию реального протокола и лимиты процесса.'),
paragraph('Для своего проекта возьмите один нечувствительный test input и выпишите результат, error path, owner boundary и версию инструмента. Если после этого вопрос всё ещё звучит как «runtime D медленный», карточка недостаточно узкая. Если он звучит как «при том же result в encode создаётся лишнее промежуточное состояние», есть безопасный следующий эксперимент. Такой переход от ярлыка к проверке полезнее любой заранее выбранной настройки.'),
excerpt:'Разбираем один request path в D как наблюдаемую структуру: где в учебной модели появляются allocation units, условная GC boundary, FFI/I/O boundaries и почему слово «быстро» не переносится между runtime.',
readingMinutes:15,
},
[
paragraph('Когда один handler называют «быстрым на D», обычно пропускают механизм. Проблема в том, что в ответе могли быть decode, проверка входа, вычисление, кодирование, вызов за ABI и выход в I/O, но в разговор попало одно слово. Цена такой потери структуры — неверная оптимизация: уменьшить allocation в одном месте и не заметить, что error route изменился, или объяснить внешний вызов свойствами GC.'),
paragraph('Разберём один request как учебную цепочку <code>decode → validation → compute → encode</code>. У неё есть trace, result, work units и allocation units. Два варианта меняют только модель временных объектов: один получает 12 units, другой 3, но оба возвращают тот же response и те же 9 work units. Это не benchmark D, не профиль DRuntime и не сравнение языков. Это способ увидеть, какой вопрос нужно отдать измерению позже.'),
heading('Путь request — это контракт, а не полоса времени'),
paragraph('Decode принимает in-memory object и собирает нормализованный request. Validation отделяет неверную операцию от вычисления. Compute складывает два целых числа и оставляет в trace намерения FFI и I/O без их исполнения. Encode превращает успешный result или error в одинаково определённый body. В таком порядке можно спросить, где выросла модель allocation, не смешивая ошибку входа с работой внешней зависимости.'),
paragraph('Для valid input мы требуем все шесть следов: <code>decode</code>, <code>validation</code>, <code>compute</code>, <code>ffi-boundary</code>, <code>io-boundary</code>, <code>encode</code>. Для invalid input требуем другой, но тоже явный путь: <code>decode</code>, <code>validation-error</code>, <code>encode-error</code>. Compute и внешние boundaries туда не входят. Это важнее счастливого ответа: если handler молча теряет error route, меньший allocation count не является улучшением.'),
dataTable(
'Наблюдаемые участки учебного request path',
['Участок','Что записывает fixture','Вопрос к реальной системе','Что нельзя заключить'],
[
['Decode','shape входа, 2 work units, вариант allocation','какие данные действительно преобразуются на входе?','что HTTP parser или framework работает именно так'],
['Validation','accepted либо <code>invalid-operation</code>','какая ветка завершает request до compute?','что validation не создаёт объектов в реальном запуске'],
['Compute','операция <code>19 + 23</code>, 4 work units','какой промежуточный state необходим результату?','что арифметика является bottleneck'],
['GC boundary','порог 8 units пересечён только heavy-веткой','где начать фактическую проверку allocation/GC?','наличие, длину или причину pause'],
['FFI / I/O','<code>invocation: not-performed</code>','где нужен отдельный contract внешнего вызова?','вызов, скорость, ownership или retry политики'],
['Encode','стабильный success/error body','сохранился ли внешний contract endpoint?','поведение реального serializer'],
],
),
heading('Allocation и GC: отделяем структуру от измерения'),
paragraph('В fixture allocation units добавляются не потому, что JavaScript нашёл реальные объекты, а потому, что модель помечает четыре проектных места: decode request shape, temporary state validation, intermediate state compute и response buffer encode. Heavy-вариант записывает 3 + 1 + 5 + 3, reuse-вариант — 1 + 0 + 1 + 1. Сумма задана явно, поэтому review видит, какая правка должна поменять budget.'),
paragraph('После пересечения 8 units модель добавляет <code>gc-boundary</code> с полем <code>measurement: "not-a-runtime-pause"</code>. Это предохранитель против самой частой подмены: «увидели границу — измерили GC». Официальная документация D действительно обсуждает автоматическое управление памятью и ограничения collector, но из этого не следует наблюдаемая история конкретного request. Нужны фактические условия и отдельный профиль. Наш trace только делает место вопроса видимым.'),
'Сравнение двух учебных вариантов request path: allocation-heavy набирает 12 allocation units и пересекает условный порог GC 8, reuse набирает 3 units; у обоих 9 work units и одинаковый handler result. Подпись подчёркивает, что units не являются байтами или временем.',
'Диаграмма сравнивает только заданные счётчики fixture. Зелёная ветка не названа быстрее: она лишь проходит выбранный учебный budget при неизменном результате.',
),
heading('FFI и I/O должны быть в trace, даже если вызов не выполняется'),
paragraph('Внешняя граница часто пропадает из разговора, пока не появится проблема. В учебном request есть <code>ffiIntent: "normalize-scalar"</code> и <code>ioIntent: "write-audit-record"</code>. Fixture пишет их как boundaries с <code>invocation: "not-performed"</code>. Таким образом код не притворяется, что вызвал C-функцию, открыл файл, ушёл в сеть или увидел процесс. Но будущий интеграционный тест уже знает, где должен появиться owner, contract данных, ошибка и cancellation.'),
paragraph('D ABI описывает совместимость с C ABI целевой системы, однако ABI не заменяет договор вызова. У реальной границы отдельно проверяют lifetime аргументов, формат ownership, error code, поток, блокировку, allocator и возможность повторить операцию. Для I/O отдельно нужны protocol, timeout, idempotency, права и данные. Ни один из этих пунктов не выводится из <code>@nogc</code>, из названия DRuntime или из меньшего allocation budget.'),
heading('Почему «быстро» не переносится между runtime'),
paragraph('Слово «быстро» содержит больше переменных, чем кажется. Меняется вход, compiler, версия runtime, link mode, target ABI, операционная система, библиотека, allocator, параллельность и метод измерения. Даже одинаковый source не гарантирует одинаковый путь в другом окружении. Поэтому локальный вывод «reuse имеет 3 units» нельзя превращать в фразу «D быстрее другого runtime». У модели нет секунд, CPU cycles, памяти процесса и внешнего вызова, а значит сравнивать ей нечего.'),
paragraph('Историческая рамка здесь тоже нужна. К октябрю 2021 существовал release D 2.097.2; его record и фиксированный source snapshot дают проверяемую точку для терминов DRuntime. Но название версии не заменяет command line, код application или collected evidence. Если нужно сопоставить две среды, сначала фиксируют по одному request и один ожидаемый output, затем одинаково описывают compiler/runtime/platform и только после этого читают реальные результаты.'),
heading('Минимальный JS-пример: читаем trace, а не придумываем профиль'),
paragraph('Следующий фрагмент использует экспортированную fixture. Он не вызывает D API, не открывает сокет и не строит benchmark. Он показывает те trace entries, которые нужны, чтобы отделить успешный path от учебной границы allocation. Если порядок исчезнет, это будет видно до обсуждения реального profiler.'),
codeBlock(traceExample),
paragraph('На heavy-ветке trace содержит <code>gc-boundary</code>, обе неисполняемые external boundaries и success encode. На reuse-ветке есть те же handler stages и boundaries, но нет пересечения порога 8. У обоих 9 work units. Это делает проверку строгой: если reuse «выигрывает» только потому, что пропустил validation или encode, assertion о полном пути станет ложным.'),
heading('Маршрут: симптом → причина → проверка → действие'),
orderedList([
'<strong>Симптом.</strong> Зафиксируйте один request, result и error response, которые вызывают вопрос. Не объединяйте их с общими рассказами о нагрузке.',
'<strong>Причина-гипотеза.</strong> Привяжите подозрение к конкретному участку decode, validation, compute, encode, GC boundary, FFI boundary или I/O boundary. «Runtime» не является участком.',
'<strong>Проверка.</strong> Постройте trace valid и invalid inputs. У valid должны быть decode/validation/compute/encode, у invalid — явный error path без compute и external boundaries.',
'<strong>Проверка budget.</strong> Сравните варианты только после равенства body, status и work units. Отдельно покажите, какой из них пересёк выбранный порог.',
'<strong>Действие.</strong> Если изменился только model allocation, готовьте маленькую обратимую правку локального состояния. Если след указывает на FFI/I/O, сначала описывайте contract и тестируйте границу отдельно.',
'<strong>Следующий шаг.</strong> Для фактической производительности соберите реальный профиль с версией compiler/DRuntime, входом, окружением и методом. Не переносите учебный verdict между runtime.',
]),
heading('Ограничения и следующий проверяемый шаг'),
paragraph('Модель не подтверждает скорость, pause, GC algorithm, масштабирование, throughput, latency, cache behavior, memory footprint, thread scheduling, HTTP semantics, ABI compatibility конкретной библиотеки или эффект compiler flag. В ней нет D compiler, runtime, file, network, foreign code, profiler, benchmark или process-level telemetry. <code>@nogc</code> в источнике не запускается и не используется как оправдание отключить collector.'),
paragraph('Практический следующий шаг — перенести названия stages на один реальный handler, не меняя его поведения: сначала получить trace input/result/error, затем выбрать одну границу для независимого измерения. Если граница FFI, добавить отдельный contract test. Если граница I/O, добавить отдельный test timeout/error. Если остался вопрос о allocations, записать точную версию инструмента и повторяемый вход. Так система получает доказательство, а не переносимый ярлык «быстро».'),
],
commonSources,
);
constfieldArticle=createRevision(
{
slug:'editorial-2021-10-field-d-runtime-service',
title:'Разбор request в D-сервисе: allocation, условная GC-граница и безопасный откат',
excerpt:'Полевой маршрут для одного request: как не спутать рост учебных allocation units с паузой, сохранить evidence о FFI/I/O boundary, увидеть error route и выбрать rollback-safe действие.',
readingMinutes:15,
},
[
paragraph('В trace учебного request heavy-вариант пересёк allocation budget 6 и получил отметку <code>gc-boundary</code>. Рядом есть FFI и I/O boundaries, а invalid input уходит в error response. Самая дорогая ошибка здесь — назвать отметку реальной паузой, обвинить внешнюю систему без вызова или сразу менять конфигурацию runtime. Тогда исчезают и причина, и возможность безопасно откатить change.'),
paragraph('Это не отчёт о production-инциденте. В нём нет реального профиля, сервера, D compiler, DRuntime, HTTP, foreign code или I/O. Есть один детерминированный in-memory request, два варианта одной обработки и error input. Его цель — собрать evidence в правильном порядке: result, stage trace, заданные units, выбранная boundary и только потом действие. Такая дисциплина полезна до того, как появятся цифры настоящего инструмента.'),
heading('Собираем evidence до изменения runtime'),
paragraph('Первый набор evidence небольшой: request id, нормализованный вход, success body либо error body, последовательность stages, allocation/work units модели, budget и список external boundaries. Значения, похожие на время, здесь запрещены: fixture не показывает миллисекунды, CPU или память процесса. Если соседняя система говорит о паузе, это отдельный факт с отдельным источником, а не расшифровка записи <code>gc-boundary</code>.'),
paragraph('В valid варианте body остаётся <code>{"requestId":"runtime-d-training-42","total":42}</code>. Heavy-вариант получает 12 allocation units и не проходит budget 6. Reuse-вариант получает 3 units и проходит budget. Оба имеют 9 work units. Такое доказательство ещё не отвечает, какой код нужно менять в D. Оно только запрещает одновременно менять contract handler и считать, что уменьшение model units уже стало оптимизацией процесса.'),
dataTable(
'Как классифицировать наблюдение до исправления',
['Наблюдение','Что фактически есть','Вероятная граница','Первое безопасное действие'],
[
['heavy > budget','12 units при budget 6, body равен reuse','учебные временные состояния','сохранить два trace и проверить локальный reuse change при том же output'],
['есть <code>gc-boundary</code>','пересечён порог 8 units, поле <code>not-a-runtime-pause</code>','граница для будущего profiling','не объявлять pause; выбрать реальный метод измерения отдельно'],
['есть FFI/I/O boundary','<code>invocation: not-performed</code>','контракт внешнего вызова ещё не проверен','не обвинять зависимость; собрать owner, input/output и отдельный test'],
['validation-error','status 400 и <code>encode-error</code>','ошибка входа до compute','сохранить error input и не применять success-path оптимизацию как исправление'],
['result различается','success body не совпадает','нарушен contract handler','остановить локальную оптимизацию и вернуть равный результат прежде budget'],
],
),
heading('Читаем error route так же внимательно, как success'),
paragraph('Проверка только счастливого запроса всегда оставляет дыру. В fixture invalid operation <code>divide</code> декодируется, отвергается validation и проходит через <code>encode-error</code>. Он не доходит до compute, FFI или I/O. Это даёт ясную отрицательную проверку: изменение buffer reuse не должно заставить ошибочный вход исчезнуть, стать успехом или неожиданно пересечь external boundary.'),
codeBlock(diagnosisExample),
paragraph('Такой error trace нужен и при разборе возможного allocation growth. Если heavy-вариант создаёт дополнительные units до validation, а invalid request больше не виден, нельзя сказать «мы сократили pressure». Возможно, мы просто перестали обрабатывать некорректный вход тем же контрактом. Поэтому fixture одновременно проверяет same handler result для success, явный status 400 для error и отсутствие compute/FFI/I/O в отрицательной ветке.'),
heading('Отделяем условную GC-границу от причины паузы'),
paragraph('У записи <code>gc-boundary</code> ровно одно значение: заданный счётчик пересёк заданный порог. Эта запись полезна, потому что показывает место, где команда договорилась задать фактический вопрос. Она не говорит, был ли GC, как он работал, остановил ли потоки, сколько длилась пауза и связана ли она с request. Документация D описывает automatic memory management, но переход от общего механизма к конкретному симптому всегда требует tool output и условий запуска.'),
paragraph('Безопасный отчёт поэтому выглядит скромно: «в учебной модели 12 units пересекают budget 6; boundary помечена; фактического profile нет». Небезопасный отчёт добавляет к этому «из-за GC endpoint зависает». Второй текст звучит увереннее, но у него нет входа, версия, метод, график или trace реального процесса. Практическая работа начинается с первого текста: он позволяет назначить следующий эксперимент и не переписать систему по впечатлению.'),
'Диагностический маршрут для учебного request в D-сервисе: сначала сохранить result, error и trace; затем проверить равенство handler result, allocation budget, модельную GC-границу и неисполняемые FFI/I/O boundaries. При любом несоответствии выбрать обратимое локальное действие, а не менять runtime глобально.',
'Маршрут разделяет contract handler, учебный allocation budget и внешнюю границу. Ни одна карточка не называет model unit профилем или pause.',
),
heading('Rollback-safe действие: откатываем гипотезу, не evidence'),
paragraph('Если heavy и reuse возвращают один body, а отличается только model allocation, допустима маленькая обратимая правка: временное состояние в одном участке заменяется на повторное использование, а valid и invalid traces остаются рядом с change. Откат в таком случае — вернуть локальный путь и снова получить прежний trace. Нельзя называть rollback-safe глобальное отключение GC, смену allocator или переписывание foreign code без теста внешнего договора: такие действия расширяют границу и могут скрыть исходный симптом.'),
paragraph('Если body различается, error route исчезает или boundary стала выполнять внешний вызов, действие другое: остановить оптимизацию, сохранить samples и восстановить прежний contract handler. Здесь важнее не сделать «быстрый» patch, а не потерять смысл ошибки. После этого можно отдельно решать, нужна ли новая схема данных, другой API или реальное измерение. Смешивать этот разбор с одной настройкой runtime нельзя: разная причина требует разного owner и обратимости.'),
dataTable(
'Выбор обратимого действия',
['Подтверждённая ситуация','Что меняем','Что сохраняем','Чего не делаем'],
[
['равный output, heavy выше budget, reuse внутри','один локальный temporary path','оба valid trace, budget и same-result assertion','не объявляем оптимизацию production без profile'],
['условная GC boundary без real evidence','ничего в runtime','input, trace, версия будущего инструмента','не включаем/выключаем GC по модели'],
['FFI/I/O boundary подозрительна','отдельный contract test границы','intent, owner, expected error/result','не приписываем внешнему коду вызов, которого не было'],
['invalid input изменил маршрут','возвращаем validation/error contract','invalid sample и error trace','не сравниваем allocation до восстановления error route'],
['успешный body изменился','останавливаем локальную правку','expected body и diff result','не прячем разницу за новой версией response'],
],
),
heading('Источники обозначают границы, а не готовый диагноз'),
paragraph('Для терминов D я сверяю official language specification: automatic memory management, <code>@nogc</code> и ABI. Для исторической точки использован опубликованный до октября 2021 release D 2.097.2 и exact DRuntime source snapshot его тега. Ни один из этих источников не содержит profile данного request, потому что такого request не существовало. Поэтому они поддерживают только аккуратные утверждения о языке и границе ответственности.'),
paragraph('Такой подход особенно важен для FFI. ABI объясняет, почему граница не исчезает из архитектуры, но не описывает particular foreign function, её ownership или возможный blocking. Аналогично источник о GC помогает назвать механизм, но не превращает 12 учебных units в измеренную pause. Чем выше соблазн сделать вывод о реальной среде, тем важнее отдельно сохранить command, версию, вход, платформу и исходные results.'),
heading('Маршрут: симптом → причина → проверка → действие'),
orderedList([
'<strong>Симптом.</strong> Сохраните один success или error request вместе с result/body. Не исправляйте runtime до появления конкретного input.',
'<strong>Причина-гипотеза.</strong> Разделите contract, model allocation, model GC boundary, FFI boundary и I/O boundary. Одно наблюдение не обязано объяснять остальные.',
'<strong>Проверка результата.</strong> Сравните success body и status two variants; затем прогоните invalid input и убедитесь, что validation-error/encode-error сохранились.',
'<strong>Проверка бюджета.</strong> Если result одинаков, проверьте allocation units против явно записанного budget. Смотрите на GC entry только как на пометку модели.',
'<strong>Действие.</strong> При локальном budget difference меняйте один обратимый temporary path. При FFI/I/O выбирайте отдельный contract test. При разном result или error route сначала восстановите handler contract.',
'<strong>Проверка после действия.</strong> Повторите те же valid и invalid samples, сохраните traces и только затем назначьте реальный profiler с описанным окружением.',
]),
heading('Ограничения и следующий проверяемый шаг'),
paragraph('Полевой маршрут не даёт production SLA, benchmark result, замер паузы, масштабирование, rate, memory footprint, сведения о compiler flags или DRuntime configuration. Он не исполняет D, FFI, file, network, HTTP, database, process, GC или profiler. Условные units не имеют единицы времени и не должны попадать в dashboard как metric. Откат в таблице — образец безопасного порядка, а не команда для чужой инфраструктуры.'),
paragraph('Следующий проверяемый шаг для своего сервиса — написать один integration-level trace вокруг выбранного handler без чувствительных данных, сохранить valid и invalid inputs, а затем выбрать ровно одну реальную границу для измерения. Если trace показывает внешний вызов, сначала тестируем его договор. Если одновременно меняются result и units, возвращаем contract. Если остаётся один вопрос про allocation, тогда можно сравнить фактические данные в зафиксированной среде. Так расследование не обещает лишнего и оставляет путь к следующему доказательству.'),
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
