{Weak|}{Map|Set}

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Sep 16 12:41:35 PDT 2011


On Sep 16, 2011, at 10:52 AM, Mark S. Miller wrote:

> On Fri, Sep 16, 2011 at 10:41 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> [...] 
> This is the exact situation that exists for any ECMAScript dynamic allocation.  There are no guarantees in the ES spec. that resources allocated with an inaccessible object  will be freed in a timely manner or ever.  Given the state of the art of memory management isn't clear how you could make such guarantees without unreasonably limiting implementors.
> 
> Does everyone, on both sides of this debate, agree that the WeakMap GC issue is and the tail-call issue are equivalent specification problems?
> 
> I propose that the way to look at both of these is a way I have seen proposed somewhere[1] about how to deal with specifying tail calls. Rather than taking it as a correctness criteria on an implementation, instead view it as a statement about how to analyze the space complexity of programs. When writing Andreas' server, it would be nice if he could analyze whether his algorithms have O(1) asymptotic space complexity. Does this mean it will succeed on every implementation? Of course not. It may be that a given implementation doesn't even have enough memory for the server to load. Or the server might crash for other reasons.
> 
> In order to do this analysis, we need a model of how much memory is retained by a computational state -- not in terms of how many bytes, but in terms adequate to make statements about asymptotic space complexity.
> 
> Then an implementation that runs out of space on programs held to be "reasonable" by such analysis can be viewed as low quality implementations.

This all sounds reasonable but I don't see how it particularly impacts the actual specification.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110916/f580fc90/attachment.html>


More information about the es-discuss mailing list