Design: Приоритет: сборщик мусора, интегрированный в JavaScript, или примитивы для реализации сборщика мусора в WASM.

Конечно, имеет смысл спроектировать функцию GC и цепочку инструментов так, чтобы она была необязательной и чтобы простые программы на C / C ++ / Rust не требовали этого. Возможный контрпример: использование ссылок на сборщик мусора позволило бы более эффективно интегрироваться с веб-API, но предположительно это было бы только в том случае, если бы веб-API использовался.

При этом, если вы хотите скомпилировать _is_ язык GC, есть несколько преимуществ интеграции с GC среды хоста по сравнению с выполнением всего этого с линейной памятью:

• циклы, которые проходят между объектами wasm и объектом среды хоста (например, DOM), могут быть собраны GC среды хоста, но не GC в линейной памяти; вы получите сильное преимущество, которое укоренило бы коллекционируемый цикл
• GC среды хоста интегрированы с такими вещами, как requestAnimationFrame и vsync, что позволяет им, например, настраивать инкрементные срезы GC так, чтобы они заканчивались, когда пришло время начинать следующий кадр.
• меньшая внутренняя фрагментация за счет безопасного повторного использования арен сборки мусора между тем, что в противном случае было бы непересекающейся вашей линейной памятью; особенно важно для 32-битных систем с ограниченным виртуальным адресным пространством
• лучшая интеграция с браузером, так как инструменты разработчика лучше понимают объекты сборки мусора.
• меньшая распространяемая среда выполнения за счет повторного использования того, что уже есть в браузере

И я думаю, что это оправдывает работу по интеграции GC в wasm.

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

Да, это причины, по которым люди все еще могут захотеть реализовать свой собственный сборщик мусора с использованием линейной памяти, и добавление поддержки сборщика мусора в wasm не должно помешать им в этом.

Да, прямо сейчас возможно реализовать сборщик мусора в wasm, но было бы намного практичнее, если бы существовал способ сканирования ссылок на сборщик мусора в локальных и промежуточных элементах. Это очень полезная функция, которая является подмножеством функций, необходимых для определяемого хостом GC, но AFAICT нигде не упоминается в репозитории проекта.

Меня беспокоит, что GC, определяемый хостом, не в том, что он технически предотвратит использование более общих строительных блоков GC, а в том, что:

• Он может легко стать необходимой функцией виртуальной машины за счет использования популярных инструментальных средств.
• И это можно рассматривать как "достаточно", поэтому усилия по поддержке эффективных реализаций сборки мусора в wasm блокируются.

лучшая интеграция с браузером, так как инструменты разработчика лучше понимают объекты сборки мусора.

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

Я согласен с тем, что некоторый объем проверки стека по подписке / оплате по мере использования был бы в целом полезной функцией для wasm, и мы должны добавить что-то подобное в ближайшее время.

Я думаю, что вы хорошо замечаете инструментальную цепочку, но я думаю, что мы можем принять это как высокоуровневую цель, заключающуюся в том, чтобы избежать жесткой зависимости от GC для источников, не связанных с GC. Я думаю, что это хорошая идея даже в Интернете, потому что я думаю, что должно быть возможно создать рабочий процесс wasm-without-GC-only, который не имеет обычной GC-heap, выделенной для него.

Если к локальным переменным и стеку значений можно получить доступ из любого места в их динамической области, то может ли это сделать недействительными некоторые предположения, неявные при декодировании в форму SSA? Возможно, нужно еще подумать над вариантами здесь, и, возможно, это даже повлияет на дизайн языка.

Один из вариантов заключается в том, что производитель wasm-кода просто не хранит указатели, которые необходимо очистить, в стеке значений или в локальных переменных в точках, которые могут вызвать сборку мусора, а не в линейной памяти. Таким образом, стек локальных переменных и значений может по-прежнему хорошо ограничиваться лексической областью видимости.

