самое главное не делать предположения что все что от __heap_base до memory.size во владении этого аллокатора ))

дада

не обязательно его запоминать

ну разницу точнее, чтобы запомнить

потому что разница - это количество доступного места

есть два случая:

1. __heap_base до __heap_base.round_up_one_page()
2. это новую страницу

ее можно высчитать всегда по heap_base

ну да, можно сделать как ты сказал, но лучше сразу несколько васм страниц выделить

да можно и так. Тут уже хозяин барин

т.е. я бы сделал алгоритм инстанцирования памяти нового модуля примерно так:
1. Выставляем heap_base равный memory.size (считаем, что если других модулей нет, то memory.size вернёт __data_end).
2. Аллокатор модуля инициализируется и сам сдвигает memory_limit на N (параметр аллокатора) страниц

Далее если места не хватает, то аллокатор берёт запоминает текущий memory.size и выполняет memory.grow  с числом T (второй параметр) и добавляет это в список своих регионов (то, что в dlmalloc называется mstate) и т.д. до тех пор, пока память не закончится. И это всё работает хорошо в одном потоке.

а как memory.size может вернуть __data_end , если __data_end байты, а memory.size - страницы?

мы выставляем heap_base на препроцессинге васм кода же

а там можем всё, что угодно сделать

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

самый маленький оверхед, который я видел, был в asmble: там всё компилировалось в jvm классы и вызов функции из другого модуля - это просто вызов функции из другого jvm класса.

ну все относительно

в wasmtime сейчас впринципе довольно неэффективная calling convention

вот в васмере оверхед сравнительно большой

но оверхеад поверх этого не слишком большой

а в чём она заключается? есть, где почитать кроме исходников?