IMHO, it should be resolved in `WeakRefs` (Stage 1).
https://github.com/tc39/proposal-weakrefs
2016/08/26 17:19、Michał Wadas <michalwadas at gmail.com> のメッセージ:
> 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
> _______________________________________________
> 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/20160827/291a58a3/attachment.html>
moriken at kimamass.com (2016-08-27T10:40:41.766Z)
IMHO, it should be resolved in `WeakRefs` (Stage 1).
https://github.com/tc39/proposal-weakrefs
