CMS Sudden long pauses with large number of weak references

Greg Bowyer gbowyer at fastmail.co.uk
Thu Jan 19 13:37:00 PST 2012


Hi all

I have an application that is solr/lucene running on JDK 1.6 / 1.7 with 
CMS, 9Gb heap. The only unusual options here are DisableExplictGC and 
UseCompressedOops (which I do not think are the issue).

Generally the application has a heap usage of ~4G with a 2-3G float of 
continual garbage on top.

The application creates several large heap objects, some of these are 
sizeable arrays (~300mb), some of these are objects that have large 
retained graphs.

One of these is a WeakHashMap that in lucene stores IndexReaders (as the 
key) -> "Fields", this mapping is used to avoid disk access, there are 
not typically a large number of readers open at any time (at worst this 
could be say 25).

Generally we see the GC behavior being fairly solid across JVMS, however 
we get ever increasing amounts of concurrent-mode-failues with a marked 
spike of weak references, this only seems to appear when new indexes 
load on lucene, which is when the references are changed and when new 
versions of these caches are created.

---- %< ----
4747.399: [GC 4747.399: [ParNew4747.492: [SoftReference, 0 refs, 
0.0000120 secs]4747.492: [WeakReference, 5 refs, 0.0000050 
secs]4747.492: [FinalReference, 0 refs, 0.0000040 secs]4747.492: 
[PhantomReference, 0 refs, 0.0000030 secs]4747.492: [JNI Weak Reference, 
0.0000020 secs]: 133242K->11776K(153344K), 0.0925850 secs] 
7199972K->7187397K(9420160K), 0.0926840 secs] [Times: user=0.72 
sys=0.00, real=0.09 secs]
Total time for which application threads were stopped: 0.0931920 seconds
4747.530: [GC [1 CMS-initial-mark: 7175620K(9266816K)] 
7300153K(9420160K), 0.0044900 secs] [Times: user=0.00 sys=0.00, 
real=0.00 secs]
Total time for which application threads were stopped: 0.0398160 seconds
4747.535: [CMS-concurrent-mark-start]
4747.537: [GC 4747.537: [ParNew4747.568: [SoftReference, 0 refs, 
0.0000120 secs]4747.568: [WeakReference, 6 refs, 0.0000060 
secs]4747.568: [FinalReference, 0 refs, 0.0000040 secs]4747.568: 
[PhantomReference, 0 refs, 0.0000040 secs]4747.568: [JNI Weak Reference, 
0.0000020 secs] (promotion failed): 127253K->127965K(153344K), 0.0315280 
secs]4747.569: [CMS4755.725: [CMS-concurrent-mark: 8.157/8.190 secs] 
[Times: user=10.81 sys=3.49, real=8.19 secs]
  (concurrent mode failure)4757.436: [SoftReference, 0 refs, 0.0000050 
secs]4757.436: [WeakReference, 6360 refs, 0.0016500 secs]4757.437: 
[FinalReference, 462 refs, 0.0088580 secs]4757.446: [PhantomReference, 
114 refs, 0.0000220 secs]4757.446: [JNI Weak Reference, 0.0000070 secs]: 
7180161K->3603572K(9266816K), 17.1070460 secs] 
7302874K->3603572K(9420160K), [CMS Perm : 47059K->47044K(78380K)], 
17.1387610 secs] [Times: user=19.75 sys=3.49, real=17.14 secs]
Total time for which application threads were stopped: 17.1393510 seconds
Total time for which application threads were stopped: 0.0245300 seconds
---- >% ----

? Is this due to the defects fixed here 
http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f1391adc6681, 
would -XX:+ParallelRefProcEnabled help here ?

Also is there anything that could explain the large number of suddenly 
processed and traced weak-references

Many thanks
-- Greg


More information about the hotspot-gc-use mailing list