Инженеры WebKit оптимизировали выделение памяти под массивы в JavaScriptCore. Речь про объекты JSArray: раньше при работе без глобальной блокировки (GIL-off) инлайн-аллокация в JIT для них не срабатывала — код шёл в медленный C++-обработчик operationNewArrayWithSize. Исправили это, введя per-type IsoSubspace TLC slot, который штампуется при создании GCClient::Heap, а tlcSlotForConcurrentlyWithIso() находит нужный индекс по типу. Но JSArray исключили из общей схемы — он возвращает nullopt, потому что JIT-функции inline allocateObject и emitAllocateJSArray записывают butterfly word без TID-тега. Из-за этого при первом же чтении длины (§4.2 ensureLength) свежий массив выглядит как чужой — происходит конвертация в сегментированную структуру. Замеры показали: 182 339 вызовов convertToSegmentedButterfly и 19 миллионов operationArrayPush суммарно давали +3472 мс налога.
Для JSArray сделали отдельный iso arm в JIT (§43) — он впервые включает инлайн-путь при GIL-off. Всё это пока завязано на Task-8: TID-тег должен ставиться при каждой JIT-инлайн-вставке butterfly. Для остальных типов с IsoSubspace (например, JSRopeString, JSString) проблема не стоит — у них либо нет butterfly, либо он всегда null.
Также внедрили Thin-thunk в FTL JIT: в steady state при GIL-off код делает acquire-load m_stubCodePtr прямо в JIT-коде и tail-jump, если указатель не null. Никаких saveAllRegisters/restoreAllRegisters и C-вызова. Если null — падает в обычный полный thunk. Результат: число вызовов operationCompileFTLLazySlowPath упало с 36,4 миллиона до 56 — минус 99,9998%.
Цифры производительности по §43: intcs W=1 улучшился с 7142 до 6381 (на 761 пункт), nomap W=1 упал на 1018, default W=1 — на 976. Суммарный налог по §42 + §43 сократился до 453 мс — это 76,3% от исходных 1912 мс. Потребление RSS: при W=1 снизилось на 2,3%, при W=16 — на 10,6%. Корпус тестов стабилен (94+95/0, identity 40/0, 34/34 checksums). Остаток — около 400–500 мс налога на JSArray iso-TLC, который упирается в Task-8.