Динамический линкер Redox кэширует исполняемые файлы — инициализация GCC вдвое быстрее

Динамический линкер relibc научился хранить уже загруженные исполняемые файлы в сегменте общей памяти. При повторном запуске программа берётся из кэша, и инициализация GCC на Redox сокращается примерно вдвое.

Откуда берётся время запуска

Даже программа, ничего не делающая, при старте проходит путь: ядро загружает ELF-файл, разбирает сегменты, настраивает память, динамический линкер связывает символы, libc инициализируется, конструкторы и обработчики регистрируются, main наконец вызывается. Всё это — время до первого полезного действия программы.

Пока файлы читались с диска при каждом запуске, повторный старт одной и той же программы снова и снова платил за чтение и разбор. В компиляторе это заметно особенно остро: он запускается часто и работает с большим числом объектных файлов.

Как устроен кэш

При второй загрузке того же исполняемого файла линкер берёт содержимое не с диска, а из сегмента общей памяти, который сам же и заполнил при первой загрузке. То есть идея простая: не перечитывать то, что уже разобрано.

Второй коммит того же дня реализует исполнение из этого кэша — то есть не только хранение, но и использование содержимого при старте.

Заявленный эффект: в контролируемых условиях инициализация GCC сокращается на 50 процентов.

Что дальше

Авторы планируют перенести кэш в службу файловой системы RedoxFS. Тогда им будет управлять владелец файловой таблицы: это и быстрее (уже свой код разбора), и безопаснее — доступ к кэшу контролируется на уровне схемы, а не отдельной подсистемы линкера.

Оригинал

Коммит Implement ld_so cache backed by shm от 29 марта 2026 года в репозитории redox-os/relibc; рядом Implement exec cache from ld_so cache. Сводка «This Month in Redox — March 2026», раздел «Dynamic Linker Storage Cache»