Wait... maybe I do :) Perhaps I was thinking that you needn't increment the refcount of a node when you're just looking at it, but only if you're going to return it or attach it to something else... Sorry to know so little...
On Thursday, 30 May 2013 21:00:59 UTC+1, atucker wrote: > > Hi! I'm an interested spectator but understand very little :) I wonder > if anyone would take a moment to explain? > E.g. I can't see why reading from a data structure should ever lead to a > change in the refcounts. > A > > > On Thursday, 30 May 2013 15:56:42 UTC+1, tbc++ wrote: >> >> There are two things I see that reduce the viability of ref-count GCs >> with Clojure: >> >> a) Clojure is insanely alloc heavy. Look at the source of the data >> structures, merging two hash-maps (for instance) requires about 2-3 >> allocations per assoc, per kv in the merged map: >> >> (merge map1 map2) >> allocs = ~((tree-depth of map1) * (count map2) >> >> b) Every time you transverse a persistent structure's tree you'll need to >> increment and decrement the refcounts. Consider multi-core, now the >> refcounts have to be thread safe (atomic inc & dec). So if you have two >> cores reading (not just writing) from the same hash-map, they'll be >> fighting over the cache lines that the refcount is stored in, and that'll >> kill performance. >> >> Timothy >> >> >> On Thu, May 30, 2013 at 8:47 AM, Gary Trakhman <gary.t...@gmail.com>wrote: >> >>> At first glance, those issues seem like they could be mitigated, so I >>> think I see room here for some real-time ref-counted clojure. I imagine >>> it'd still have a lot of allocations so it wouldn't be that great for >>> low-memory systems. >>> >>> >>> On Thu, May 30, 2013 at 9:44 AM, Jean Niklas L'orange < >>> jean...@hypirion.com> wrote: >>> >>>> >>>> >>>> On Thursday, May 30, 2013 2:21:36 PM UTC+2, Gary Trakhman wrote: >>>>> >>>>> I just thought about this recently, but does the value-oriented nature >>>>> of clojure mostly void the need for a cycles-aware GC? It seems like you >>>>> won't ever have cycles without identities, or pointers (java references). >>>>> Maybe this would be a problem only when you need identities, ie deftype >>>>> or >>>>> defprotocol implementing objects. >>>>> >>>> >>>> Sure thing, the value-oriented nature removes a lot of cycles in >>>> practice. However, you may for instance have an atom which contain itself, >>>> so they are not nonexistant. As such, the GC cannot be completely >>>> cycle-ignorant, but perhaps it doesn't have to be efficient at finding >>>> them >>>> either. >>>> >>>> Another place where cycles happen are in (mutually) recursive >>>> functions, they may be iffy if you define many recursive anonymous >>>> functions at runtime. >>>> >>>> -- Jean Niklas L'orange >>>> >>>> -- >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To post to this group, send email to clo...@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+u...@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 unsubscribe from this group and stop receiving emails from it, send >>>> an email to clojure+u...@googlegroups.com. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>>> >>> >>> -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@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+u...@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 unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> >> >> -- >> “One of the main causes of the fall of the Roman Empire was that–lacking >> zero–they had no way to indicate successful termination of their C >> programs.” >> (Robert Firth) >> > -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
