There's no magic here, everyone tuning their app hit this wall eventually, tweaking the JVM memory options :)
Luc > > On Dec 9, 2012, at 6:25 AM, Softaddicts wrote: > > > If the number of object allocation mentioned earlier in this thread are > > real, > > yes vm heap management can be a bottleneck. There has to be some > > locking done somewhere otherwise the heap would corrupt :) > > > > The other bottleneck can come from garbage collection which has to freeze > > object allocation completely or partially. > > > > This internal process has to reclaim unreferenced objects otherwise you may > > end up > > exhausting the heap. That can even susoend your app while gc is running > > depending > > on the strategy used. > > Agreed that memory allocation and garbage collection will in some cases need > to coordinate between threads to work in the general case of arbitrary > allocations and GCs. > > However, one could have a central list of large "pages" of free memory (e.g. > a few MBytes, or maybe even larger), and pass these out to concurrent memory > allocators in these large chunks, and let them do small object allocations > and GC within each thread completely concurrently. > > The only times locking of any kind might be needed with such a strategy would > be when one of the parallel threads requests a new big page from the central > free list, or returned a completely empty free page back to the central list > that it didn't need any more. All other memory allocation and GC could be > completely concurrent. The idea of making those "pages" large is that such > passing pages around would be infrequent, and thus could be made to have no > measurable synchronization overhead. > > That is pretty much what is happening when you run Lee's benchmark programs > as 1 thread per JVM, but 4 or 8 different JVMs processes running in parallel. > In that situation the OS has the central free list of pages, and the JVMs > manage their small object allocations and GCs completely concurrently without > interfering with each other. > > If HotSpot's JVM could be configured to work like that, he would be seeing > big speedups in a single JVM. > > Andy > > -- > 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 > -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- 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
