Здравствуйте, rudzuk, Вы писали:

R>Так и этот тоже не пустой. Там и GC и работата с DOM браузера.

Кстати в WebAssembly завезли GC
https://developer.chrome.com/blog/wasmgc?hl=ru

WasmGC — предложение группы сообщества WebAssembly . Текущая реализация Wasm MVP способна работать только с числами, то есть целыми числами и числами с плавающей запятой, в линейной памяти, а с учетом предложения ссылочных типов Wasm может дополнительно удерживать внешние ссылки. WasmGC теперь добавляет типы кучи структур и массивов, что означает поддержку нелинейного распределения памяти. Каждый объект WasmGC имеет фиксированный тип и структуру, что позволяет виртуальным машинам легко генерировать эффективный код для доступа к своим полям без риска деоптимизации , которая свойственна динамическим языкам, таким как JavaScript. Таким образом, это предложение добавляет в WebAssembly эффективную поддержку управляемых языков высокого уровня через типы кучи структур и массивов, которые позволяют компиляторам языков, ориентированным на Wasm, интегрироваться со сборщиком мусора в виртуальной машине хоста. Проще говоря, это означает, что с помощью WasmGC портирование языка программирования на Wasm означает, что сборщик мусора языка программирования больше не должен быть частью порта, а вместо этого можно использовать существующий сборщик мусора.

Чтобы проверить реальное влияние этого улучшения, команда Chrome Wasm скомпилировала версии теста Fannkuch (который выделяет структуры данных по мере их работы) из C , Rust и Java . Бинарные файлы C и Rust могут иметь размер от 6,1 до 9,6 КБ в зависимости от различных флагов компилятора, тогда как версия Java намного меньше — всего 2,3 КБ ! C и Rust не включают сборщик мусора, но они по-прежнему связывают malloc/free для управления памятью, и причина, по которой Java здесь меньше, заключается в том, что ей вообще не нужно связывать какой-либо код управления памятью. Это всего лишь один конкретный пример, но он показывает, что двоичные файлы WasmGC потенциально могут быть очень маленькими, и это еще до какой-либо значительной работы по оптимизации размера.

Здравствуйте, rudzuk, Вы писали:

R>Так и этот тоже не пустой. Там и GC и работата с DOM браузера.

Кстати в WebAssembly завезли GC
https://developer.chrome.com/blog/wasmgc?hl=ru

WasmGC — предложение группы сообщества WebAssembly . Текущая реализация Wasm MVP способна работать только с числами, то есть целыми числами и числами с плавающей запятой, в линейной памяти, а с учетом предложения ссылочных типов Wasm может дополнительно удерживать внешние ссылки. WasmGC теперь добавляет типы кучи структур и массивов, что означает поддержку нелинейного распределения памяти. Каждый объект WasmGC имеет фиксированный тип и структуру, что позволяет виртуальным машинам легко генерировать эффективный код для доступа к своим полям без риска деоптимизации , которая свойственна динамическим языкам, таким как JavaScript. Таким образом, это предложение добавляет в WebAssembly эффективную поддержку управляемых языков высокого уровня через типы кучи структур и массивов, которые позволяют компиляторам языков, ориентированным на Wasm, интегрироваться со сборщиком мусора в виртуальной машине хоста. Проще говоря, это означает, что с помощью WasmGC портирование языка программирования на Wasm означает, что сборщик мусора языка программирования больше не должен быть частью порта, а вместо этого можно использовать существующий сборщик мусора.

Чтобы проверить реальное влияние этого улучшения, команда Chrome Wasm скомпилировала версии теста Fannkuch (который выделяет структуры данных по мере их работы) из C , Rust и Java . Бинарные файлы C и Rust могут иметь размер от 6,1 до 9,6 КБ в зависимости от различных флагов компилятора, тогда как версия Java намного меньше — всего 2,3 КБ ! C и Rust не включают сборщик мусора, но они по-прежнему связывают malloc/free для управления памятью, и причина, по которой Java здесь меньше, заключается в том, что ей вообще не нужно связывать какой-либо код управления памятью. Это всего лишь один конкретный пример, но он показывает, что двоичные файлы WasmGC потенциально могут быть очень маленькими, и это еще до какой-либо значительной работы по оптимизации размера.

Проблемы в .Net [wasm][post-MVP] garbage collection proposal in .NET