но в версии dlmalloc в wasi есть mstate и теоретически он может работать, как ты сказал

а там поменять аллокатор нельзя?

можно, но это же аллокатор внутри васма будет, и он сможет только memory.grow вызывать

но нужна поддержка вызова mmap со стороны вм

не понял, я про то же

в васме же можно смотреть привызове malloc - ага , еще конец страницы не закончился значит работаем с ним. Потом когда кончился - не проверять что там есть ли свободные страницы, а безусловно аллоцировать новую тем же memory.grow

все на уровне буккипинга

ага, мне кажется, мы немного о разном. Смотри, я изначально имел в виду, что мы всю область кучи васма (т.е. всё, что после стека и данных) разобъём на несколько частей и у каждого модуля будет своя независимая часть, начало которой регулируется значением __heap_base. Но тут есть проблема в том, что dlmalloc и прочие аллокаторы могут только линейно расти из-за того, что есть в васме есть только одна инструкция для управления памятью. И эта область одного модуля растёт по дефолту до тех пор, пока grow не вернёт -1. Таким образом, она может зайти на соседние области, лежащие справа от неё, т.к. -1 возвращается, когда вм упирается в max mem size, заданный в васм файле (ну или указываемый при создании памяти).

возможно немного о разном но противоречие не там где ты указал.  Я понимаю ограничения которые дает memory.grow, однако я говорю о решение которое не упирается в них (+-)

Давай пример разберем

У тебя есть один модуль. У этого модуля есть стек, дата сегмент мб .bss, и все это умещается в половину одной страницы в сумме. __heap_base соответственно в районе 32k. У каждого модуля свой аллоктор скажем. Все это PIC.

Теперь представим что мы инстанциируем этот модуль два раза. Один попадает в первую страницу, второй попадает во вторую.

Безусловно, если впелить туда обычный аллокатор то вроде текущих версий тех же dlmalloc, wee_alloc, то все закончиться плачевно, а именно тем что первый инстанс наедет на область второго.

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

а именно ↑

тоесть первый модуль будет выделять аллокации до конца страницы. Если места не хватает на новую аллокацию, то аллокатор выделит новую страницу

новая страница окажется уже за пространством второго инстанса

я так понимаю, что это нужно не аллокатор патчить, а вм?

нет, именно аллокатор

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

я не понимаю, как именно аллокатор будет выделять новую страницу, он же вкомпилирован в васм и у него есть только memory.grow/memory.size

что делает функция malloc? Она обычно берет большие блоки памяти и выделает из них маленькие блоки памяти, правильно? Роль больших блоков играют обычно страницы, но не обязательно.

Блоки в этом пуле могут закончиться, в таком случае их нужно заполнить

в больших системах это приводит к mmap обычно

раньше кк brk/sbrk