On Tue, Dec 22, 2009 at 8:43 PM, mac <markus.gustavs...@gmail.com> wrote: > >> You might run into the problem than any C++ garbage collector you find >> will probably not be quite as efficient as the JVM's garbage collector >> (I don't think it would be possible to implement Clojure without a >> GC). Additionally, a lot of Clojure's concurrency features rely on >> Java's concurrency mechanisms and how these are mapped to the JVM's >> concurrency semantics and memory model, for which you will also have >> to find a suitable C++ library. > > Yes, if you want to port Clojure to native code it might be easier to > use a host language that already has these features but closely > resembles C++. > Candidates are D and the new Google Go. > Go in particular seems interesting because one of their goals is to > make a very efficient GC and the language is somewhat multicore aware.
Is the generic GC the best tool for managing persistent data structures? I imagine that each such data structure could be, for example, stored in a separate circular data buffer (so that new chunks can overwrite old ones without an added effort from the GC). Clojure exercises GC quite a lot but it does that in a somewhat predictable manner (uses a lot of linked data structures). In contrast, standard GC's are tuned for managing a smaller number of irregular and relatively independent objects. Maybe writing a custom GC is not that bad idea at all? Andrzej -- 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
