GC pause times are normally a function of heap size and live data (i.e. non-garbage), but can vary quite a bit depending on the exact heap layout. Looking at single pauses would not produce high confidence data, so I decided to find a benchmark with a fixed amount of live data and a fixed heap size and look at pause times for a large number of GC pauses over a long run.It turns out that the Specjbb2005 benchmark is well suited to support this type of study as long as you limit the number of warehouses. Henrik limited them to 8. The test was run on a number of Xeon and Sparc based architectures. The JVM was configured with a 2 GB heap space that was managed with a compacting mark-and-sweep GC. The results are clear, the JVM scales well with the number of cores that it has to work with. As is often the case with performance, reasoning through a problem may or may not stand up to a benchmark. Read the details here
Henrik Ståhl has written a response to the recent Billy Newport series on Multi-core may be bad for Java. One of Billy’s assertions was that Java promoted long execution paths which would not parallelize. He also stated that garbage collection remains dependent on clock speed. Henrik, a member of the JRockit team, did what any good performance engineer would do; he put Billy’s assertions to the test.
- Posted by: Kirk Pepperdine
- Posted on: December 18 2006 11:43 EST
Is multicore bad for Java? Is multicore bad for all non-parallel languages? I blog about this in detail and provide some eye-popping benchmarks of a new Java framework for building Java apps that scale 32+ cores processing 10 million records in seconds. How did the developer build this Java app? In about 1 day without using a line of concurrency API, semaphore mgmt, deadlock detection... it's all in the framework. http://www.pervasivedatarush.com/beta
That link is dead. I found the DataRush SDK here http://www.pervasivedatarush.com/downloads This looks cool, it transparently takes advantage of multi-core processors for computation intensive tasks.