On Mon, Apr 25, 2011 at 10:36 PM, Alan Cox <a...@lxorguk.ukuu.org.uk> wrote: >> One of the problems with Java Garbage Collection is that it halts >> other work in the JVM for the duration of the GC (because you're >> moving stuff around, you can't have people trying to use it). While GC >> has improved over time to reduce the amount of objects handled during >> each scan, my understanding is that it still suspends other JVM work. >> Part of GC can exploit additional CPUs when you activate the parallel >> GC (not the default). > > Thats an implementation flaw (maybe flaw is a strong word given its a > hard problem). > > Schoeberl and Puffitsch for one produced a mostly non blocking garbage > collection for Java which only blocks the threads it needs and only at the > points it has to. Rather useful for multi-threaded systems.
If it is non-blocking, why would one be concerned about the elapsed time of GC and what would be the interest of having multiple threads working in parallel on GC. Or would you really have allocation rates so high that a single thread could not keep with it? Or should we conclude that current implementations don't deploy such algorithms? Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
