Все странные вещи случаются, потому что вы не можете реально отслеживать распределение памяти WebAssembly (или Emscripten), используя системные инструменты движка JS.Другими словами, куча управляется пользовательским кодом WebAssembly, а не механизмом JS, таким как V8.
Возможно, вы захотите проверить мое объяснение памяти WebAssembly .WebAssembly имеет одну линейную область памяти, которая называется WebAssembly.Memory.На самом деле это один большой JS ArrayBuffer WebAssembly.Memory.buffer , который является единственной областью памяти (кроме стека), которую модуль WebAssembly может касаться по своему дизайну.Хотя WebAssembly не может касаться какой-либо памяти за пределами этого единственного ArrayBuffer, он может делать что угодно с этим буфером.Поэтому большинство двоичных файлов WebAssemlby используют буфер в качестве области кучи.
WebAssembly 1.0 не определяет какие-либо виды встроенной пользовательской библиотеки, включая управление памятью.Это означает, что каждый код C / C ++, скомпилированный в WebAssembly, должен иметь собственную реализацию malloc(), тогда как хост-система - механизм JS в этом контексте - не имеет представления о том, что происходит внутри кучи.
Поэтому независимо от того, сколько вы выделили и освободили кучу в вашем коде Emscripten, в перспективе V8 использование памяти останется стабильным, поскольку оно уже выделило весь ArrayBuffer и передало экземпляру Emscripten.
Единственное исключениечто экземпляр WebAssembly может запросить движок JS увеличить размер ArrayBuffer , так как ему требуется больше кучи, точно так же, как sbrk в контексте C / C ++.Таким образом, распределение ядра JS имеет тенденцию к увеличению, пока не достигнет максимального размера WebAssembly.Memory(), который вы (или автоматически сгенерированный код JS, выполненный Emscripten) задаете.