February 2010 - hotspot-gc-dev

hg: jdk7/hotspot-gc/hotspot: 2 new changesets
by antonios.printezis＠sun.com 24 Feb '10

24 Feb '10

Changeset: b81f3572f355 Author: tonyp Date: 2010-02-23 23:13 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b81f3572f355 6928059: G1: command line parameter renaming Summary: Rename G1 parameters to make them more consistent. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 1c72304f1885 Author: tonyp Date: 2010-02-23 23:14 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1c72304f1885 6928073: G1: use existing command line parameters for marking cycle initiation Summary: replace the combination of the G1SteadyStateUsed / G1SteadyStateUsedDelta parameteres to decide the marking initiation threshold and instead use InitiatingHeapOccupancyPercent. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp

1 0

Re: G1 is bad for me
by Y. Srinivas Ramakrishna 22 Feb '10

22 Feb '10

Sorry, we haven't responded in depth because we are busy with other high priority stuff. Please follow up with your support contacts for urgent issues. If you subscribe to hotspot-gc-dev(a)openjdk.java.net you will get all G1 integration notifications; those then usually flow into the next JDK7 build in the subsequent week or two. regards. -- ramki Andrei Pozolotin wrote: > Tony, Ramki, Jon, hello; > > 1) I take it that you silence means that "we are not there yet" with G1; > understandable - thank you for your efforts! > > 2) there are some 82 people on this mail list who seem to be really > interested > in GC and G1 specifically; can I ask to you to make brief > announcements here > when JDK 7 weekly build brings some new G1 advances, so we can test > it right away? > > Thank you; > > Andrei > > > -------- Original Message -------- > Subject: Re: G1 is bad for me > From: Y. Srinivas Ramakrishna <Y.S.Ramakrishna(a)Sun.COM> > To: Andrei Pozolotin <andrei.pozolotin(a)gmail.com> > Cc: hotspot-gc-use(a)openjdk.java.net > Date: Thu 18 Feb 2010 11:37:56 AM CST >> Hi Andrei -- please use the latest hs17 JVM which you can get from JDK >> 7. There have been >> many improvements (and bug fixes) since the 6u18/hs16 that you are >> using below. >> Most importantly, please add -XX:-ReduceInitialCardMarks to work >> around a regression >> introduced in 6u18/hs16, as described in the 6u18 release notes. >> As re optimal settings (these may be quite different from shapes that >> helped with CMS >> for example), i'll let others w/more (tuning and other) experience >> w/G1 comment. >> >> -- ramki >> >> On 02/18/10 08:56, Andrei Pozolotin wrote: >>> Ramki, Jon, hi; >>> >>> I read everyting I could find on G1: >>> http://www.google.com/patents/about?id=j5SpAAAAEBAJ&dq=7,340,494 >>> >>> http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-5419.pdf >>> http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf >>> http://blogs.sun.com/sunabl/entry/the_new_g1_collector >>> http://blogs.sun.com/jonthecollector/entry/our_collectors >>> etc, etc, etc, >>> >>> got myself excited - looks great on paper! >>> >>> and I followed Albert's advice, while trying to mimic my CMS >>> settings: >>> http://blogs.sun.com/sunabl/entry/the_new_g1_collector >>> >>> -Xms3700m >>> -Xmx3700m >>> -XX:PermSize=50m >>> -XX:MaxPermSize=50m >>> -XX:+UnlockExperimentalVMOptions >>> -XX:+UseG1GC >>> -XX:G1YoungGenSize=900m >>> -XX:SurvivorRatio=2 >>> -XX:+G1ParallelRSetUpdatingEnabled >>> -XX:+G1ParallelRSetScanningEnabled >>> >>> results: >>> >>> 1) pauses are 1000 milliseconds or more; >>> >>> 2) reproducible crashes after 3 minutes under load; >>> >>> logs attached; >>> >>> am I missing something obvious? >>> like do I need to switch to older / specific JVM build? >>> >>> per Tony, this was already working fine for a neighbour of mine >>> in 2008: >>> >>> http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-5419.pdf >>> >>> Thank you; >>> >>> Andrei >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> hotspot-gc-use mailing list >>> hotspot-gc-use(a)openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use(a)openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

1 0

Re: G1 is bad for me
by Jon Masamitsu 19 Feb '10

