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

тоесть если у тебя 100 разных линейных памятей, можно разным load инструкциям запрещать разные страницы?

Проблема с выделением памяти под все инстансы в 1 блоке GROW.
Если будет 2 модуля подряд, 1 решил себе 1гб выделить, придётся его двигать

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

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

так, надо тогда сразу определиться — в оргу добавляем всех желающих или активных участников =)