Suggest WeakMap.prototype.values()

[Michał Wadas]

For your case I would suggest deterministic scope for objects via promises
and reference counting across workers. For your case you don't need to
really GC object - you can just put in invalided internal state.

See sequelize transaction handling for similar solution.

However, observing GC would be great.

On 26 Aug 2016 7:55 a.m., "현우박" <nemo1275 at gmail.com> wrote:

> I know it's the design choice that WeakSet and WeakMap's key is not
> enumurable because it's weak, but I think values in WeakMap is little
> different.
>
> WeakSet's values and WeakMap's keys must not be referenced from the
> map/set itself. If values from WeakSet can be accessed, then it cannot be
> GCed. And it's not we want for WeakMap/Set.
>
> But well, WeakMap's values ARE referenced from WeakMap, via map.get(key).
> So values in WeakMap cannot GCed until it's matching key is GCed, and it's
> intended feature.
>
> My suggestion is, a new WeakMap method that does same thing as
> Map.prototype.values(). With such method, we can utilize JS runtime's GC
> functionality in userspace.
>
> For example, I'm planning to make immutable data structures on
> SharedArrayBuffer to boost data passing speed between Workers. As you may
> know proper GC is the important problem for immutable data structure. But
> in this case GC is not the free lunch as data is shared between multiple JS
> context. So I need to check manually what data node is still visible in
> each context, and clear unused data manually.
>
> Please tell me your idea about this suggestion
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160826/7073a635/attachment.html>