Уничтожить экземпляр WebAssembly?

Я создаю игровую площадку/«скрипку» для 3D-движок, написанный на Go — вы можете написать код Go в браузере, скомпилировать его в веб-сборку и запустить. Все работает, за исключением того, что каждый раз, когда выполняется фрагмент и создается новый экземпляр WebAsssembly, используемая память увеличивается, поскольку предыдущие экземпляры все еще работают. Запуск фрагмента несколько раз приводит к сбою страницы из-за ограничения памяти WASM (4 ГБ). Я не могу полагаться на автора фрагмента, чтобы убедиться, что его программа завершится, и в большинстве случаев программы не завершатся, потому что у них есть цикл рендеринга.

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

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

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

@Kaiido, верно, я думаю, что завершение убивает весь рабочий процесс, так что это должно освободить все ресурсы, удерживаемые им. Но я не уверен, что ОП использует рабочих, поскольку они упоминают, что это цикл рендеринга. OTOH, я не понимаю, как какой-либо Wasm может работать в фоновом режиме, не будучи рабочим. Возможно, требуется дополнительная информация. Я подозреваю, что реальная проблема может быть связана со средой выполнения Go и ее реализацией облегченной многопоточности.

После некоторой обрезки я выяснил, какой именно код Go вызывает зависание памяти. Это когда я регистрирую обратный вызов requestAnimationFrame. Если я вызову os.Exit(1) до этого, вся память WASM будет освобождена, но если я позвоню позже, он зависнет. Движок JS должен хранить внутреннюю ссылку на функцию WASM, которую я не могу удалить, не зная requestID, выданного при ее регистрации.

Я не знаю, как Go реализует os.Exit в браузере или как вы регистрируете обратный вызов из Go, но у меня есть сильное подозрение, что виновником является среда выполнения Go.

Что, если вы хотите. восстанавливать экземпляр Wasm каждый раз, когда вы меняете размер экрана? Действительно ли сборка мусора сработает в нужное время?

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

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