linear-time weak-map gc

Allen Wirfs-Brock allen at
Sun Mar 20 18:35:48 PDT 2011

typically this is seen as a quality of implementation issue. Note the we (and most other language specs.) don't say much (or anything) about GC in general.  In one sense we don't need to say anything else about WeakMaps because it would be a lower quality implementation to retain objects in one that are provably not accessible. However, because of the long history of such poor implementations we need to say say just enough to make it clear what we expect.

It is something I'm sure I can draft when the time comes, but it isn't the most pressing matter.

On Mar 20, 2011, at 8:24 AM, David Herman wrote:

> Come to think of it, evaluating implementations for proper tail calls is a little easier, at least in implementations with fixed-size stacks and stack overflow exceptions. I'm not quite sure how you write weak map tests that check memory consumption, unless implementations expose heap size measurements. (They'd be especially hard to automate, but I'd rather have the ability to test manually than none at all.)
> Anyone have experience with this from, say, the JVM and its weak references?
> Dave
> On Mar 20, 2011, at 8:20 AM, David Herman wrote:
>>> It's weird, though--specifying anything about WeakMap reachability at
>>> all is a lot like specifying proper tail calls: it's hard to say what
>>> you mean without being a lot more concrete about the abstract machine
>>> the language runs on than you would be otherwise. The real requirement
>>> is simply that the WeakMap not observably consume space for entries
>>> that can't be queried. Maybe we could just say that.
>> Yeah. The perfect is the enemy of the good when it comes to specifying these kinds of features. We don't have a formal semantics for the rest of the language anyway, so we shouldn't be aiming for a formal cost model, too. Instead I think we need a combination of as-precise-as-reasonably-possible informal English in the spec with the best tests we can come up with for evaluating implementations.
>> Dave
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list