The crash is intermittently seen in production by the customer running on Linux.  It's been reported with both 6u2 as well as 6u5.  The stack from hs_err follows:

Stack: [0x00000000,0x00000000],  sp=0xb42d8300,  free space=-1242272k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x24d99a];;  oopDesc::size_given_klass(Klass*)+0x2a
V  [libjvm.so+0x50bd7e];;  ParScanClosure::do_oop_work(oopDesc**, bool, bool)+0x
7e
V  [libjvm.so+0x50bbd6];;  ParRootScanWithBarrierTwoGensClosure::do_oop(oopDesc*
*)+0x16
V  [libjvm.so+0x34ec1e];;  instanceKlass::oop_oop_iterate_nv_m(oopDesc*, Filteri
ngClosure*, MemRegion)+0x15e
V  [libjvm.so+0x296285];;  FreeListSpace_DCTOC::walk_mem_region_with_cl_par(MemR
egion, HeapWord*, HeapWord*, FilteringClosure*)+0xd5
V  [libjvm.so+0x29617f];;  FreeListSpace_DCTOC::walk_mem_region_with_cl(MemRegio
n, HeapWord*, HeapWord*, FilteringClosure*)+0x3f
V  [libjvm.so+0x56f900];;  Filtering_DCTOC::walk_mem_region(MemRegion, HeapWord*
, HeapWord*)+0x50
V  [libjvm.so+0x56f74f];;  DirtyCardToOopClosure::do_MemRegion(MemRegion)+0xcf
V  [libjvm.so+0x24f73b];;  ClearNoncleanCardWrapper::do_MemRegion(MemRegion)+0xa
b
V  [libjvm.so+0x24e721];;  CardTableModRefBS::non_clean_card_iterate_work(MemReg
ion, MemRegionClosure*, bool)+0x141
V  [libjvm.so+0x5072ee];;  CardTableModRefBS::process_stride(Space*, MemRegion,
int, int, DirtyCardToOopClosure*, MemRegionClosure*, bool, signed char**, unsign
ed, unsigned)+0xfe
V  [libjvm.so+0x50718f];;  CardTableModRefBS::par_non_clean_card_iterate_work(Sp
ace*, MemRegion, DirtyCardToOopClosure*, MemRegionClosure*, bool, int)+0xaf
V  [libjvm.so+0x24e5ab];;  CardTableModRefBS::non_clean_card_iterate(Space*, Mem
Region, DirtyCardToOopClosure*, MemRegionClosure*, bool)+0x4b
V  [libjvm.so+0x24effc];;  CardTableRS::younger_refs_in_space_iterate(Space*, Oo
psInGenClosure*)+0x5c
V  [libjvm.so+0x32e51c];;  Generation::younger_refs_in_space_iterate(Space*, Oop
sInGenClosure*)+0x1c
V  [libjvm.so+0x2b3af0];;  ConcurrentMarkSweepGeneration::younger_refs_iterate(O
opsInGenClosure*)+0x40
V  [libjvm.so+0x24ef28];;  CardTableRS::younger_refs_iterate(Generation*, OopsIn
GenClosure*)+0x28
V  [libjvm.so+0x322b10];;  GenCollectedHeap::gen_process_strong_roots(int, bool,
 bool, SharedHeap::ScanningOption(OopsInGenClosure*, void))+0x70
V  [libjvm.so+0x509bc7];;  ParNewGenTask::work(int)+0xc7
V  [libjvm.so+0x5ffb63];;  GangWorker::loop()+0xa3
V  [libjvm.so+0x5ffa78];;  GangWorker::run()+0x18
V  [libjvm.so+0x4fde19];;  java_start(Thread*)+0x139
C  [libpthread.so.0+0x4dd8]

We've collected several hs_err logs from the customer and the stack seems very close in all of them.

The customer has tried the workaround mentioned in CR 6642634 of setting -Xmx == -Xms and -XX:PermSize == -XX:MaxPermSize but they still reported getting crashes. 

We've asked the customer to try removing -XX:+UseBiasedLocking and to let us know whether or not they continue to see crashes.

Cu also reports that this application was stable running under 1.5.0_10.