19 Feb '10

Chi Ho Kwok wrote On 02/19/10 06:59,: > Hi all, > > A large part of our CPU load is caused by GC, so I'm always interested > in new techniques, but the last time I tried G1 (6u14?), the jvm > rapidly crashed after startup under load. Is the recommendation to > switch to/wait for JDK7 releases for G1, or is G1 on 6u18 (or later?) > any good for production usage? I'd assume there will be more updates > for JDK6 as JDK7 got extended to up to 10 milestones. G1 is in 6u18 but it is still an experimental collector. It's definitely better but if you try it add the flag -XX:-ReduceInitialCardMarks to work around regression that escaped in 6u18. > > CMS with a 32G heap which changes rapidly (~10%/min replaced) is > manageable, but we're "losing" 20% capacity because the threshold has > to be so low, anything higher than 80% causes new gen promotions to > fail during CMS and the app to stop for half a minute. Processing > capacity is also reduced by half during a CMS run because the amount > of threads has to be high (=6 at the moment) to make it hurry up, or > it'll mean either setting the threshold even lower or risk promotion > failures :( If you're running into fragmentation, then either you start the CMS cycles early (as it appears you do) or use a larger heap (if you can). There an RFE in jdk 7 (6631166) that helps with fragmentation in some applications. It's not in a jdk 6 yet. If you're a Java-4-business customer, contact your Sun/Oracle support person and talk to them about getting that RFE. If your application is allocating objects at a high rate and CMS has to do lots of processing to keep up (might be the case if you're using 6 GC threads to do the concurrent marking in parallel), then the overhead may just be what's required to collect all that garbage. Again, if you're a Java-4-business customer, talk to your support person to see if you can get some help in analyzing your situation. > > Chi Ho Kwok > > On Thu, Feb 18, 2010 at 6:37 PM, Y. Srinivas Ramakrishna > <Y.S.Ramakrishna(a)sun.com <mailto:Y.S.Ramakrishna@sun.com>> wrote: > > Hi Andrei -- please use the latest hs17 JVM which you can get from > JDK 7. There have been > many improvements (and bug fixes) since the 6u18/hs16 that you are > using below. > Most importantly, please add -XX:-ReduceInitialCardMarks to work > around a regression > introduced in 6u18/hs16, as described in the 6u18 release notes. > As re optimal settings (these may be quite different from shapes > that helped with CMS > for example), i'll let others w/more (tuning and other) experience > w/G1 comment. > > -- ramki > >------------------------------------------------------------------------ > >_______________________________________________ >hotspot-gc-use mailing list >hotspot-gc-use(a)openjdk.java.net >http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use(a)openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

1 0

Re: G1 is bad for me
by Y. Srinivas Ramakrishna 18 Feb '10

18 Feb '10

Hi Andrei -- please use the latest hs17 JVM which you can get from JDK 7. There have been many improvements (and bug fixes) since the 6u18/hs16 that you are using below. Most importantly, please add -XX:-ReduceInitialCardMarks to work around a regression introduced in 6u18/hs16, as described in the 6u18 release notes. As re optimal settings (these may be quite different from shapes that helped with CMS for example), i'll let others w/more (tuning and other) experience w/G1 comment. -- ramki On 02/18/10 08:56, Andrei Pozolotin wrote: > Ramki, Jon, hi; > > I read everyting I could find on G1: > http://www.google.com/patents/about?id=j5SpAAAAEBAJ&dq=7,340,494 > http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-5419.pdf > http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf > http://blogs.sun.com/sunabl/entry/the_new_g1_collector > http://blogs.sun.com/jonthecollector/entry/our_collectors > etc, etc, etc, > > got myself excited - looks great on paper! > > and I followed Albert's advice, while trying to mimic my CMS settings: > http://blogs.sun.com/sunabl/entry/the_new_g1_collector > > -Xms3700m > -Xmx3700m > -XX:PermSize=50m > -XX:MaxPermSize=50m > -XX:+UnlockExperimentalVMOptions > -XX:+UseG1GC > -XX:G1YoungGenSize=900m > -XX:SurvivorRatio=2 > -XX:+G1ParallelRSetUpdatingEnabled > -XX:+G1ParallelRSetScanningEnabled > > results: > > 1) pauses are 1000 milliseconds or more; > > 2) reproducible crashes after 3 minutes under load; > > logs attached; > > am I missing something obvious? > like do I need to switch to older / specific JVM build? > > per Tony, this was already working fine for a neighbour of mine in 2008: > http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-5419.pdf > > Thank you; > > Andrei > > > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use(a)openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use(a)openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

1 0

Re: Incremental CMS: long "[GC [1 CMS-initial-mark:"
by Jon Masamitsu 17 Feb '10

17 Feb '10

> From: Andrei Pozolotin <andrei.pozolotin(a)gmail.com> > Date: February 17, 2010 3:42:14 PM PST > To: ysr(a)Sun.COM > Cc: hotspot-gc-use(a)openjdk.java.net > Subject: Re: Incremental CMS: long "[GC [1 CMS-initial-mark:" > > > Ramki, hello again; > > 1) "unfortunately" - got it; thank you; > > 2) thanks for G1 idea; will try now; > > 3) it does not seem gchisto / visualvm can see G1 at all; > can you please recommend a tool that can help with G1 tuning? Yes, sadly, gchisto has not been updated to parse the G1 style of logging. The work is probably in part to add to/change the G1 logging to be more like the other collectors and then to update gchisto. That's my guess and since its still a guess, we're not close to getting there. > > Cheers, > > Andrei _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use(a)openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

