Weak maps for GC references?

[skuzmich]

Would browser VM be able to support weak maps for GC references without additional overhead?

Some languages provide an identity hash code for every object, usually a i32 random number that is always the same for a particular object instance.

These identity hash codes are often computed lazily because many objects never need them. They either never put into a hash table or hash code method is overridden to not depend on object identity. In case VMs already have internal hash codes (I assume they would not want to provide them to user-space directly) and could support weak maps efficiently, languages would be able allocate their identity hashCodes lazily inside these weak maps, saving 32 bits for most GC objects.

[RossTate]

This is an interesting idea. I think I can adjust a bit by calling them unenumerable maps. That is, there is no way to enumerate through all the entries of the map. This means that if an engine knows a key is no longer accessible, then its entry can be removed and no one could tell the difference. It also means there's no non-determinism, unlike Java's WeakHashMap in which entries might or might not be enumerated depending on whether the GC has yet discovered that their keys can be collected.

Also, I don't think identity hash codes are the only application of this in supporting language runtimes. Doesn't the JVM use a similar trick for monitors, since technically every object in Java can act as a monitor?

[titzer]

JavaScript has WeakMap, which was designed specifically for this purpose. It should be fairly easy to use in the JavaScript embedding. Of course that doesn't help other embeddings, so the question is whether Wasm should have similar functionality.

[bvibber]

A WeakMap equivalent would be great for mapping publicly exportable object references to local pointers without exposing the pointers to forgery by calling modules. [Edit: specifically this would be good for non-JS bindings or the use of an app composed from multiple modules.]

[tlively]

We have consensus on a JS interop solution (#279) that does include WeakMap support, although it does come with some space overhead in the V8 implementation. Language implementations could use this to avoid allocating additional space in their objects as OP suggested.