On 06/08/2017 09:29 PM, Ruben Astudillo wrote:
I didn't understand some parts
On 08/06/17 15:08, Brandon Allbery wrote:
It's not just allocation: if it didn't get garbage collected, then there is *at least* one reference to it that needs to be updated.
which reference is that?. Immutability means that old data can't reference the new one, right?. What kind of reference (apart from live data on the stack) can we have on new data on the nursery?
No, immutability does not mean that old data cannot reference new data. The reason is that we are in a lazy language: If you have an old value referencing a thunk and the thunk is evaluated, it is replaced by an indirection to the new value (it may be replaced if the new value is small enough, but this is just an optimization). So if two threads share a reference to an infinite list and one threads evaluates a piece of the list and later throws away its reference, the other thread still references the new evaluated part of the list - which was allocated in the nursery of the other thread! Additionally, not all data in Haskell is immutable. Just think about all the different vectors, arrays and things like IORefs you can modify as long as you are in the correct monad. The GC has to take care of that, otherwise your program would either leak memory or after the GC frees your data while you still hold an IORef pointing to it or similar.
So what happens when there is more than one, and some of those are active in other threads?
Same as before right?
Sorry, maybe I don't have the right mental model. If you could show me a general picture of what happens when a nursery gets full I would appreciate it :-)> -- Ruben Astudillo _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.