Thanks for this! I do see now that it's probably a little trickier than I first thought :) Still, like you, I am left with the feeling it might be possible to do well...
On Thursday, 30 May 2013 21:25:27 UTC+1, Gary Trakhman wrote: > > Well, ref-counting in C++ is used by something like smart-pointers, the > implementation uses operator overloading to overload the pointer > dereference operator *, and it manages an internal pointer to the actual > value. Instantiating a smart-pointer increases the count for that object, > and once that smart-pointer object goes out of scope (free/delete or > popping off the stack), it'll automatically decrement the ref count again > by action of its destructor. > > The thing I'm proposing would use something like that, by my > understanding, and data structures could either be implemented in native > bits or further up once deftypes and protocols are defined on top of > something like this. > > So, in order to actually read from a memory value and guarantee that the > object still exists, you have to allocate a wrapper that manages these > reference counts. HTH. > > On Thu, May 30, 2013 at 4:00 PM, atucker <agjf....@gmail.com <javascript:> > > 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<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<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<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<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 clo...@googlegroups.com<javascript:> >> 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 <javascript:> >> 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 <javascript:>. >> 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 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.
