Здравствуйте, D. Mon, Вы писали:

V>>Это нейтивный стек вызовов нельзя сканировать, а стек данных можно:
DM>Хм, можно ссылку на описание "стека данных" в WebAssembly?

Одной ссылки у меня нет (мне её искать столько же, сколько и тебе), из обсуждений в баг- и пул-реквестов проекта стало понятно, что под стек "песочницы" выделяется просто область памяти из той же кучи, из которой выделяется обычная динамическая память для данного экземпляра "песочницы". По-умолчанию 256 К, вроде бы.

С другой стороны, вряд ли тут требуется какое-либо особое описание, бо в классике стеков всегда два — стек данных и стек возвратов.

Это мы так привыкли, что в мейнстримовом фон-неймановском железе эти стеки совмещены, что, с одной стороны удобнее (экономится один регистр процессора и требуется управлять одной областью памяти, а не двумя), с другой стороны — чинит препятствия стековым вычислениям, где состояние стека в результате пред. вычислений одновременно является входным аргументом для последующих вычислений. Такие вычисления в кол-ве операций эффективнее по сравнению со совмещённым стеком, требующим возврата состояния стека после вызова подпрограмм.

Так-то сейчас есть всё более растущая область гарвардского embedded, там стеки всегда раздельные.

Ну и, есть та гарантия, что то, что не является UB в С/C++, не будет являться UB и в бинарнике под WebAssembly.
Т.е. указатели и ссылки на локальные переменные — это вполне себе доступные адреса памяти.

На всякий случай напомню, что преобразование указателя на ф-ию в указатели на данные (например в void*) и обратно — UB в С/С++.
Тем самым можно соблюсти гарантию того, что адрес ф-ий будет невозможно рассматривать как адрес данных.


DM>Если что, мы тут про WebAssembly говорим, а не про ASM.js.

У них есть взаимно-однозначно отображаемая модель.
Походу, ASM.js показан для демонстрации, т.к. llvm не так чтобы бегло читается с листа. ))

Вполне может быть, что "расшифровывать" происходящее с помощью ASM.js — вполне себе норма в этом проекте.
По крайней мере в обсуждении баг- и пул- реквестов я видел это более одного раза.


V>>В любом случае, в чистом нейтиве бывают только пессимистичные GC, т.е. если в стеке лежат только данные — это даже еще лучше.
DM>Что такое "пессимистичные GC"?

Консервативные.

The collector has to make pessimistic assumptions if a memory slot can contain both a pointer or an integer value

DM>Консервативные? Нет, это не так совершенно.

Еще и "совершенно"? ))
Объем сканируемой памяти данных резко уменьшается, если стек данных отделить от стека возврата.


V>>А если брать что-то типа .Net/Java с точным GC, то для такого GC в любом случае надо размечать фреймы стека и связывать их с метаинформацией, поэтому, отсутствие доступа к адресам возвратов мешать не должно — указатель на текущий фрейм можно протягивать как неявный аргумент любого вызова.
DM>Если текущий фрейм не в куче, то на него не бывает указателей в WebAssembly.

Фреймы стека данных живут в стеке данных, т.е. на куче в исполнении WebAssembly.