Weak References

Mark S. Miller erights at google.com
Sun Sep 6 17:50:21 UTC 2015

On Sun, Sep 6, 2015 at 10:32 AM, Isiah Meadows <isiahmeadows at gmail.com>

> That's actually the feature I need...
Hi Isiah and Thomas, what "That"? If you mean pre-mortem finalization, like
Java's Object.finalize or the cited node callbacks (whose pre-mortem nature
is made clear by isNearDeath at <
I would be very surprised if you actually need it. Could you show a very
small but motivating example? I have never run across an example that
couldn't be expressed at least as well with post-mortem finalization.

I ask for a "very small but motivating example" so that, hopefully, I'll be
able to find the time to rewrite it using post-mortem finalization.

Note the C++ RAII is an immediate pre-mortem invocation of a destructor at
a predictable and deterministic time. The general arguments against
gc-driven pre-mortem finalization do not apply.

If you just mean some kind of finalization via callback, sure, that's
always been part of the strawman.

> On Sat, Sep 5, 2015, 09:48 Thomas <thomasjamesfoster at bigpond.com> wrote:
>> I haven't had too much of a look at the weak references chatter, but the
>> npm module you linked to provides a callback for when the object is garbage
>> collected. Are you using that feature? Perhaps destructors might be worth
>> thinking about as well alongside weak references (then again, maybe this
>> putting too much of the underlying gc implementation into the spec).
>> Thomas
>> On 5 Sep 2015, at 9:07 PM, Isiah Meadows <isiahmeadows at gmail.com> wrote:
>> I'm resurrecting this [1] because I have found a use case where I needed
>> a weak reference. Is there any chance this could get into the language?
>> Here's my particular use case: making a stream with a rotating
>> destination that itself acts as a stream (snippet of that code, or what I'd
>> like it to be).
>> ```js
>> function rotateStream(interval, format) {
>>     // Without the weak reference here, there's a memory leak
>>     const ref = new WeakReference({})
>>     setStream(ref.get(), format)
>>     setInterval(function () {
>>         if (ref.exists()) setStream(ref.get(), format)
>>         else clearInterval(this)
>>     }, interval)
>>     return ref.get()
>> }
>> ```
>> This basically rotates an active stream, with the weak reference pointing
>> to the said stream. The alternative requires explicit marking (in this
>> case, with a `close` method):
>> ```js
>> function leakyRotateStream(interval, format) {
>>     let stream = {close() {
>>         clearInterval(timer)
>>         timer = stream = null
>>     }}
>>     const timer = setInterval(function () {
>>         setStream(stream, format)
>>     }, interval)
>>     setStream(stream, format)
>>     return stream
>> }
>> ```
>> In this use case, weak references would simplify the implementation and
>> reduce memory costs. And I would rather take advantage of the GC machinery
>> than explicit memory management (as explicit as C), as it would be easier
>> to collect when that's the only thing referenced.
>> (The setInterval callback is gc'd with all its references when it's
>> cleared from within.)
>> Thankfully, I'm using Node.js, so `weak` [2] is an option (the only
>> option, really). But I would definitely appreciate if it was available in
>> JS proper, across engines. V8, SpiderMonkey, and JSC all have weak
>> references to JS objects as part of their public API, and I would be
>> surprised if the implementation work would be anything significant.
>> [1]: https://esdiscuss.org/topic/what-is-the-status-of-weak-references
>> [2]: https://github.com/TooTallNate/node-weak
>> --
>> Isiah Meadows
>> _______________________________________________
>> 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/20150906/3e29d9be/attachment-0001.html>

More information about the es-discuss mailing list