Re: Weak reference semantics - why does a dead weak ref keep its value alive?

2014-05-27 Thread Simon Marlow
On 24/05/2014 01:11, Luite Stegeman wrote: In particular, the variant of weak reference you suggest is the /ephemeron/ semantics in Hayes. Their reachability rule is: The value field of an ephemeron is reachable if both (a) the ephemeron (weak pointer object) is

Re: Weak reference semantics - why does a dead weak ref keep its value alive?

2014-05-26 Thread Edward Z . Yang
Excerpts from Luite Stegeman's message of 2014-05-23 17:11:30 -0700: Actually it's not the same, since I think the finalizer should still be run if the weak pointer object is unreachable (and it should run when the key becomes unreachable). I think that's a legitimate point in the design

Weak reference semantics - why does a dead weak ref keep its value alive?

2014-05-23 Thread Luite Stegeman
Hi all, I'm reviewing and improving my weak references implementation for GHCJS, among other things to make sure that the profiling/stack trace support, currently being implemented by Ömer Sinan Ağacan as a GSoC project has the correct heap information to work with. JavaScript does not have weak

Re: Weak reference semantics - why does a dead weak ref keep its value alive?

2014-05-23 Thread Edward Z . Yang
Hello Luite, GHC's separation of weak references into keys and values is a generalization which can be useful to avoid space leaks; the motivation for the design is described in Stretching the storage manager: weak pointers and stable names in Haskell. In particular, the variant of weak

Re: Weak reference semantics - why does a dead weak ref keep its value alive?

2014-05-23 Thread Luite Stegeman
In particular, the variant of weak reference you suggest is the /ephemeron/ semantics in Hayes. Their reachability rule is: The value field of an ephemeron is reachable if both (a) the ephemeron (weak pointer object) is reachable, and (b) the key is reachable. Actually it's