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 reachable, and (b) the key is
reachable.
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).
The implementation would indeed need to keep some reference to the key
and finalizer around after the weak pointer becomes unreachable, perhaps
on some weak pointers list, but the same goes for GHC's semantics. The
only difference is that the value (which might in turn make a whole
bunch of other data reachable) would not have to be retained.
I haven't been able to think of any issues with considering the value
unreachable here, so I'm still puzzled as to why GHC's semantics would
be preferable. It doesn't look like it would complicate implementation
too much either.
So the semantics is currently:
w <- mkWeak k v f
1. v is reachable if k is reachable
2. f is reachable if k is reachable
3. when k is unreachable, the finalizer f is run
4. deRefWeak w returns
- Nothing, if k is not reachable
- Just v, otherwise
In your proposal I think you would change the first one to
1. v is reachable if both k and w are reachable
Arguably this makes sense, because as you say, v is accessed via w, and
what's the point of making v reachable if you can't access it? It's just
a space leak.
My only worry is how hard this is to implement. Rather than considering
w as unconditionally reachable (which is what we do now), you would have
to track its reachability, and only consider v reachable when both k and
w are reachable. A weak pointer object where only k was reachable would
probably need to be put in a semi-dead (zombie?) state, so that we would
still run the finalizer when k becomes unreachable. I suspect all this
might be more complicated to implement, but maybe there's a simpler way
that I'm missing.
Cheers,
Simon
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