Может ли помочь, если бы локальные переменные и стек значений можно было только читать, а не записывать за пределами их лексической области видимости? На первый взгляд, этого может быть достаточно ограничения, чтобы не повлиять на декодер SSA? Это поддержит консервативный сборщик значений в локальных переменных и стеке значений, но не точный сборщик мусора, который хочет перемещать объекты с указателями из локальных переменных или стека значений.

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

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

Было бы интересно узнать мнение о влиянии разрешения только чтения локальных переменных и стека значений из любого динамического контекста, а не записи в них, и повлияет ли это на декодеры SSA?

Допустим, можно разрешить чтение любой локальной переменной и стека значений из их динамического контекста, тогда кажется, что предложение get_value (которое является статической ссылкой в ​​стеке) тоже должно подойти? Тогда модель будет заключаться в том, что стек значений имеет значения только для чтения, которые имеют динамическую область видимости, а локальные переменные имеют значения, которые могут быть прочитаны в их динамической области видимости, но записаны только в их лексической области видимости.

Влияет ли какая-либо из этих проблем на обсуждаемый вариант wasm-GC? Разве у этого не было бы некоторых из этих проблем, возможного расстраивающего декодирования SSA, если бы указатели GC в локальных переменных или стек значений могли быть записаны из любого динамического контекста?

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

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

Если к локальным переменным и стеку значений можно получить доступ из любого места в их динамической области, то может ли это сделать недействительными некоторые предположения, неявные при декодировании в форму SSA? Возможно, нужно еще подумать над вариантами здесь, и, возможно, это даже повлияет на дизайн языка.

Я думаю, вы наблюдаете недетерминизм реализации во времени жизни локальных переменных и промежуточных значений. Это правильно?

Я думаю, что необходимо добавить что-то вроде внутренней точки состояния LLVM GC: вызов, который дополнительно принимает набор местоположений стека значений и локальных переменных, которые могут быть изменены вызовом. Это позволяет сериализовать мутации локального состояния с помощью вызова, без пессимистического предположения, что все должно быть сериализовано с помощью вызова.

Помимо локального состояния, явно сериализованного с помощью этого вызова с поддержкой GC, может быть полезно разрешить проверке стека наблюдать недетерминизм в форме других живых локальных переменных и промежуточных значений.

Может ли помочь, если бы локальные переменные и стек значений можно было только читать, а не записывать за пределами их лексической области видимости? На первый взгляд, этого может быть достаточно ограничения, чтобы не повлиять на декодер SSA? Это поддержит консервативный сборщик значений в локальных переменных и стеке значений, но не точный сборщик мусора, который хочет перемещать объекты с указателями из локальных переменных или стека значений.

ИМО цель должна быть точной, уплотняющей GC.

Не сразу очевидно, что можно было бы получить, разрешив определение стека значений и местоположений локальных переменных, которые могут быть изменены при вызове. Практически их нужно было бы записать обратно в память и повторно загрузить, и это могло бы быть сделано явно производителем, просто сохранив их в линейной памяти, которая уже поддерживается. Зачем усложнять, если в этом нет необходимости.

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

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

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

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

Это определенно сложно реализовать. Однако обработка исключений с нулевой стоимостью уже включена в план развития

Для декодера SSA все еще могут быть проблемы, если состояние может быть изменено за пределами лексической области.

Вы можете закодировать возможность этой мутации в SSA следующим образом:

%gcRef0 = ... ; The initial value of gcRef.
%gcStatepoint = call ... gcstate=[%gcRef0...]
%gcRef1 = gcmutate %gcStatepoint 0 ; The new, possibly mutated value of gcRef after the GC statepoint
%result = gcresult %gcStatepoint   ; The result of the function called by the GC statepoint