1 0

long unaccounted pause during concurrent mark phase of ParNew cycle
by atulksh 17 Feb '10

17 Feb '10

Hi, We have an application that is freezing (pausing) for a very long (tens of seconds) time during the concurrent mark phase of the ParNew cycle. This pause is consistently seen when there is good amount of activity on the server. We tried to upgrade the JVM (JRE 6) from Update 02 to Update 17 keeping all the parameters same, but the pauses did not go away (they became more consistent and slightly longer). We even tried to enable CompressedOops option, thinking that that would reduce memory requirements, but that has not helped. We are running on 64bit SUSE 10.1 platform with 32Gb of RAM and 8 core machine. 26g is allocated to the java process. The full set of VM parameters are here -Xmx26g -Xms26g -server -XX:+UseConcMarkSweepGC -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:CMSInitiatingOccupancyFraction=70 -XX:-CMSParallelRemarkEnabled The nature of the pause is like this. All the application threads that are being processed seem to stop responding. New requests that come to our app server are not processed and get queued. When the pause ends then everything frees up and seems to go on normally henceforth. In the GC you see a gap between the ParNews. The following are two examples of the pauses. Notice the pause from 10:13:06 to 10:13:35 (29 seconds) in the first one and 11:29:04 to 11:29:17 (13 seconds) in the second one. These pauses only occur in the concurrent mark phase. They do not seem to occur at any other time or anywhere else in the CMS cycle. .... Thu Feb 4 10:12:59 2010: [GC [1 CMS-initial-mark: 18976170K(27092608K)] 18989786K(27245952K), 0.0059140 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] Thu Feb 4 10:12:59 2010: [CMS-concurrent-mark-start] Thu Feb 4 10:12:59 2010 [18,980,009 K]: [GC 42035.293: [ParNew Desired survivor size 8716288 bytes, new threshold 4 (max 4) - age 1: 1833064 bytes, 1833064 total - age 2: 18472 bytes, 1851536 total : 148315K->3839K(153344K), 0.0400230 secs] 19124486K->18980009K(27245952K), 0.0401580 secs] [Times: user=0.25 sys=0.00, real=0.04 secs] Thu Feb 4 10:12:59 2010 [18,979,036 K]: [GC 42035.415: [ParNew Desired survivor size 8716288 bytes, new threshold 4 (max 4) - age 1: 2068376 bytes, 2068376 total - age 2: 23792 bytes, 2092168 total - age 3: 18472 bytes, 2110640 total : 140159K->2866K(153344K), 0.0352200 secs] 19116329K->18979036K(27245952K), 0.0353520 secs] [Times: user=0.29 sys=0.00, real=0.03 secs] Thu Feb 4 10:12:59 2010 [18,979,103 K]: [GC 42035.535: [ParNew Desired survivor size 8716288 bytes, new threshold 4 (max 4) - age 1: 1782608 bytes, 1782608 total - age 2: 22032 bytes, 1804640 total - age 3: 23792 bytes, 1828432 total - age 4: 18472 bytes, 1846904 total : 139186K->2933K(153344K), 0.0498480 secs] 19115356K->18979103K(27245952K), 0.0499850 secs] [Times: user=0.24 sys=0.00, real=0.05 secs] Thu Feb 4 10:12:59 2010 [18,979,181 K]: [GC 42035.673: [ParNew Desired survivor size 8716288 bytes, new threshold 4 (max 4) - age 1: 2161000 bytes, 2161000 total - age 2: 22032 bytes, 2183032 total - age 3: 22032 bytes, 2205064 total - age 4: 23792 bytes, 2228856 total : 139253K->2992K(153344K), 0.0400420 secs] 19115423K->18979181K(27245952K), 0.0401730 secs] [Times: user=0.26 sys=0.00, real=0.04 secs] Thu Feb 4 10:13:06 2010 [18,979,876 K]: [GC 42042.243: [ParNew Desired survivor size 8716288 bytes, new threshold 4 (max 4) - age 1: 2113272 bytes, 2113272 total - age 2: 23792 bytes, 2137064 total - age 3: 22032 bytes, 2159096 total - age 4: 22032 bytes, 2181128 total : 138855K->3662K(153344K), 0.0465500 secs] 19115044K->18979876K(27245952K), 0.0466840 secs] [Times: user=0.27 sys=0.00, real=0.04 secs] Thu Feb 4 10:13:35 2010 [18,979,051 K]: [GC 42071.809: [ParNew Desired survivor size 8716288 bytes, new threshold 4 (max 4) - age 1: 219056 bytes, 219056 total - age 2: 1867632 bytes, 2086688 total - age 3: 23792 bytes, 2110480 total - age 4: 22032 bytes, 2132512 total : 139982K->2814K(153344K), 0.0426920 secs] 19116196K->18979051K(27245952K), 0.0428200 secs] [Times: user=0.28 sys=0.00, real=0.05 secs] Thu Feb 4 10:13:35 2010: [CMS-concurrent-mark: 36.272/36.715 secs] [Times: user=56.34 sys=0.34, real=36.71 secs] .... .... Thu Feb 4 11:28:59 2010: [GC [1 CMS-initial-mark: 19012252K(27092608K)] 19032719K(27245952K), 0.0279440 secs] [Times: user=0.02 sys=0.00, real=0.03 secs] Thu Feb 4 11:28:59 2010: [CMS-concurrent-mark-start] Thu Feb 4 11:28:59 2010 [19,154,661 K]: [GC 46595.614: [ParNew Desired survivor size 8716288 bytes, new threshold 1 (max 4) - age 1: 17431976 bytes, 17431976 total : 153344K->17024K(153344K), 0.9259390 secs] 19165596K->19154661K(27245952K), 0.9260890 secs] [Times: user=1.23 sys=0.05, real=0.93 secs] Thu Feb 4 11:29:00 2010 [19,199,696 K]: [GC 46596.973: [ParNew Desired survivor size 8716288 bytes, new threshold 1 (max 4) - age 1: 17448432 bytes, 17448432 total : 153344K->17024K(153344K), 0.3054460 secs] 19290981K->19199696K(27245952K), 0.3055930 secs] [Times: user=0.79 sys=0.07, real=0.31 secs] Thu Feb 4 11:29:01 2010 [19,229,358 K]: [GC 46597.722: [ParNew Desired survivor size 8716288 bytes, new threshold 1 (max 4) - age 1: 10331408 bytes, 10331408 total : 153344K->17024K(153344K), 0.1449040 secs] 19336016K->19229358K(27245952K), 0.1450630 secs] [Times: user=0.59 sys=0.02, real=0.15 secs] Thu Feb 4 11:29:02 2010 [19,240,015 K]: [GC 46598.038: [ParNew Desired survivor size 8716288 bytes, new threshold 1 (max 4) - age 1: 17354120 bytes, 17354120 total : 153344K->17024K(153344K), 0.0935440 secs] 19365678K->19240015K(27245952K), 0.0936870 secs] [Times: user=0.59 sys=0.00, real=0.10 secs] Thu Feb 4 11:29:02 2010 [19,302,509 K]: [GC 46598.347: [ParNew Desired survivor size 8716288 bytes, new threshold 1 (max 4) - age 1: 17432360 bytes, 17432360 total : 151519K->17024K(153344K), 0.4619430 secs] 19374510K->19302509K(27245952K), 0.4620890 secs] [Times: user=1.19 sys=0.02, real=0.46 secs] Thu Feb 4 11:29:03 2010 [19,329,594 K]: [GC 46599.030: [ParNew Desired survivor size 8716288 bytes, new threshold 1 (max 4) - age 1: 11933296 bytes, 11933296 total : 153344K->17024K(153344K), 0.1492670 secs] 19438829K->19329594K(27245952K), 0.1494200 secs] [Times: user=0.77 sys=0.03, real=0.15 secs] Thu Feb 4 11:29:03 2010 [19,337,176 K]: [GC 46599.423: [ParNew Desired survivor size 8716288 bytes, new threshold 4 (max 4) - age 1: 5719032 bytes, 5719032 total : 153344K->12852K(153344K), 0.0675180 secs] 19465914K->19337176K(27245952K), 0.0676670 secs] [Times: user=0.46 sys=0.02, real=0.07 secs] Thu Feb 4 11:29:03 2010 [19,338,256 K]: [GC 46599.754: [ParNew Desired survivor size 8716288 bytes, new threshold 2 (max 4) - age 1: 6783616 bytes, 6783616 total - age 2: 5570080 bytes, 12353696 total : 149172K->13931K(153344K), 0.0650520 secs] 19473496K->19338256K(27245952K), 0.0652060 secs] [Times: user=0.42 sys=0.01, real=0.07 secs] Thu Feb 4 11:29:04 2010 [19,340,264 K]: [GC 46600.144: [ParNew Desired survivor size 8716288 bytes, new threshold 2 (max 4) - age 1: 2190136 bytes, 2190136 total - age 2: 6762648 bytes, 8952784 total : 150251K->10375K(153344K), 0.0709470 secs] 19474576K->19340264K(27245952K), 0.0710920 secs] [Times: user=0.48 sys=0.01, real=0.07 secs] Thu Feb 4 11:29:17 2010 [19,345,928 K]: [GC 46613.628: [ParNew Desired survivor size 8716288 bytes, new threshold 4 (max 4) - age 1: 760488 bytes, 760488 total - age 2: 2173472 bytes, 2933960 total : 146695K->9279K(153344K), 0.0689390 secs] 19476584K->19345928K(27245952K), 0.0691070 secs] [Times: user=0.45 sys=0.00, real=0.07 secs] Thu Feb 4 11:29:17 2010: [CMS-concurrent-mark: 15.853/18.260 secs] [Times: user=29.26 sys=0.55, real=18.26 secs] Thu Feb 4 11:29:17 2010: [CMS-concurrent-preclean-start] .... Any idea what may causing these pauses and what possible JVM tuning would be neccessary to avoid these pauses? Your help greatly appreciated. Thank you very much. Atul -- View this message in context: http://old.nabble.com/long-unaccounted-pause-during-concurrent-mark-phase-o… Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com.

