Впрочем, это реторический вопрос.

да, в данный момент все так

А зачем wasm-у gc? У каждого языка уже есть сборщик мусора который оптимизирован и заточен конкретно под этот язык. Почему бы не скомпилировать в wasm сам этот сборщик мусора вместе с другим рантаймом языка? Попытка создать общий gc для всех языков приведет к тому что этот gc будет неэффективным для отдельно взятого языка

to reduce the size of deployment

Потому что почти все GC сканируют стек, что в WASM просто невозможно.

Тогда почему бы комитету не решить этот недостаток и добавить возможность сканировать стек вместо того чтобы тащить gc?
Кстати даже если в wasm-а нет возможности просканировать стек то почему бы тогда не передавать аргументы между функциями явно записывая их в память (то есть получится собственный стек вместо встроенного) ?

Не обязательно. Так же как и корутины есть stackful и stackless. Разница собственно в том, что второй тип требует кодогенерации

Сканировать стек -- дыра в безопасности. Свой стек (shadow stack) -- медленно.

Ну я вот кроме рефкаунтинга не припоминаю кто НЕ сканирует. 🤷‍♀

Кроме того, большинство WASM рантаймов всё равно будут иметь свой GC в том или ином виде -- логично же прокинуть интерфейс к нему, раз уж он всё равно есть.

А почему свой стек - медленно? Понятно что в x64 уже есть встроенные инструкции для стека но я не понимаю почему это будет прям сильно медленно. Любое обращение в память всегда считывает всю кеш-линию (область памяти в 64 байта). Считал хотя бы один байт - получай в подарок практически бесплатное обращение к 64 близлежащим байтам. Поскольку стек это идеальная с точки зреня локальности структура ( последовательная запись или считывание) то даже кастомный стек будет работать быстро за счет этих кеш-линий

Кстати а почему возможность сканировать стек это дыра в безопасности? Я так понимаю речь про запись в стек а не считывание (например заменить ссылки на объекты когда gc переместит в другой регион), тогда согласен
Все равно неясно почему комитет webassembly так беспокоится про безопасность. Там ведь все равно будет изоляция и песочница от других сайтов. Все что может wasm-модуль так это навредить сам себе. Мне кажется задача обеспечивать безопасность относится не к рантайму а к  тому языку который компилируется в wasm, например memory-safe ссылки на объекты вместо явных указателей, статическая типизация и проверки и т.д

Wasm-у GC еще нужен чтоб с JS взаимодействовать. Если Wasm и JS будут использовать разные сборщики мусора, то сложно будет собирать мусор с циклами сслыок на границе Wasm и JS.

Еще кастомный сборщик мусора - это постоянный оверхед. Существующие сборщики мусора не рассчитаны оптимизацию размера их рантайма, их придется урезать и идти на компромиссы, и он может в итоге получится хуже чем в JS движках.

Как бонус, с Wasm GC языкам с безопасной моделью памяти будует нужно меньше проверок выхода за границу памяти

а как кстати делается проверка что ты не выходишь за границу памяти? неужто на каждое обращение к линейной памяти под капотом делается проверка?

Да

Тоже интересно, я предполагал, что компилятор старается статически убрать или сгруппировать ненужные проверки, вынести их из циклов и.т.п

По этому мне Макс сказал везде напихать unchecked в AS

Чтобы везде не прлверял.:)