Re: Re: What is the status of Weak References?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Re: What is the status of Weak References?

Owen
I see this is a very old thread, but I was wondering if there have been any new developments/plans?

My thoughts are this:

I think it's natural, if you're used to seeing people misuse GC, to be suspicious of weakrefs. With GC it's easy to create accidental memory leaks because you think the useful lifetime of your objects will always correspond to the lifetime of their references, when in fact they don't. My Java code always has more memory leaks than my C++ code, even though they tell me it shouldn't.

But in my experience people don't tend to misuse weakrefs. Weakrefs are tricky and awkward, so they're not a tempting feature; people don't tend to use them unless they have a specific compelling need. They're not a feature like C++ implicit conversions where everyone uses them and then shoots them in the foot. So I think the risk of adding weakrefs to the language from a code maintainability perspective are fairly low.

I think the one-time-listener pattern is really great. I've written some FRP code that uses it, and it makes a whole lot of things better, such as skipping over unnecessary calculations and handling listeners that return listeners gracefully. But it turns out it doesn't solve the memory problem unless you also have weakrefs. The reason is that it's far more common than you might think to create listeners that are never ever called. Think about opening a dialog with OK and Cancel buttons, listening on each. Every time you open the dialog, at least one listener will leak. What one-time-listeners does solve very nicely is the lifetime of control -- you can trust that the code associated with useless listeners will never be called, and never waste CPU cycles. But unfortunately the memory stays around unless you have weakrefs.

We must remember that our programming languages are Turing complete, so that everything that can be done with weakrefs can also be done without them. It might seem sort of like asking MS Paint to expose its flood-fill algorithm through an API -- because you know it's in there, and maybe you want to use it in your code and avoid duplication. Well, that would seem rather silly, asking MS Paint to expose an API -- go use your own flood-fill algorithm! And maybe that's what it seems like with the GC -- just because the GC is there, doesn't mean it has to make all its features available to the programmer to do what they like with.

It's just that it happens that implementing GC is just such a massive and tricky task, that it's just *so* *tempting* to use the GC that's already there. It can solve certain problems for you so that you don't have to solve them yourself. It doesn't solve every problem -- no software can -- but when it does solve one of your problems it solves it so beautifully. And it's just so frustrating to know the code is right there under the surface and you can't use it. Sure, maybe you should do the memory management yourself. But if you could just get at those weakrefs..... then you'd be in good shape.

In my experience there is a very small set of problems that really really benefit from weakrefs. Most of the code you write will never encounter one of those problems. But when you do hit one, it's so nice when the language supports it. You write your weakref code carefully -- because it's nondeterministic and hard to debug. You box it in real tight and get a solid core that uses weakrefs just the way you need it. Then you expose it as a library and never think about it again. You make sure the semantics of your library never expose a nondeterministic variable -- those stay on the inside.

The funny thing is that even when you keep your API fully deterministic, the fact that it can use the GC's nondeterminism on the inside changes what the external API can do. It's like how using a nonlinear electrical component can change the set of linear transfer functions you can implement at the boundary. And because everyone wants to work with nice APIs at the boundary, there's very little temptation to abuse weakrefs.

Just some things to consider.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: What is the status of Weak References?

Isiah Meadows-2
This is probably best asked/stated here:
https://github.com/tc39/proposal-weakrefs/
-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Thu, Jul 20, 2017 at 6:26 PM, Owen <[hidden email]> wrote:

> I see this is a very old thread, but I was wondering if there have been any
> new developments/plans?
>
> My thoughts are this:
>
> I think it's natural, if you're used to seeing people misuse GC, to be
> suspicious of weakrefs. With GC it's easy to create accidental memory leaks
> because you think the useful lifetime of your objects will always correspond
> to the lifetime of their references, when in fact they don't. My Java code
> always has more memory leaks than my C++ code, even though they tell me it
> shouldn't.
>
> But in my experience people don't tend to misuse weakrefs. Weakrefs are
> tricky and awkward, so they're not a tempting feature; people don't tend to
> use them unless they have a specific compelling need. They're not a feature
> like C++ implicit conversions where everyone uses them and then shoots them
> in the foot. So I think the risk of adding weakrefs to the language from a
> code maintainability perspective are fairly low.
>
> I think the one-time-listener pattern is really great. I've written some FRP
> code that uses it, and it makes a whole lot of things better, such as
> skipping over unnecessary calculations and handling listeners that return
> listeners gracefully. But it turns out it doesn't solve the memory problem
> unless you also have weakrefs. The reason is that it's far more common than
> you might think to create listeners that are never ever called. Think about
> opening a dialog with OK and Cancel buttons, listening on each. Every time
> you open the dialog, at least one listener will leak. What
> one-time-listeners does solve very nicely is the lifetime of control -- you
> can trust that the code associated with useless listeners will never be
> called, and never waste CPU cycles. But unfortunately the memory stays
> around unless you have weakrefs.
>
> We must remember that our programming languages are Turing complete, so that
> everything that can be done with weakrefs can also be done without them. It
> might seem sort of like asking MS Paint to expose its flood-fill algorithm
> through an API -- because you know it's in there, and maybe you want to use
> it in your code and avoid duplication. Well, that would seem rather silly,
> asking MS Paint to expose an API -- go use your own flood-fill algorithm!
> And maybe that's what it seems like with the GC -- just because the GC is
> there, doesn't mean it has to make all its features available to the
> programmer to do what they like with.
>
> It's just that it happens that implementing GC is just such a massive and
> tricky task, that it's just *so* *tempting* to use the GC that's already
> there. It can solve certain problems for you so that you don't have to solve
> them yourself. It doesn't solve every problem -- no software can -- but when
> it does solve one of your problems it solves it so beautifully. And it's
> just so frustrating to know the code is right there under the surface and
> you can't use it. Sure, maybe you should do the memory management yourself.
> But if you could just get at those weakrefs..... then you'd be in good
> shape.
>
> In my experience there is a very small set of problems that really really
> benefit from weakrefs. Most of the code you write will never encounter one
> of those problems. But when you do hit one, it's so nice when the language
> supports it. You write your weakref code carefully -- because it's
> nondeterministic and hard to debug. You box it in real tight and get a solid
> core that uses weakrefs just the way you need it. Then you expose it as a
> library and never think about it again. You make sure the semantics of your
> library never expose a nondeterministic variable -- those stay on the
> inside.
>
> The funny thing is that even when you keep your API fully deterministic, the
> fact that it can use the GC's nondeterminism on the inside changes what the
> external API can do. It's like how using a nonlinear electrical component
> can change the set of linear transfer functions you can implement at the
> boundary. And because everyone wants to work with nice APIs at the boundary,
> there's very little temptation to abuse weakrefs.
>
> Just some things to consider.
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: What is the status of Weak References?