@ lars-t-hansen Виртуальной машине нужна только песочница для памяти, поэтому язык, реализующий свою собственную объектную систему (и возможную маркировку указателей), не всегда должен быть типобезопасным и не должен защищать идентичность своих указателей. Принимая во внимание, что непрозрачные указатели GC всегда должны быть безопасными для защиты песочницы, и вы упоминаете, что не хотите предоставлять значение указателя коду, запущенному в виртуальной машине. Кроме того, управление памятью часто может реализовать эту песочницу с небольшими затратами, а оборудование может даже добавлять функции для лучшей поддержки песочницы с управляемой памятью в будущем. Таким образом, код, реализующий собственную кучу объектов в песочнице, может обеспечить лучшую производительность и небольшую нагрузку на виртуальную машину.

Например, рассмотрим список (связанный список cons-ячеек), в котором каждый элемент представляет собой помеченное маленькое целое число (например, ваши помеченные целые числа) и код, который добавляет все элементы списка. Производитель может воспользоваться объявлением, что это маленькие целые числа и что сумма не превышает маленькое целое число, и просто загрузить и добавить их в одной инструкции на x86. Я не понимаю, как язык, ориентированный на выделенные объекты gc-heap, может приблизиться к такому уровню производительности.

Например, с пометкой указателя указатель на cons-ячейку может иметь помеченный тип, который позволяет cons-ячейке использовать только два слова памяти. Я не понимаю, как объектная система, выделенная gc-heap, может приблизиться к такому уровню эффективности памяти.

Я хотел бы видеть программное обеспечение для символьной математики, такое как maxima, написанное на лиспе, эффективно работающее в сети, это кажется справедливым вариантом использования.

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

Чтобы повысить адаптивность в постоянно меняющейся среде, важно раскрывать только исходные аппаратные возможности и не заставлять людей иметь GC.

Я считаю, что для команды лучше всего создать отдельную независимую группу, имеющую только одну конкретную цель: построить GC с открытым исходным кодом поверх Wasm.

..Это позволяет любому [включая разработчиков браузеров] легко получить возможности сборки мусора, когда - если они им нужны. В то же время, тяжелые программы реального времени, которым требуется, чтобы сборщик мусора оставался в стороне, могут иметь именно это.

Мне нравится эта цитата Алана Кея:

Когда появился C ++, они попытались обслужить программистов на C и создали систему, которая не была ни рыбой, ни птицей.

Делайте в сети правильные люди. Сделай это правильно на этот раз, или нас снова назовут любителями.

@Pacerier , наличие GC в Wasm не повлияет на код, который его не использует. В частности, куча с GC будет полностью отделена от линейной памяти. По сути, все, что будет новым, - это то, что коду Wasm в той или иной форме предоставляется доступ к существующей куче JavaScript. Так что никого ни к чему не принуждают.

Будет чрезвычайно сложно реализовать сборщик мусора с конкурентоспособной производительностью _ на вершине_ Wasm, потому что это тип кода, на который больше всего влияют ограничения безопасности. Это также невероятный объем работы, чтобы стать правильным и эффективным. В то же время это механизм, который нужен практически каждому высокоуровневому языку, поэтому было бы плохим сервисом для веб-платформы, если бы всем пришлось повторить тяжелую работу, которая уже была проделана в браузерах.

Справедливости ради следует отметить, что с GC на платформе не-веб-реализации wasm могут быть вынуждены реализовать GC, который в противном случае мог бы не понадобиться. Все реализации wasm на основе браузера обязательно будут использовать свой сборщик мусора с JS, но, как вы заметили, это добавляет невероятный объем дополнительной работы к реализациям, не относящимся к Web.

Справедливо. Возможно, спецификация будущего Wasm с GC могла бы определить подъязык без GC, которым реализации могут ограничиться.

Некоторым не-веб-платформам будет проще. Например, реализации WASM на основе .NET или Java также имеют легко доступную сборку мусора.

