Allocation of big long lived array in heap significally reduce performance of Parallel and Conc GC. In mustang parallel works fine, but Conc still very slow.

http://forum.java.sun.com/thread.jspa?messageID=3801578

See my reproduction source in attachment. SerialGC is more than 10 times faster than Conc.
java -XX:+PrintGCDetails -Xmx768m -XX:+Use<GC> gctest.Main
  xxxxx@xxxxx   2005-07-19 13:56:08 GMT

N/A

The root cause of this bug is the the block offset table (BOT) is initialized
for single card offsets in the constructor for BlockOffsetArray.  This is 
does not lead to a correctness issue.  The performance problem arises from
the free list allocation done by CMS.  If a chunk is split in order to
do an allocation, it is assumed that the BOT for the original chunk is
correct and the BOT for the remainder after the split is updated.  For
some situations (for example the first initialization of large chunks
out of the dictionary) this leaves the BOT using the single card offsets
instead of the logrithmic offsets.  This probably evertually works itself
out but is particularly obvious  in the test case for the problem.

The initialization of the BOT needs to fixed.  Since the contiguous space
version of the BOT will set the BOT for blocks as allocations move to
the right in the heap, initializing for logrithmics strides is probably
ok but that should be verified.
Posted Date : 2006-02-02 22:04:50.0

I've looked at the execution profiles for the VM
after the fix for the BOT was implemented and the
a large part of the remaining costs are in the promotion handling code.
Specifically, the code that links promoted objects together
in a list may need some work.  There was nothing there that
looked like it related specifically to big objects so this bug
is being moved to fix delivered.
Posted Date : 2006-03-14 16:49:16.0