Owen
Thank you for the link, I'm glad to see that people have been making progress on it.

On Fri, Jul 21, 2017 at 2:16 PM, Isiah Meadows <[hidden email]> wrote:
This is probably best asked/stated here:
https://github.com/tc39/proposal-weakrefs/
-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Thu, Jul 20, 2017 at 6:26 PM, Owen <[hidden email]> wrote:
> I see this is a very old thread, but I was wondering if there have been any
> new developments/plans?
>
> My thoughts are this:
>
> I think it's natural, if you're used to seeing people misuse GC, to be
> suspicious of weakrefs. With GC it's easy to create accidental memory leaks
> because you think the useful lifetime of your objects will always correspond
> to the lifetime of their references, when in fact they don't. My Java code
> always has more memory leaks than my C++ code, even though they tell me it
> shouldn't.
>
> But in my experience people don't tend to misuse weakrefs. Weakrefs are
> tricky and awkward, so they're not a tempting feature; people don't tend to
> use them unless they have a specific compelling need. They're not a feature
> like C++ implicit conversions where everyone uses them and then shoots them
> in the foot. So I think the risk of adding weakrefs to the language from a
> code maintainability perspective are fairly low.
>
> I think the one-time-listener pattern is really great. I've written some FRP
> code that uses it, and it makes a whole lot of things better, such as
> skipping over unnecessary calculations and handling listeners that return
> listeners gracefully. But it turns out it doesn't solve the memory problem
> unless you also have weakrefs. The reason is that it's far more common than
> you might think to create listeners that are never ever called. Think about
> opening a dialog with OK and Cancel buttons, listening on each. Every time
> you open the dialog, at least one listener will leak. What
> one-time-listeners does solve very nicely is the lifetime of control -- you
> can trust that the code associated with useless listeners will never be
> called, and never waste CPU cycles. But unfortunately the memory stays
> around unless you have weakrefs.
>
> We must remember that our programming languages are Turing complete, so that
> everything that can be done with weakrefs can also be done without them. It
> might seem sort of like asking MS Paint to expose its flood-fill algorithm
> through an API -- because you know it's in there, and maybe you want to use
> it in your code and avoid duplication. Well, that would seem rather silly,
> asking MS Paint to expose an API -- go use your own flood-fill algorithm!
> And maybe that's what it seems like with the GC -- just because the GC is
> there, doesn't mean it has to make all its features available to the
> programmer to do what they like with.
>
> It's just that it happens that implementing GC is just such a massive and
> tricky task, that it's just *so* *tempting* to use the GC that's already
> there. It can solve certain problems for you so that you don't have to solve
> them yourself. It doesn't solve every problem -- no software can -- but when
> it does solve one of your problems it solves it so beautifully. And it's
> just so frustrating to know the code is right there under the surface and
> you can't use it. Sure, maybe you should do the memory management yourself.
> But if you could just get at those weakrefs..... then you'd be in good
> shape.
>
> In my experience there is a very small set of problems that really really
> benefit from weakrefs. Most of the code you write will never encounter one
> of those problems. But when you do hit one, it's so nice when the language
> supports it. You write your weakref code carefully -- because it's
> nondeterministic and hard to debug. You box it in real tight and get a solid
> core that uses weakrefs just the way you need it. Then you expose it as a
> library and never think about it again. You make sure the semantics of your
> library never expose a nondeterministic variable -- those stay on the
> inside.
>
> The funny thing is that even when you keep your API fully deterministic, the
> fact that it can use the GC's nondeterminism on the inside changes what the
> external API can do. It's like how using a nonlinear electrical component
> can change the set of linear transfer functions you can implement at the
> boundary. And because everyone wants to work with nice APIs at the boundary,
> there's very little temptation to abuse weakrefs.
>
> Just some things to consider.
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss