6 записей с тегом "инструменты"

Этот блог-пост подготовлен Хосе Дапена Пазом (Igalia) при содействии Джейсона Уильямса (Bloomberg), Эшли Клеймора (Bloomberg), Роба Пальмера (Bloomberg), Джойи Чюн (Igalia) и Шу-Юй Гуо (Google).

В этом посте о снимках кучи V8 я расскажу о некоторых проблемах производительности, обнаруженных инженерами Bloomberg, и о том, как мы их решили, чтобы сделать анализ памяти JavaScript быстрее, чем когда-либо.

Проблема​

Инженеры Bloomberg работали над диагностикой утечки памяти в JavaScript-приложении. Оно завершалось с ошибками Out-Of-Memory. Для тестируемого приложения предел кучи V8 был настроен примерно на 1400 МБ. Обычно сборщик мусора V8 должен быть способен удерживать использование кучи ниже этого предела, поэтому сбои указывали на вероятную утечку.

Последние три месяца были для меня потрясающим опытом обучения, так как я присоединилась к команде V8 (Google London) в качестве стажера и работала над новым инструментом под названием Indicium.

Этот системный анализатор представляет собой унифицированный веб-интерфейс для трассировки, отладки и анализа шаблонов создания и модификации Inline Caches (ICs) и карт (Maps) в реальных приложениях.

В V8 уже существует инфраструктура трассировки для ICs и карт (Maps), которая может обрабатывать и анализировать события IC с помощью IC Explorer и события карт с помощью Map Processor. Однако предыдущие инструменты не позволяли анализировать карты и ICs комплексно, что теперь возможно с системным анализатором.

Введение​

Благодаря недавней работе в Chrome и Emscripten теперь вы можете использовать до 4 ГБ памяти в приложениях WebAssembly. Это больше предыдущего ограничения в 2 ГБ. Может показаться странным, что вообще было ограничение, ведь не требовалось никаких изменений, чтобы использовать 512 МБ или 1 ГБ памяти! - но оказывается, что в переходе от 2 ГБ к 4 ГБ происходят особенные вещи, как в браузере, так и в цепочке инструментов, о которых мы расскажем в этом посте.

У нас растет число компиляторов и других инструментов, которые генерируют или обрабатывают файлы .wasm, и иногда вам может захотеться посмотреть, что находится внутри. Возможно, вы разработчик такого инструмента, или, более непосредственно, программист, нацеленный на Wasm, и вам интересно, как выглядит сгенерированный код, например, с точки зрения производительности или по другим причинам.

Emscripten всегда был ориентирован в первую очередь на компиляцию для использования в Интернете и других средах JavaScript, таких как Node.js. Однако по мере того, как WebAssembly начинает использоваться без JavaScript, появляются новые варианты применения, и поэтому мы работаем над поддержкой генерации автономных файлов Wasm с помощью Emscripten, которые не зависят от JavaScript-рантайма Emscripten! Этот пост объясняет, почему это интересно.

WebAssembly обычно компилируется из исходного языка, что означает, что разработчикам нужны инструменты для его использования. По этой причине команда V8 работает над соответствующими open-source проектами, такими как LLVM, Emscripten, Binaryen и WABT. В этом посте описана часть работы, которая выполнена над Emscripten и LLVM, и которая скоро позволит Emscripten по умолчанию перейти на LLVM WebAssembly backend — пожалуйста, протестируйте его и сообщите о любых проблемах!