Здравствуйте, fddima, Вы писали:
F>Так там туда же ссылка и стоит. Что-то будет точно
Пока что даже GC не планируется для вебасма.
Сказано так: GC может быть выполнен в виде скомпиллированной в webasm VM.
То бишь, возьми реализацию VM джавы или дотнета, портируй её на webasm, вот и будет тебе GC.
Правда, к GC JS браузера он не будет иметь никакого отношения.
F>а вот с какими ограничениями — уже будет видно по факту. Что они подразумевают под opaque reference types — мне вот не очень понятно...
Некий тип без объявления "тела". Такой тип можно получать и передавать по ссылке.
Это похоже на одну из идей, как можно сделать вызовы из нейтивной (по архитектуре) webasm в управляемую JS-среду.
Например, как-то так:
class JsObject;
typedef JsObject * JsRef;
И затем погнали некое АПИ сверху, типа такого:
void incrementRef(JsRef jsObj);
void decrementRef(JsRef jsObj);
size_t memberCount(JsRef jsObj);
JsObject getMemberByIndex(JsRef jsObj, size_t index);
JsObject getMemberByName(JsRef jsObj, JsStringRef name);
Тут одно плохо — они в эту сторону не то, что делать что-то еще не начали, тут даже еще серьезного обсуждения нет.
Т.е., все эти вещи если и появятся — то очень не скоро и скорее всего сам JS будет уже не актуален на тот момент.
F>если через протаскиваение persistent GC handles — то опять надо будет обязательно все ссылки зануливать, что катастрофой в общем-то тоже не будет. Утечки просто будут и крики <мой браузер> опять сожрал всю память. 
Не-е-е-е. Ты не понял. "Плоская память" VM WebAsm и память JS-машинки вообще никак не пересекаются по GC.
Я рядом давал ссылки, они рассуждают так, что для GC объектов (если GC когда-нить и будет частью webasm) будет выделена совсем отдельная куча. Более того, если почитать вот эту ссылку внимательно:
https://github.com/WebAssembly/design/blob/master/GC.md
то выглядит так, что они уже и сами поняли, что в случае GC у них получится Java/Дотнет, вид сбоку, ы-ы-ы.
Посмотри, что ни хотят сделать с JS:
https://github.com/nikomatsakis/typed-objects-explainer/blob/master/README.md
