Feature suggestion - event from the JS Garbage Collector

[lskyum]

Suppose one would like to nicely wrap C++ objects in JavaScript objects, so they could be exposed to JavaScript developers. I suppose many uses for wasm will be exactly that - at least in the beginning, until Java/C# is available.

With Emscripten it is currently nessesary to manually delete such objects, but it would be nice if one could just catch an event when the JS object is garbagecollected.

I suppose this is really a feature request for a "rooting API", to allow for weak references, that can provide an event, when an object is garbage collected.

[paleozogt]

This has been my biggest problem with using emscripten (which is not really its fault). We definitely need some kind of "finalizer".

[kripken]

There is a proposal for a next-event-loop finalizer type event in future JS. It should solve this problem.

[trevnorris]

@kripken Has any type of spec for that been created, or is just in discussion phase?

[kripken]

Not sure, I heard about it on twitter from @BrendanEich.

[kg]

There are a couple very old strawman APIs for JS weak references but I don't think there's anything current. It's definitely my understanding that they are going in eventually, because someone figured out how to implement them without compromising JS's security priorities. (I've been campaigning for them for a couple years.)

[BrendanEich]

I will put weak references on the July TC39 meeting agenda. The old proposal is here

http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs

What's most needed is someone on TC39 to champion this proposal for inclusion in ES2016 or (more likely at this point) ES2017.

/be

[abustin]

So what is the current strawman for binding C and JS? Interested to hear peoples thoughts on this.

Could WASM be able to leverage existing JS engine primitives? Each engine has its own C API for creating JS function, object bindings with event callbacks (such as destroy). Could there be a common/generic JS engine abstraction lib for WASM to bind into the JS environment? Or would that over engineering the problem?

[trevnorris]

@abustin In V8 you can use Persistent<> handles and set the weak callback. Do it all the time to cleanup attached C++ class instances after the object is no longer in use.

As far as cross-VM compatibility, been having discussions in node's API WG about abstracting away from V8. The biggest blocker is lack of information around object and GC life cycle. Enough so that it's prevented progress.

[lskyum]

I think we need both weak references and finalizer events to solve this issue. If a wasm module should return an existing JS object it would need to reference it. The reference should be weak to allow GC.

I am not sure the proposed WeakMap will work here because the weak part is the key and not the value.

[trevnorris]

@BrendanEich Was expecting an API that would notify when the object was no longer in use. With the API in the strawman would have to create a Set of WeakRef handles and iterate over them at intervals so any additional cleanup could happen. Feels like implementing an inefficient GC in JS.

[BrendanEich]

WeakMap is not relevant. Tattoo this in your inner eyelids!

@trevnorris, please read the ecmascript.org wiki page about GC non-determinism. We are not going to expose a callback from the garbage collector's sweep phase, entailing post-mortem finalization and the possibillity of ressurection as in Java. That is a non-starter.

The event loop helps here. At a later turn, some notifications based on definite finalization fire, without disclosing engine-specific GC schedules.

/be

[trevnorris]

@BrendanEich The only feature we depend on in node.js is to be notified when an object is no longer referenced in JS. Used to cleanup I/O handles in certain cases. Unfortunately this has been a blocker for abstracting away the native implementation so node could be supported by multiple VMs.

V8 does (probably unofficially) support being able to resurrect objects about to be GC'd, Though node.js core doesn't use it, and have never seen it used in the wild.

EDIT: Correction. The 'vm' module does make use of resurrecting objects.

[abustin]

abstracting away from V8

@trevnorris which engines have prevented this abstraction? It sounds like nodejs has a dependance on v8's set of api and events that are missing in other engines?

[BrendanEich]

@abustin: that's the wrong way of looking at it. Even V8 alone does not want to commit to its current GC implementation via a GC-schedule-leaky abstraction.

Hence TC39's strawman proposal that uses next-event-loop-turn scheduling of finalization-based notifications. That's the only way to roll. Trying to blame other engines won't cut it. V8 smeared across the future is multiple engines.

/be