On 12/10/2011 09:04, Simon Peyton-Jones wrote:
| Just out of curiosity, why not implement a memo table where both keys
| and values are weak pointers? Sure, it doesn't have the nice property
| that keys keep values alive, but I wonder how much difference it would
| be in practice.
I'll let Simon M answer that! I have this stuff fully paged out.
Hard to tell how much difference it would make in practice without
actually trying it, and moreover it would be entirely
application-specific: if your program happens to keep the values alive
for some other reason, then it would make no difference, but otherwise
all the values in the memo table would be GC'd and your memo table would
be useless.
Is your goal to simplify the design? The values are just treated in the
same way as the finalizers, incedentally.
In practice I don't think anyone actually uses this kind of memo table.
We never put the code into a package and released it properly,
although you can find it in our testsuite
(testsuite/tests/lib/should_run/Memo1.lhs). The overhead for
maintaining the memo table means that you have to memoize a *lot* of
work to make it worthwhile. Perhaps it could be optimised, though.
Cheers,
Simon
S
| -----Original Message-----
| From: Paul Liu [mailto:[email protected]]
| Sent: 11 October 2011 22:20
| To: Simon Peyton-Jones
| Cc: [email protected]
| Subject: Re: help needed to understand weak reference and its design choice
|
| Hi Simon, thanks a lot for the pointer!
|
| I was kind of wondering why mkWeak# has an IO type, and the paper made
| it much clearer that it's not about reachability from the Weak#
| object, but the side effect that's between key and value objects.
|
| Just out of curiosity, why not implement a memo table where both keys
| and values are weak pointers? Sure, it doesn't have the nice property
| that keys keep values alive, but I wonder how much difference it would
| be in practice.
|
| Regards,
| Paul Liu
|
| On Tue, Oct 11, 2011 at 1:07 AM, Simon Peyton-Jones
|<[email protected]> wrote:
|> | I'm just trying to understand the design rationale behind GHC's weak
|> | references. Any help is greatly appreciated! Thanks!
|>
|> Did you read the paper http://research.microsoft.com/en-
| us/um/people/simonpj/papers/weak.htm
|>
|> It gives the design rationale in detail.
|>
|> Simon
|>
|> | -----Original Message-----
|> | From: [email protected] [mailto:[email protected]] On
Behalf
| Of
|> | Paul Liu
|> | Sent: 10 October 2011 21:21
|> | To: [email protected]
|> | Subject: help needed to understand weak reference and its design choice
|> |
|> | GHC.Weak says "A weak pointer expresses a relationship between two
|> | objects, the key and the value: if the key is considered to be alive
|> | by the garbage collector, then the value is also alive. A reference
|> | from the value to the key does not keep the key alive."
|> |
|> | Am I right to say that if we use the same object for both key and
|> | value, we get the behavior of a traditional weak pointer (where it
|> | doesn't keep the object alive, and becomes null when the object goes)?
|> |
|> | I tried to look for use cases where key and value are different, there
|> | are in total only two such cases in GHC's library sources (and a few
|> | others where only the finalizer is of interest):
|> |
|> | mkWeakIORef :: IORef a -> IO () -> IO (Weak (IORef a))
|> | mkWeakIORef r@(IORef (STRef r#)) f = IO $ \s ->
|> | case mkWeak# r# r f s of (# s1, w #) -> (# s1, Weak w #)
|> |
|> | and
|> |
|> | mkWeakThreadId :: ThreadId -> IO (Weak ThreadId)
|> | mkWeakThreadId t@(ThreadId t#) = IO $ \s ->
|> | case mkWeak# t# t (unsafeCoerce# 0#) s of
|> | (# s1, w #) -> (# s1, Weak w #)
|> |
|> | In both cases it is trying make a weak reference of an unboxed value
|> | and yet to return its box when de-referencing. I wonder if the same
|> | goal can be achieved by using the following definition:
|> |
|> | data Weak v where
|> | Weak :: Weak# w -> (w -> v) -> Weak v
|> |
|> | mkWeakIORef :: IORef a -> IO () -> IO (Weak (IORef a))
|> | mkWeakIORef r@(IORef (STRef r#)) f = IO $ \s ->
|> | case mkWeak# r# r# f s of (# s1, w #) -> (# s1, Weak w (IORef .
STRef) #)
|> |
|> | Apart from some kind mis-matches (no way to annotate v as unlifted
|> | kind), will this definition of mkWeakIORef work the same? If so, It
|> | seems to me that GHC's weak references are no more general than the
|> | traditional definition of weak pointers.
|> |
|> | I'm just trying to understand the design rationale behind GHC's weak
|> | references. Any help is greatly appreciated! Thanks!
|> |
|> | Regards,
|> | Paul Liu
|> |
|> | _______________________________________________
|> | Cvs-ghc mailing list
|> | [email protected]
|> | http://www.haskell.org/mailman/listinfo/cvs-ghc
|>
|>
|>
|
|
|
| --
| Regards,
| Paul Liu
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