Я согласен с концепцией подъязыка без сборщика мусора, это обеспечивает «уровень функций», на который библиотеки WASM могут ориентироваться для поддержки более широкого спектра платформ, при этом предоставляя полезные возможности для таких сложных, как веб-браузеры. Этот подход может быть применен и к различным другим предложениям.

Я не против расширения GC, определяемого реализацией. Я бы, наверное, даже поддержал его в WAVM, хотя и не с «конкурентоспособной производительностью». Я доволен высокоуровневой целью, которую Люк предложил выше: «избежать жесткой зависимости от GC для источников, не являющихся по своей сути GC».

Что меня беспокоит, так это то, что не будет стандартного расширения, позволяющего программе WASM эффективно собирать мусор линейной памяти, и что поставщики браузеров могут не поддерживать такое расширение, даже если они по какой-либо причине разрешили его стандартизировать.

Я не думаю, что продуктивно спорить о том, должен ли язык реализовывать собственный сборщик мусора поверх WASM. Первая цель WASM - создать «цель компиляции, которая может быть скомпилирована для выполнения на собственной скорости, используя преимущества общих аппаратных возможностей, доступных на широком спектре платформ», поэтому я думаю, что WASM должен попробовать для предоставления общих аппаратных возможностей, доступных машинному коду на широком спектре платформ: для проверки и изменения стека и регистрации состояния.

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

@sunfishcode У меня в

Если нам это удастся, то вполне логично, что некоторые реализации WASM просто откажутся от реализации расширения WASM для управляемых данных.

Что касается GC поверх WASM, поскольку это уровень над механизмом выполнения, я не вижу причин, по которым он не может быть построен поверх WASM без какой-либо явной поддержки. Фактически, проекты по этому поводу уже реализуются. Я не рассматриваю стандартизированный сборщик мусора поверх WASM как цель основного проекта WASM, но рассматриваю его в той же категории, что и соглашения об инструментах.

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

Что касается GC поверх WASM, поскольку это уровень над механизмом выполнения, я не вижу причин, по которым он не может быть построен поверх WASM без какой-либо явной поддержки. Фактически, проекты по этому поводу уже реализуются. Я не рассматриваю стандартизированный сборщик мусора поверх WASM как цель основного проекта WASM, но рассматриваю его в той же категории, что и соглашения об инструментах.

Возможно, но не очень эффективно, реализовать линейный сборщик мусора памяти в WASM; В WASM отсутствует способ поиска / изменения ссылок в стеке вызовов или в регистрах, поэтому вам придется проливать все ссылки на линейную память между вызовами.

Я хочу не стандартизировать некоторый линейный сборщик мусора, а стандартизировать некоторое расширение нижнего уровня, которое обеспечивает безопасный и переносимый способ поиска, чтения и записи адресов в стеке. Потребуются операторы расширенного вызова, которые принимают некоторые дополнительные операнды и переназначают их с помощью любой операции «карты стека», которая может произойти во время вызова. Также потребуются операторы для чтения и записи ссылок, которые были «отображены» этими операторами расширенного вызова в стеке текущего потока. Самого по себе этого недостаточно, чтобы соответствовать производительности собственной реализации GC, но это немного сократит разрыв.

@AndrewScheidecker Да, я думаю, что что-то подобное - разумная функция, которую стоит добавить, и она также могла бы быть в целом полезной; недавно мы говорили о том, как можно реализовать фильтры Windows SEH, и iirc им это тоже нужно.

@ Россберг-хром, re:

наличие GC в Wasm не повлияет на код, который его не использует.

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

@ Россберг-хром, re:

Так что никого ни к чему не принуждают.

.. Вы все еще упускаете суть. Дело в том, что слабая связь . Поскольку нет взаимосвязанных проблем, многоуровневый подход лучше.

@ Россберг-хром, re:

Будет чрезвычайно сложно реализовать сборщик мусора с конкурентоспособной производительностью поверх Wasm, потому что это вид кода, на который больше всего влияют ограничения безопасности. Это также невероятный объем работы, чтобы стать правильным и эффективным. В то же время это механизм, который нужен практически каждому высокоуровневому языку, поэтому было бы плохим сервисом для веб-платформы, если бы всем пришлось повторить тяжелую работу, которая уже была проделана в браузерах.

..Это будет сделано «с открытым исходным кодом»: например, jquery - это всего лишь одна библиотека, которую используют миллионы команд. Нет причин, по которым небольшие магазины кода должны сами писать jquery, когда в крупных компаниях есть специальные группы, работающие над совершенствованием этого проекта с открытым исходным кодом.

@ Россберг-хром, re:

В то же время это механизм, который нужен практически каждому языку высокого уровня.

..Ни за что. А как насчет C?

На самом деле, разработчики игр и других приложений, чувствительных ко времени, которые случайно не могут позволить себе роскошь использовать C, всегда в конечном итоге ненавидят GC, с которым у них не было другого выбора, кроме как иметь дело .

@AndrewScheidecker , re:

Что меня беспокоит, так это то, что не будет стандартного расширения, позволяющего программе WASM эффективно собирать мусор линейной памяти.

..Это даже невозможно, потому что, пока программисту доступны все возможности оборудования, все можно сделать. В самом деле, если это не так, это просто означает, что открытый уровень слишком высокоуровневый, и меньшее подмножество, расположенное ближе к оборудованию, является правильным уровнем для нацеливания.

Я полагаю, этот стандарт рассчитывает закрепиться в сети как минимум на 2 или 3 десятилетия? Затем нацельтесь на необработанный аппаратный уровень и придерживайтесь его. Все остальное, что находится выше аппаратного уровня, должно обрабатываться «другими командами». Одна команда, одна забота.

В конце концов, все сводится к простому вопросу: есть ли в этом столетии оборудование, на котором есть инструкция по сборке мусора? Громкое «Нет». Когда он был создан, и только после этого , мы можем расширить стандарт, добавив GC в ядро.

Даже если он будет добавлен как дополнительное расширение, реализация WebAssembly без него станет бессмысленной, если Emscripten использует его. У меня уже есть проблемы с запуском скомпилированных двоичных файлов Emscripten в WAVM из-за связи его среды выполнения C с его жгутом JavaScript. Если этот интерфейс начинает использовать ссылки на сборщик мусора, мне нужно будет добавить сборщик мусора в мою автономную виртуальную машину WebAssembly.

^ Это x1000

Именно так работает « Принятие», «Расширение» и «Погашение» . Я не говорю, что предложение GC намеренно построено по образцу Microsoft, я просто указываю на неизбежный эффект, возникающий в результате непреднамеренного следования их образцу:

1. В настоящее время все WASM могут быть размещены _ везде_
2. Мы добавляем опцию GC для программ WASM («но это _только__ расширение!»)
3. Среды выполнения без GC теперь стоят перед выбором: внедрить GC или не иметь возможности разместить все WASM
4. Конечный результат: WASM больше нельзя размещать везде

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

Я понимаю практическую сторону: сейчас самый большой рынок для WASM - это Интернет. Я имею в виду, что это называется _Web_ Assembly.

Но всем, пожалуйста, помните, что это не только для интернет-браузеров. Прямо сейчас я могу встроить произвольный ненадежный двоичный файл WASM в программу Rust без ущерба для безопасности. И любой может создать этот WASM с помощью LLVM. Это замечательно. Я бы не хотел усложнять это. И кто знает, как будет выглядеть Интернет через 20 лет. И давайте не будем забывать, что сооснователь Docker сказал о WASM + WASI :

Недостающим звеном был стандартизованный интерфейс системы.

Он не сказал, что «расширение языка было недостающим звеном».

