They are not completely orthogonal. In fact they work well together. One of the core assumptions in generational garbage collection is that data in higher generations rarely grow pointers to data in lower generations. This is often true in imperative programs. But absent implicit mutation in the form of laziness, it's _always_ true in functional programs. If your purely functional language is strict, you can engineer your GC algorithm to take advantage of it as Joe Armstrong did for Erlang:
One pass real-time generational mark-sweep garbage collection: http://citeseer.ist.psu.edu/armstrong95one.html Clojure isn't purely functional but it is sufficiently pure to play along well with standard generational schemes. As persistent data structures go, it's possible to have a data structure that is physically constituted from pieces in generation 0 and pieces in generation N without triggering the card-marking write barrier and forcing the generation 0 pieces to be hoisted into generation N. -Per On Sun, Apr 4, 2010 at 7:53 AM, verec <jeanfrancois.brouil...@googlemail.com> wrote: > The two issues are orthogonal. > > Even if Clojure had been going for full copies to preserve > immutability, the reason why the "old" copy would leak is only because > your code would hold a reference to it. > > With structural sharing, those bits of "old" that are still retained > in "new" are precisely those bits that weren't modified between the > two versions, and certainly have to stay in memory, because they > belong in "new" too. As for the bits of "old" that point to this > shared part, if nothing *else* points to them, then there's no reason > for them not to be GC'd apart from the references that *your* code > might hold on them. > > On Apr 3, 3:13 pm, "David R. Smith" <davesmith....@gmail.com> wrote: >> Hi All, >> >> I'm sold on the virtues of immutable data, but the notion of >> "persistent in-memory data structures" sounds kind of like a euphemism >> for a garbage collection leak. >> >> Could someone point me to a reference explaining how persistent >> transactional memory works in the context of garbage collection? Are >> there special issues related to garbage collection I need to be >> concerned with when using Seqs? >> >> Sincerely, >> >> Dave Smith > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > To unsubscribe, reply using "remove me" as the subject. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
