On Feb 14, 10:00 am, Christian Vest Hansen <karmazi...@gmail.com> wrote: > You run into problems with the garbage collector when the heap gets > big: the bigger the heap, the longer it takes to compact. Azul has > hardware support for their garbage collector which allows their > compaction phase to run concurrently with the application, otherwise > there'd be no way they could make use of the 768 GB ram their kit can > scale to, unless striped across hundreds of JVMs. If you try to scale > a normal collector to those heap sizes, you will see your > stop-the-world collections jump from sub-second to minutes or even > hours.
*nods* It's not even clear that one would want to use memory as a single shared blob for that many processors and that much memory. I would prefer a partitioned global address space like that used by Titanium (http://titanium.cs.berkeley.edu/), UPC (http:// upc.lbl.gov/), or Global Arrays (http://www.emsl.pnl.gov/docs/ global/). If you can distinguish between "local" and "far-away" chunks of memory, it's easier to do garbage collection more efficiently. mfh --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