Если мы хотим, чтобы программы WASM имели высококачественные GC, давайте инкапсулируем GC и позволим программам WASM запускать их сами (как в примере jQuery

И если мы хотим более тесной интеграции с хостом GC, создайте для него нормальный интерфейс.

При этом, если вы хотите скомпилировать _is_ язык GC, есть несколько преимуществ интеграции с GC среды хоста по сравнению с выполнением всего этого с линейной памятью:

• циклы, которые проходят между объектами wasm и объектом среды хоста (например, DOM), могут быть собраны GC среды хоста, но не GC в линейной памяти; вы получите сильное преимущество, которое укоренило бы коллекционируемый цикл

Я считаю, что это был бы конкретный пример такого цикла: хост и программа WASM работают вместе, чтобы создать круговой связанный список. Один узел живет в хосте, другой - в программе WASM, и каждый узел указывает на другой узел. Ни одна из сторон не может собрать свой узел, не повредив ссылку другой стороны.

Но для меня это сигнализирует о проблеме с реализацией ссылок.

Ссылка на языке GC должна отслеживаться GC независимо от того, куда идет ссылка. Вы не можете дать ссылку на объект C # функции C, потому что сборщик мусора C # не может добраться до земли C и возиться с ней. Вы можете извлечь адрес памяти из этой ссылки и передать это число, но это не гарантирует, что адрес памяти будет иметь смысл позже, если вы сначала не укажете сборщику мусора C # закрепить этот объект. Как только вы это сделаете, функция C сможет последовательно делать значимые вещи с этим числом. Обе стороны довольны.

Означает ли тот факт, что в C # есть сборщик мусора, он требует, чтобы каждая другая программа, которую он вызывает, также имела сборщик мусора? Нет. Вместо этого в C # есть явные элементы управления для закрепления / рутирования, которые позволяют согласованно управлять программами.

Ссылка в Rust дает гарантии, которые часто невозможно поддерживать вне Rust. Право собственности, время жизни и изменчивость могут быть нарушены, если вы извлечете адрес памяти и выбросите это число через стену.

Означает ли тот факт, что в Rust есть система владения, каждая иностранная функция должна иметь систему владения? Нет. Вместо этого разработчики API очень осторожны при создании фреймворка, а обертки Rust для сторонних функций требуют много внимания.

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

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

Если хост хочет перетасовать память под ногами программы WASM, тогда создайте интерфейс (обычными средствами), который передает это намерение и концепцию.

Кроме того, интересно, что обычно не очень полезно задаться вопросом, как сделать ссылочные графы в бэкенде C # более совместимыми с ссылочными графами во фронтенде пользовательского интерфейса Flutter. Есть граница процесса, которую люди терпят (даже в которой нуждаются), и есть рамки и шаблоны для пересечения этой границы.

• GC среды хоста интегрированы с такими вещами, как requestAnimationFrame и vsync, что позволяет им, например, настраивать инкрементные срезы GC так, чтобы они заканчивались, когда пришло время начинать следующий кадр.

Я думаю, что для GC, размещенных в WASM, это можно решить обычными средствами, такими как вызовы функций и общее состояние.

Не говоря уже о том, что здесь делается (большое) предположение, что главный сборщик мусора будет делать именно то, что хочет программист WASM.

• меньшая внутренняя фрагментация за счет безопасного повторного использования арен сборки мусора между тем, что в противном случае было бы непересекающейся вашей линейной памятью; особенно важно для 32-битных систем с ограниченным виртуальным адресным пространством

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

• лучшая интеграция с браузером, так как инструменты разработчика лучше понимают объекты сборки мусора.

Я не думаю, что это очень сильный аргумент. Инструменты обязательно отстают от языков, а также инструменты не статичны. Так что я не поклонник изменения языкового дизайна в соответствии с текущими инструментами. Devtools можно заставить понимать что угодно.

• меньшая распространяемая среда выполнения за счет повторного использования того, что уже есть в браузере

Я думаю, что кеширование файлов в браузере и связывание модулей решат эту проблему. Опять же, подумайте о jQuery.