API JavaScript Promise Integration (JSPI) позволяет приложениям WebAssembly, которые были написаны с расчётом на синхронный доступ к внешней функциональности, работать корректно в среде, где функциональность фактически является асинхронной.
В API интеграции JavaScript Promise (JSPI) WebAssembly появился новый API, доступный в Chrome версии M126. Мы расскажем, что изменилось, как использовать это с Emscripten, и как выглядит дорожная карта JSPI.
JSPI — это API, который позволяет приложениям WebAssembly, использующим последовательные API, обращаться к веб-API, которые являются асинхронными. Многие веб-API работают с объектами JavaScript Promise: вместо непосредственного выполнения запрашиваемой операции они возвращают Promise для выполнения. С другой стороны, многие приложения, скомпилированные в WebAssembly, приходят из мира C/C++, где доминируют API, блокирующие вызвавшего до завершения операции.
JavaScript Promise Integration (JSPI) API для WebAssembly входит в этап внутреннего тестирования с выпуском Chrome версии M123. Это означает, что вы можете протестировать, принесли ли вы и ваши пользователи пользу от этого нового API.
JSPI — это API, который позволяет так называемому последовательному коду, скомпилированному для WebAssembly, получать доступ к веб-API, которые являются асинхронными. Многие веб-API разработаны на основе JavaScript Promise: вместо немедленного выполнения запрашиваемой операции они возвращают Promise для ее выполнения. Когда действие наконец выполнено, планировщик задач браузера вызывает любые обратные вызовы с Promise. JSPI интегрируется в эту архитектуру, позволяя приложению WebAssembly приостанавливать выполнение при возврате Promise и возобновлять выполнение, когда Promise разрешается.
Добро пожаловать в захватывающий мир V8, где скорость — это не просто функция, а образ жизни. Наступил момент попрощаться с 2023 годом и отпраздновать впечатляющие достижения, которых V8 достиг в этом году.
Благодаря инновационным оптимизациям производительности V8 продолжает расширять границы возможного в постоянно меняющемся ландшафте Веба. Мы представили новый компилятор среднего уровня и реализовали множество улучшений в инфраструктуре компилятора высокого уровня, среде выполнения и сборщике мусора, что привело к значительному увеличению скорости работы.
Недавняя статья о WebAssembly Garbage Collection (WasmGC) на высоком уровне объясняет, как предложение по сборке мусора (GC) направлено на улучшение поддержки языков со сборкой мусора в Wasm, что крайне важно в свете их популярности. В этой статье мы углубимся в технические детали того, как такие языки, как Java, Kotlin, Dart, Python и C#, могут быть портированы в Wasm. По сути, существуют два основных подхода:
Мы внедряем вызовы хвостов WebAssembly в V8 v11.2! В этом посте мы кратко рассмотрим это предложение, покажем интересный пример использования копрограмм C++ с Emscripten и продемонстрируем, как V8 обрабатывает вызовы хвостов внутри.
Вызов считается находящимся в хвостовой позиции, если это последняя инструкция, выполняемая перед возвратом из текущей функции. Компиляторы могут оптимизировать такие вызовы, отбрасывая фрейм вызывающего и заменяя вызов на переход.
Это особенно полезно для рекурсивных функций. Например, рассмотрим эту C-функцию, которая суммирует элементы связного списка:
int sum(List* list, int acc) {
if (list == nullptr) return acc;
return sum(list->next, acc + list->val);
}
При обычном вызове это потребляет 𝒪(n) памяти стека: каждый элемент списка добавляет новый фрейм в стеке вызовов. С достаточно длинным списком это может быстро привести к переполнению стека. Заменяя вызов на переход, оптимизация хвостовых вызовов фактически превращает эту рекурсивную функцию в цикл, который использует 𝒪(1) памяти стека:
V8 имеет два компилятора для компиляции кода WebAssembly в машинный код, который затем можно выполнять: базовый компилятор Liftoff и оптимизирующий компилятор TurboFan. Liftoff может генерировать код гораздо быстрее, чем TurboFan, что позволяет добиться быстрого запуска. TurboFan, в свою очередь, может генерировать более быстрый код, обеспечивая высокую производительность.
Благодаря недавней работе в Chrome и Emscripten теперь вы можете использовать до 4 ГБ памяти в приложениях WebAssembly. Это больше предыдущего ограничения в 2 ГБ. Может показаться странным, что вообще было ограничение, ведь не требовалось никаких изменений, чтобы использовать 512 МБ или 1 ГБ памяти! - но оказывается, что в переходе от 2 ГБ к 4 ГБ происходят особенные вещи, как в браузере, так и в цепочке инструментов, о которых мы расскажем в этом посте.
У нас растет число компиляторов и других инструментов, которые генерируют или обрабатывают файлы .wasm, и иногда вам может захотеться посмотреть, что находится внутри. Возможно, вы разработчик такого инструмента, или, более непосредственно, программист, нацеленный на Wasm, и вам интересно, как выглядит сгенерированный код, например, с точки зрения производительности или по другим причинам.
Emscripten всегда был ориентирован в первую очередь на компиляцию для использования в Интернете и других средах JavaScript, таких как Node.js. Однако по мере того, как WebAssembly начинает использоваться без JavaScript, появляются новые варианты применения, и поэтому мы работаем над поддержкой генерации автономных файлов Wasm с помощью Emscripten, которые не зависят от JavaScript-рантайма Emscripten! Этот пост объясняет, почему это интересно.