3 12

Re: Incremental CMS: long "[GC [1 CMS-initial-mark:"
by Y. Srinivas Ramakrishna 17 Feb '10

17 Feb '10

On 02/17/10 14:57, Andrei Pozolotin wrote: > Ramki, hi > > Thank you for quick response; > > from reading JDK 6 source I deluded myself that the problem you > describe: > > "... occurs sometime between two scavenges ..." > > would get fixed by these options: > > wrapper.java.additional.175=-XX:+CMSParallelRemarkEnabled > wrapper.java.additional.176=-XX:+CMSScavengeBeforeRemark > wrapper.java.additional.177=-XX:CMSIncrementalOffset=10 > wrapper.java.additional.178=-XX:CMSScheduleRemarkEdenPenetration=5 > > please confirm I was wrong? Yes, unfortunately, those are in some sense orthogonal to the way CMS "incrementalizes" its working, here (somewhat relatedly see [1]) For example, CMSScavengeBeforeRemark does indeed schedule a scavenge before a remark pause, but not (unfortunately) before an initial mark pause. Similarly the CMSScheduleRemarkEdenPenetration controls the scheduling of remark pauses, not the initial mark pauses. As for CMSIncrementalOffset, it is just a constant positive delta applied to the ideal starting point for a given duty cycle. So, in fact, any positive value will take you further away from the objective you are trying to achieve here of reducing the occupancy of Eden when initial mark hits. Try G1, that may save you filing an RFE on (i)CMS for this. Honestly though, there is an existing blanket RFE on this: 6412968 CMS: Long initial mark pauses but it has not risen to the top of our list of things to fix. If this is important, please contact your Java support.... -- ramki [1] 6518192 iCMS: smoother, duration-bounded incrementality > Cheers, > > Andrei > > > > -------- Original Message -------- > Subject: Re: Incremental CMS: long "[GC [1 CMS-initial-mark:" > From: Y. Srinivas Ramakrishna <Y.S.Ramakrishna(a)Sun.COM> > To: Andrei Pozolotin <andrei.pozolotin(a)gmail.com> > Cc: hotspot-gc-use(a)openjdk.java.net > Date: Wed 17 Feb 2010 04:42:34 PM CST >> On 02/17/10 14:28, Andrei Pozolotin wrote: >>> *Jon, *hello; >>> >>> I need to convert CMS into incremental CMS to reduce latency, >>> eliminate occasional "concurrent mode failure" - related pauses; >>> >>> and I am running into the following problem: >>> >>> 1) in "normal CMS" - [GC [1 CMS-initial-mark: takes 50 milliseconds >>> >>> 2) in "incremental CMS" - [GC [1 CMS-initial-mark: takes 800 >>> milliseconds >> >> This is to be expected and is a consequence of how and when >> the initial mark is done in "normal" vs "incremental". >> In the former, the initial mark almost immediately follows >> after a scavenge pause and Eden is empty. In the latter case >> it normally occurs sometime between two scavenges by which time >> Eden has objects in it. For various reasons, the young gen >> is scanned as a source of initial roots to mark from, >> and for various reasons it is currently the case that this >> work is done single-threaded. >> >> As you will find, the magnitude of this difference typically >> depends (among other factors) on the size of Eden you specify >> (being directly proportional to it) and the duty cycle you >> specify (being inversely proportional to it). >> >> There are ways to fix this in the JVM, but no real workaround that >> i can think of at the command-line level. >> >> If this is important, please file a bug on this via your >> support contacts. >> >> thanks! >> -- ramki >> >>> >>> both above results are under same no-load conditions, >>> with non-reducible statuc heap object set of 430 MB >>> composed of some 350K complex objects; >>> >>> I can not understand why and how to fix it; >>> I tried a lot of Incremental CMS - related option combinations, >>> still dead end. >>> >>> GC settings, log attached; >>> >>> Thank you for your help, >>> >>> Andrei >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> # use server-style JIT compiler >>> wrapper.java.additional.100=-server >>> >>> # do GC logging >>> wrapper.java.additional.110=-verbose:gc >>> wrapper.java.additional.111=-Xloggc:./logs/gc.log >>> wrapper.java.additional.112=-XX:+PrintGCDetails >>> wrapper.java.additional.113=-XX:+PrintGCTimeStamps >>> >>> # Heap Total = PermGen + NewGen + OldGen; >>> wrapper.java.additional.120=-Xms3700m >>> wrapper.java.additional.121=-Xmx3700m >>> >>> # PermGen; >>> wrapper.java.additional.130=-XX:PermSize=50m >>> wrapper.java.additional.131=-XX:MaxPermSize=50m >>> >>> # NewGen; Parallel collector; >>> wrapper.java.additional.140=-XX:NewSize=1200m >>> wrapper.java.additional.141=-XX:MaxNewSize=1200m >>> wrapper.java.additional.142=-XX:-UseAdaptiveSizePolicy >>> wrapper.java.additional.143=-XX:SurvivorRatio=1 >>> wrapper.java.additional.144=-XX:TargetSurvivorRatio=90 >>> wrapper.java.additional.145=-XX:MaxTenuringThreshold=3 >>> wrapper.java.additional.146=-XX:+UseParNewGC >>> wrapper.java.additional.147=-XX:-UseParallelGC >>> wrapper.java.additional.148=-XX:ParallelGCThreads=4 >>> >>> # OldGen; Incremental CMS collector; >>> wrapper.java.additional.170=-XX:-UseParallelOldGC >>> wrapper.java.additional.171=-XX:+UseConcMarkSweepGC >>> wrapper.java.additional.172=-XX:+CMSIncrementalMode >>> wrapper.java.additional.173=-XX:-CMSIncrementalPacing >>> wrapper.java.additional.174=-XX:CMSIncrementalDutyCycle=1 >>> wrapper.java.additional.175=-XX:+CMSParallelRemarkEnabled >>> wrapper.java.additional.176=-XX:+CMSScavengeBeforeRemark >>> wrapper.java.additional.177=-XX:CMSIncrementalOffset=10 >>> wrapper.java.additional.178=-XX:CMSScheduleRemarkEdenPenetration=5 >>> wrapper.java.additional.179=-XX:CMSWaitDuration=60000 >>> wrapper.java.additional.181=-XX:ParallelCMSThreads=1 >>> wrapper.java.additional.182=-XX:PrintCMSStatistics=0 >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> hotspot-gc-use mailing list >>> hotspot-gc-use(a)openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> >> > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use(a)openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

1 0

Re: Incremental CMS: long "[GC [1 CMS-initial-mark:"
by Y. Srinivas Ramakrishna 17 Feb '10

17 Feb '10

On 02/17/10 14:28, Andrei Pozolotin wrote: > *Jon, *hello; > > I need to convert CMS into incremental CMS to reduce latency, > eliminate occasional "concurrent mode failure" - related pauses; > > and I am running into the following problem: > > 1) in "normal CMS" - [GC [1 CMS-initial-mark: takes 50 milliseconds > > 2) in "incremental CMS" - [GC [1 CMS-initial-mark: takes 800 > milliseconds This is to be expected and is a consequence of how and when the initial mark is done in "normal" vs "incremental". In the former, the initial mark almost immediately follows after a scavenge pause and Eden is empty. In the latter case it normally occurs sometime between two scavenges by which time Eden has objects in it. For various reasons, the young gen is scanned as a source of initial roots to mark from, and for various reasons it is currently the case that this work is done single-threaded. As you will find, the magnitude of this difference typically depends (among other factors) on the size of Eden you specify (being directly proportional to it) and the duty cycle you specify (being inversely proportional to it). There are ways to fix this in the JVM, but no real workaround that i can think of at the command-line level. If this is important, please file a bug on this via your support contacts. thanks! -- ramki > > both above results are under same no-load conditions, > with non-reducible statuc heap object set of 430 MB > composed of some 350K complex objects; > > I can not understand why and how to fix it; > I tried a lot of Incremental CMS - related option combinations, > still dead end. > > GC settings, log attached; > > Thank you for your help, > > Andrei > > ++++++++++++++++++++++++++++++++++++++++++++++++ > > # use server-style JIT compiler > wrapper.java.additional.100=-server > > # do GC logging > wrapper.java.additional.110=-verbose:gc > wrapper.java.additional.111=-Xloggc:./logs/gc.log > wrapper.java.additional.112=-XX:+PrintGCDetails > wrapper.java.additional.113=-XX:+PrintGCTimeStamps > > # Heap Total = PermGen + NewGen + OldGen; > wrapper.java.additional.120=-Xms3700m > wrapper.java.additional.121=-Xmx3700m > > # PermGen; > wrapper.java.additional.130=-XX:PermSize=50m > wrapper.java.additional.131=-XX:MaxPermSize=50m > > # NewGen; Parallel collector; > wrapper.java.additional.140=-XX:NewSize=1200m > wrapper.java.additional.141=-XX:MaxNewSize=1200m > wrapper.java.additional.142=-XX:-UseAdaptiveSizePolicy > wrapper.java.additional.143=-XX:SurvivorRatio=1 > wrapper.java.additional.144=-XX:TargetSurvivorRatio=90 > wrapper.java.additional.145=-XX:MaxTenuringThreshold=3 > wrapper.java.additional.146=-XX:+UseParNewGC > wrapper.java.additional.147=-XX:-UseParallelGC > wrapper.java.additional.148=-XX:ParallelGCThreads=4 > > # OldGen; Incremental CMS collector; > wrapper.java.additional.170=-XX:-UseParallelOldGC > wrapper.java.additional.171=-XX:+UseConcMarkSweepGC > wrapper.java.additional.172=-XX:+CMSIncrementalMode > wrapper.java.additional.173=-XX:-CMSIncrementalPacing > wrapper.java.additional.174=-XX:CMSIncrementalDutyCycle=1 > wrapper.java.additional.175=-XX:+CMSParallelRemarkEnabled > wrapper.java.additional.176=-XX:+CMSScavengeBeforeRemark > wrapper.java.additional.177=-XX:CMSIncrementalOffset=10 > wrapper.java.additional.178=-XX:CMSScheduleRemarkEdenPenetration=5 > wrapper.java.additional.179=-XX:CMSWaitDuration=60000 > wrapper.java.additional.181=-XX:ParallelCMSThreads=1 > wrapper.java.additional.182=-XX:PrintCMSStatistics=0 > > > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use(a)openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use(a)openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

1 0

hg: jdk7/hotspot-gc/hotspot: 11 new changesets
by john.cuthbertson＠sun.com 16 Feb '10

16 Feb '10

Changeset: 455df1b81409 Author: kamg Date: 2010-02-08 13:49 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/455df1b81409 6587322: dtrace probe object__alloc doesn't fire in some situations on amd64 Summary: Fix misplaced probe point Reviewed-by: rasbold, phh Contributed-by: neojia(a)gmail.com ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: 95d21201c29a Author: apangin Date: 2010-02-11 10:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/95d21201c29a Merge Changeset: 3f5b7efb9642 Author: never Date: 2010-02-05 11:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3f5b7efb9642 6920293: OptimizeStringConcat causing core dumps Reviewed-by: kvn, twisti ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 576e77447e3c Author: kvn Date: 2010-02-07 12:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/576e77447e3c 6923002: assert(false,"this call site should not be polymorphic") Summary: Clear the total count when a receiver information is cleared. Reviewed-by: never, jrose ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/arguments.cpp Changeset: f516d5d7a019 Author: kvn Date: 2010-02-08 12:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f516d5d7a019 6910605: C2: NullPointerException/ClassCaseException is thrown when C2 with DeoptimizeALot is used Summary: Set the reexecute bit for runtime calls _new_array_Java when they used for _multianewarray bytecode. Reviewed-by: never ! src/share/vm/code/pcDesc.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse3.cpp + test/compiler/6910605/Test.java Changeset: f70b0d9ab095 Author: kvn Date: 2010-02-09 01:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f70b0d9ab095 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") Summary: Mark in PcDesc call sites which return oop and save the result oop across objects reallocation during deoptimization. Reviewed-by: never ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/includeDB_core ! src/share/vm/opto/output.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/runtime/deoptimization.cpp + test/compiler/6910618/Test.java Changeset: 4ee1c645110e Author: kvn Date: 2010-02-09 10:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4ee1c645110e 6924097: assert((_type == Type::MEMORY) == (_adr_type != 0),"adr_type for memory phis only") Summary: Use PhiNode::make_blank(r, n) method to construct the phi. Reviewed-by: never ! src/share/vm/opto/loopopts.cpp Changeset: e3a4305c6bc3 Author: kvn Date: 2010-02-12 08:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e3a4305c6bc3 6925249: assert(last_sp < (intptr_t*) interpreter_frame_monitor_begin(),"bad tos") Summary: Fix assert since top deoptimized frame has last_sp == interpreter_frame_monitor_begin if there are no expressions. Reviewed-by: twisti ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/vframeArray.cpp Changeset: c09ee209b65c Author: kvn Date: 2010-02-12 10:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c09ee209b65c 6926048: Improve Zero performance Summary: Make Zero figure out result types in a similar way to C++ interpreter implementation. Reviewed-by: kvn Contributed-by: gbenson(a)redhat.com ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp Changeset: 7b4415a18c8a Author: kvn Date: 2010-02-12 15:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7b4415a18c8a Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 58add740c4ee Author: johnc Date: 2010-02-16 14:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/58add740c4ee Merge ! src/share/vm/includeDB_core

1 0

hg: jdk7/hotspot-gc/langtools: Added tag jdk7-b83 for changeset c9f4ae1f1480
by john.coomes＠sun.com 14 Feb '10

14 Feb '10

Changeset: 2edcb5dc642d Author: mikejwre Date: 2010-02-12 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/2edcb5dc642d Added tag jdk7-b83 for changeset c9f4ae1f1480 ! .hgtags

1 0