Ограничения памяти в webassembly

какова будет политика ограничений выделения памяти для программ webassembly?

будут ли унаследованы текущие (жесткие) ограничения памяти движка javascript? Е. Г. можно будет писать реальные приложения, которые нужно больше, чем несколько сотен мегабайт памяти?

текущие политики браузера по распределению памяти на javascript создают жесткие ограничения на то, что на самом деле выполнимо в браузере. Скорость больше не проблема с emscripten / asm.JS и JIT-компиляцию, но ограничения памяти делают трудным или невозможным создание любого серьезного приложения в браузере.

см., например,http://www.meshlabjs.net, версия запуска в браузере системы обработки сетки MeshLab. Что касается настольного приложения, то основным ограничением является то, что в версии на основе javascript большие 3D-модели не могут быть загружены для внутренних ограничений на выделение, наложенных JS-движком браузеров.

6
browser memory webassembly

2 ответов

WebAssembly имеет WebAssembly.Memory объект и двоичный файл имеет раздел памяти. Через них разработчик предоставляет обоснованные догадки о минимальном и максимальном использовании памяти, затем виртуальная машина выделяет минимум (или терпит неудачу). Затем разработчик может во время выполнения запросить больше через grow_memory какие инструменты, такие как Emscripten будет использовать под капотом malloc (Они похожи на sbrk).

для asm.Яш трудно знать, как ArrayBuffer собирался использоваться, и на некоторых 32-битных платформах вы часто сталкивались с фрагментацией процесса, что затрудняло выделение достаточного смежного пространства в виртуальной памяти процесса (ArrayBuffer должны быть непрерывным в виртуальном адресном пространстве процесса браузера, иначе у вас был бы огромный удар perf). Вы попытаетесь выделить 256MiB, а иногда и с трудом. Это было очень трудно, если браузер не был мульти-процесс, потому что все остальные вкладки конкурирующих для 32-битного виртуального адресного пространства. Браузеры были немного глупы несколько лет назад, они стали лучше, но 32 бита не так много, чтобы пойти вокруг.

WebAssembly поддерживается WebAssembly.Memory который является особым типом ArrayBuffer. Это означает, что реализация WebAssembly может быть умной об этом ArrayBuffer. На 32-битном не так много делать: если у вас заканчивается непрерывное адресное пространство, то виртуальная машина не может много сделать. Но на 64-битных платформах есть много адресного пространства. Броузер реализация может помешать вам создать слишком много WebAssembly.Memory экземпляры (выделение виртуальной памяти -почти бесплатно, но не совсем), но вы должны иметь возможность получить несколько распределений 4GiB. Обратите внимание, что браузер будет выделять это пространство только виртуально и фиксировать физические адреса для минимального количества страниц, которое вам нужно. После этого он будет выделять только физически, когда вы используете grow_memory. Это может потерпеть неудачу (физическая память примерно так же обильна, как и объем ОЗУ, дайте или возьмите пространство подкачки), но это много более предсказуемой.

реализация может вытащить аналогичный трюк на 32-битных платформах (over-commit, но keep PROT_NONE и физически не выделяется), предполагая, что фрагментация позволяет, но это зависит от реализации и того, как это влияет на ASLR. На самом деле трудно найти память, когда вокруг не так много, но практически и физически.

WebAssembly в настоящее время указан как ILP32 процесс: указатели 32 бита. Поэтому вы жестко ограничены 4GiB. Мы можем добавить wasm64 в будущем.

7

я суммирую немного выше ответы, комментарии и немного больше гуглить вокруг; есть две проблемы, которые мешают использовать WebAssembly для используемых проектов, которые требуют значительного объема памяти:

  • текущие реализации WebAssembly следуют 32-битной модели адресного пространства, поэтому нет надежды использовать более 4 ГБ памяти до wasm64 выходит.
  • браузеры произвольно решают, какой объем памяти предоставляется странице. Это (в основном) по соображениям безопасности, потому что люди любят думать о веб-страницах как о чем-то более "безопасном", чем настольные приложения.

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

0