I suspect that the clojure is actually slightly better here than standard java collections.
With standard java collections, you'll tend to associate a collection with some attribute or property of an object and then modify it over time. The chances of this object living to a later generation are proportional to the use case. It doesn't matter how you modify it, the root object is probably still the same. With a clojure persistent collection, you might well have a reference that conceptually represents the same collection in memory. Over time this mutable reference to an immutable collection will change. The thing it changes to, may share some of the internal state of the previous version of the collection associated with that reference. But it might not. When it doesn't then no part of the original collection will remain and so there's less chance of an object living long enough to make it to a later generation. Additionally, as I understand it, structural sharing only happens when it is efficient to do so: the internal unit of sharing for vectors is something like an 8 object structure. So creating modified versions of a clojure collection will not necessarily create objects with extended lifetimes. The only case where clojure's persistent collections might produce more objects that survive to later generations is when you create lots of derivative collections that happen to be similar enough to share structure. Java could be better here if the code pattern was to create collections and then create lots of derived collections by creating copies of the collections contents and populating new collections with them. But that really isn't the Java way either. Of course, I could be wrong... Rob. On 12 Feb 2012, at 13:44, pron wrote: > Alright, let me explain. I'm not talking about memory leaks or whether or not > objects become eligible for collection when they should. The JVM garbage > collector is a generational collector, which means there's a humongous > difference in GC work between objects that become unreachable (eligible for > GC) shortly after creation, and those that become unreachable after a while > (specifically, after surviving a couple of "minor GC" cycles). While short > lived objects place a tiny, almost negligible burden, on the application, > long lived objects place a big burden, and the worst are those that in > between, that is, not collected immediately, but not reachable throughout the > lifetime of the application either (meaning, they are used for a little > while, say a few seconds or so, and then discarded). The place a huge burden > on the GC. > > Now, regular, mutable collections can live for very long, but modifying them > usually does not mess with the GC much. If you replace a value in a, say, > ConcurrentHashMap, there are no objects created or discarded. But in Clojure, > if you have a ref to a map, every assoc causes up to 6 PersistentHashMap > nodes to become unreachable, and those may very well be the worst kind of > medium-lived objects. OTOH, a high rate of assoc operations may constantly > discard the same nodes, o they become short-lived objects and not much of a > problem at all. So my question is, what is the "behavior profile" for > persistent collection nodes in Clojure applications, and what is their > measured effect on GC. Whatever the answer is, it's clear that their behavior > from a GC perspective is very different from that of mutable collections. > > -- > 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 -- 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
