From john.coomes at sun.com Wed Oct 1 01:30:08 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Wed, 01 Oct 2008 01:30:08 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6725697: par compact - rename class ChunkData to RegionData Message-ID: <20081001013013.29891D7EA@hg.openjdk.java.net> Changeset: 81cd571500b0 Author: jcoomes Date: 2008-09-30 12:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/81cd571500b0 6725697: par compact - rename class ChunkData to RegionData Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp From john.coomes at sun.com Wed Oct 1 03:42:09 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Wed, 01 Oct 2008 03:42:09 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6729594: par compact - remove unused block table implementation Message-ID: <20081001034214.18D18D80F@hg.openjdk.java.net> Changeset: 0166ac265d53 Author: jcoomes Date: 2008-09-30 13:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0166ac265d53 6729594: par compact - remove unused block table implementation Reviewed-by: tonyp, jmasa, apetrusenko ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/runtime/globals.hpp From antonios.printezis at sun.com Thu Oct 2 01:53:31 2008 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Thu, 02 Oct 2008 01:53:31 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 8 new changesets Message-ID: <20081002015350.4CBD3D947@hg.openjdk.java.net> Changeset: 8261ee795323 Author: rasbold Date: 2008-09-17 08:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/8261ee795323 6711100: 64bit fastdebug server vm crashes with assert(_base == Int,"Not an Int") Summary: insert CastII nodes to narrow type of load_array_length() node Reviewed-by: never, kvn ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp + test/compiler/6711100/Test.java Changeset: 194b8e3a2fc4 Author: never Date: 2008-09-17 12:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/194b8e3a2fc4 6384206: Phis which are later unneeded are impairing our ability to inline based on static types Reviewed-by: rasbold, jrose ! src/share/vm/ci/ciMethodBlocks.cpp ! src/share/vm/ci/ciMethodBlocks.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: 36ccc817fca4 Author: kvn Date: 2008-09-23 12:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/36ccc817fca4 6747051: Improve code and implicit null check generation for compressed oops Summary: Push DecodeN node below the Null check to the non-null path to use the mach node without 0 test. Reviewed-by: rasbold, never ! src/share/vm/asm/assembler.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp Changeset: 5f85534046c2 Author: rasbold Date: 2008-09-24 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5f85534046c2 6750588: assert(lrg._area >= 0,"negative spill area") running NSK stmp0101 test Summary: handle NaN costs more carefully Reviewed-by: kvn, never ! src/share/vm/opto/ifg.cpp Changeset: 885fe0f95828 Author: never Date: 2008-09-25 12:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/885fe0f95828 6744783: HotSpot segfaults if given -XX options with an empty string argument Reviewed-by: kamg, kvn Contributed-by: volker.simonis at gmail.com ! src/share/vm/prims/jvmtiTrace.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp Changeset: dbec32712472 Author: never Date: 2008-09-30 11:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/dbec32712472 6753795: HotSpot crash in strlen() when JVMTI is used Summary: test for null instead of strlen Reviewed-by: rasbold ! src/share/vm/prims/jvmtiEnvBase.cpp Changeset: be41fa651400 Author: rasbold Date: 2008-09-30 15:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/be41fa651400 Merge ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp Changeset: ddfad9496151 Author: tonyp Date: 2008-10-01 15:05 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ddfad9496151 Merge ! src/share/vm/runtime/globals.hpp From dragonken at gmail.com Thu Oct 2 05:24:53 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Wed, 1 Oct 2008 22:24:53 -0700 (PDT) Subject: CMS collection keep working during holiday Message-ID: <19773575.post@talk.nabble.com> 01/10 is our holiday and my stock quote application was in leisure time on 01/10. I am surprised that during non-busy hours, my application keep draw around 15-20% cpu loading due to continueously CMS collections. It seems that -XX:CMSInitiatingOccupancyFraction=70 will not take effect during non-busy hours. Please find the attached memory chart from jconsole and gc log. jvm options: %JAVA_HOME%\jre\bin\java -server -verbose:gc -XX:+PrintGCDetails -Xloggc:powerserver_gc.log -showversion -Djava.security.policy=.\java.policy -Xms4G -Xmx4G -XX:NewSize=1G -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=4 -XX:CMSInitiatingOccupancyFraction=70 -XX:TargetSurvivorRatio=90 -Dcom.sun.management.jmxremote.port=18002 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false Any idea? Please advise. http://www.nabble.com/file/p19773575/pserver-oldgen.png http://www.nabble.com/file/p19773575/pserver-oldgen2.png 62446.219: [GC 62446.219: [ParNew: 873856K->174720K(873856K), 0.2927771 secs] 2109161K->1491505K(4019584K), 0.2928679 secs] [Times: user=1.64 sys=0.02, real=0.30 secs] 63537.932: [GC 63537.932: [ParNew: 873856K->174720K(873856K), 0.2936245 secs] 2190641K->1573411K(4019584K), 0.2937111 secs] [Times: user=1.66 sys=0.03, real=0.31 secs] 64576.245: [GC 64576.245: [ParNew: 873856K->174720K(873856K), 0.2805543 secs] 2272547K->1652492K(4019584K), 0.2806343 secs] [Times: user=1.52 sys=0.05, real=0.28 secs] 65665.444: [GC 65665.444: [ParNew: 873856K->174720K(873856K), 0.3126828 secs] 2351628K->1733865K(4019584K), 0.3127696 secs] [Times: user=1.61 sys=0.08, real=0.31 secs] 66761.009: [GC 66761.009: [ParNew: 873856K->174720K(873856K), 0.3386468 secs] 2433001K->1815987K(4019584K), 0.3387269 secs] [Times: user=1.64 sys=0.17, real=0.36 secs] 67839.979: [GC 67839.979: [ParNew: 873856K->174720K(873856K), 0.3359659 secs] 2515123K->1897775K(4019584K), 0.3360704 secs] [Times: user=1.72 sys=0.09, real=0.34 secs] 68936.295: [GC 68936.295: [ParNew: 873856K->174720K(873856K), 0.3439460 secs] 2596911K->1979557K(4019584K), 0.3440326 secs] [Times: user=1.58 sys=0.19, real=0.34 secs] 70019.873: [GC 70019.873: [ParNew: 873856K->174720K(873856K), 0.3758143 secs] 2678693K->2065201K(4019584K), 0.3759026 secs] [Times: user=1.81 sys=0.13, real=0.38 secs] 71123.565: [GC 71123.566: [ParNew: 873856K->174719K(873856K), 0.3515356 secs] 2764337K->2147170K(4019584K), 0.3516129 secs] [Times: user=1.47 sys=0.11, real=0.34 secs] 72227.180: [GC 72227.180: [ParNew: 873855K->174720K(873856K), 0.3775019 secs] 2846306K->2230692K(4019584K), 0.3775869 secs] [Times: user=1.64 sys=0.19, real=0.38 secs] 73334.657: [GC 73334.657: [ParNew: 873856K->174719K(873856K), 0.3546221 secs] 2929828K->2313182K(4019584K), 0.3547042 secs] [Times: user=1.61 sys=0.27, real=0.36 secs] 74434.184: [GC 74434.184: [ParNew: 873855K->174720K(873856K), 0.3884261 secs] 3012318K->2395247K(4019584K), 0.3885106 secs] [Times: user=1.63 sys=0.20, real=0.39 secs] 74434.573: [GC [1 CMS-initial-mark: 2220527K(3145728K)] 2396315K(4019584K), 0.2436187 secs] [Times: user=0.25 sys=0.00, real=0.23 secs] 74434.817: [CMS-concurrent-mark-start] 74437.338: [CMS-concurrent-mark: 2.521/2.521 secs] [Times: user=5.06 sys=0.16, real=2.53 secs] 74437.338: [CMS-concurrent-preclean-start] 74437.369: [CMS-concurrent-preclean: 0.031/0.031 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 74437.374: [GC[YG occupancy: 176540 K (873856 K)]74437.374: [Rescan (parallel) , 0.1324063 secs]74437.507: [weak refs processing, 0.1494715 secs] [1 CMS-remark: 2220527K(3145728K)] 2397068K(4019584K), 0.3048030 secs] [Times: user=0.42 sys=0.00, real=0.31 secs] 74437.694: [CMS-concurrent-sweep-start] 74438.946: [CMS-concurrent-sweep: 1.248/1.252 secs] [Times: user=2.19 sys=0.05, real=1.25 secs] 74438.946: [CMS-concurrent-reset-start] 74438.961: [CMS-concurrent-reset: 0.015/0.015 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 75525.633: [GC 75525.633: [ParNew: 873856K->174719K(873856K), 0.3452037 secs] 2940674K->2323239K(4019584K), 0.3453060 secs] [Times: user=1.73 sys=0.11, real=0.34 secs] 76628.997: [GC 76628.997: [ParNew: 873855K->174720K(873856K), 0.3680628 secs] 3022375K->2405373K(4019584K), 0.3681462 secs] [Times: user=1.88 sys=0.13, real=0.38 secs] 76629.366: [GC [1 CMS-initial-mark: 2230653K(3145728K)] 2407331K(4019584K), 0.2614019 secs] [Times: user=0.27 sys=0.00, real=0.27 secs] 76629.627: [CMS-concurrent-mark-start] 76632.373: [CMS-concurrent-mark: 2.746/2.746 secs] [Times: user=5.22 sys=0.34, real=2.75 secs] 76632.373: [CMS-concurrent-preclean-start] 76632.383: [CMS-concurrent-preclean: 0.010/0.010 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 76632.391: [GC[YG occupancy: 176683 K (873856 K)]76632.391: [Rescan (parallel) , 0.1555281 secs]76632.546: [weak refs processing, 0.0003456 secs] [1 CMS-remark: 2230653K(3145728K)] 2407337K(4019584K), 0.1559517 secs] [Times: user=0.36 sys=0.00, real=0.16 secs] 76632.562: [CMS-concurrent-sweep-start] 76633.784: [CMS-concurrent-sweep: 1.222/1.222 secs] [Times: user=1.31 sys=0.00, real=1.22 secs] 76633.784: [CMS-concurrent-reset-start] 76633.799: [CMS-concurrent-reset: 0.015/0.015 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 77722.107: [GC 77722.107: [ParNew: 873856K->174719K(873856K), 0.3346014 secs] 3005732K->2390264K(4019584K), 0.3346905 secs] [Times: user=1.61 sys=0.13, real=0.33 secs] 77722.442: [GC [1 CMS-initial-mark: 2215544K(3145728K)] 2391202K(4019584K), 0.2670180 secs] [Times: user=0.28 sys=0.00, real=0.28 secs] 77722.710: [CMS-concurrent-mark-start] 77725.468: [CMS-concurrent-mark: 2.758/2.758 secs] [Times: user=5.66 sys=0.11, real=2.77 secs] 77725.468: [CMS-concurrent-preclean-start] 77725.478: [CMS-concurrent-preclean: 0.010/0.011 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 77725.478: [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time 77730.692: [CMS-concurrent-abortable-preclean: 0.340/5.213 secs] [Times: user=3.24 sys=0.00, real=5.22 secs] 77730.699: [GC[YG occupancy: 181794 K (873856 K)]77730.700: [Rescan (parallel) , 0.1554305 secs]77730.855: [weak refs processing, 0.0002146 secs] [1 CMS-remark: 2215544K(3145728K)] 2397339K(4019584K), 0.1557162 secs] [Times: user=0.27 sys=0.00, real=0.16 secs] 77730.870: [CMS-concurrent-sweep-start] 77732.117: [CMS-concurrent-sweep: 1.247/1.247 secs] [Times: user=1.26 sys=0.00, real=1.24 secs] 77732.117: [CMS-concurrent-reset-start] 77732.132: [CMS-concurrent-reset: 0.015/0.015 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 77734.136: [GC [1 CMS-initial-mark: 2208798K(3145728K)] 2392348K(4019584K), 0.2699426 secs] [Times: user=0.26 sys=0.00, real=0.27 secs] 77734.406: [CMS-concurrent-mark-start] 77737.261: [CMS-concurrent-mark: 2.851/2.856 secs] [Times: user=5.27 sys=0.34, real=2.86 secs] 77737.261: [CMS-concurrent-preclean-start] 77737.272: [CMS-concurrent-preclean: 0.010/0.010 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 77737.272: [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time 77742.481: [CMS-concurrent-abortable-preclean: 0.339/5.209 secs] [Times: user=3.30 sys=0.00, real=5.22 secs] 77742.487: [GC[YG occupancy: 191586 K (873856 K)]77742.487: [Rescan (parallel) , 0.1631453 secs]77742.651: [weak refs processing, 0.0001524 secs] [1 CMS-remark: 2208798K(3145728K)] 2400385K(4019584K), 0.1633895 secs] [Times: user=0.28 sys=0.00, real=0.17 secs] 77742.666: [CMS-concurrent-sweep-start] 77743.864: [CMS-concurrent-sweep: 1.198/1.198 secs] [Times: user=1.22 sys=0.00, real=1.20 secs] 77743.864: [CMS-concurrent-reset-start] 77743.879: [CMS-concurrent-reset: 0.015/0.015 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 77745.883: [GC [1 CMS-initial-mark: 2203641K(3145728K)] 2398172K(4019584K), 0.2750780 secs] [Times: user=0.25 sys=0.00, real=0.27 secs] 77746.159: [CMS-concurrent-mark-start] 77748.880: [CMS-concurrent-mark: 2.721/2.721 secs] [Times: user=5.36 sys=0.09, real=2.73 secs] 77748.880: [CMS-concurrent-preclean-start] 77748.890: [CMS-concurrent-preclean: 0.010/0.010 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 77748.890: [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time 77754.112: [CMS-concurrent-abortable-preclean: 0.467/5.222 secs] [Times: user=3.33 sys=0.00, real=5.23 secs] 77754.118: [GC[YG occupancy: 197250 K (873856 K)]77754.118: [Rescan (parallel) , 0.1562518 secs]77754.274: [weak refs processing, 0.0001109 secs] [1 CMS-remark: 2203641K(3145728K)] 2400891K(4019584K), 0.1564752 secs] [Times: user=0.36 sys=0.00, real=0.17 secs] 77754.290: [CMS-concurrent-sweep-start] 77755.425: [CMS-concurrent-sweep: 1.135/1.135 secs] [Times: user=1.14 sys=0.00, real=1.14 secs] 77755.425: [CMS-concurrent-reset-start] 77755.441: [CMS-concurrent-reset: 0.016/0.016 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 77757.445: [GC [1 CMS-initial-mark: 2203641K(3145728K)] 2405052K(4019584K), 0.2801865 secs] [Times: user=0.26 sys=0.00, real=0.28 secs] 77757.725: [CMS-concurrent-mark-start] 77760.493: [CMS-concurrent-mark: 2.768/2.768 secs] [Times: user=5.52 sys=0.11, real=2.80 secs] 77760.493: [CMS-concurrent-preclean-start] 77760.504: [CMS-concurrent-preclean: 0.010/0.010 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] 77760.504: [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time 77765.719: [CMS-concurrent-abortable-preclean: 0.339/5.216 secs] [Times: user=3.23 sys=0.03, real=5.22 secs] 77765.725: [GC[YG occupancy: 203843 K (873856 K)]77765.725: [Rescan (parallel) , 0.1573253 secs]77765.883: [weak refs processing, 0.0000936 secs] [1 CMS-remark: 2203641K(3145728K)] 2407484K(4019584K), 0.1575000 secs] [Times: user=0.38 sys=0.00, real=0.17 secs] 77765.898: [CMS-concurrent-sweep-start] 77767.132: [CMS-concurrent-sweep: 1.234/1.234 secs] [Times: user=1.25 sys=0.00, real=1.23 secs] 77767.132: [CMS-concurrent-reset-start] 77767.147: [CMS-concurrent-reset: 0.015/0.015 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 77769.151: [GC [1 CMS-initial-mark: 2203641K(3145728K)] 2409821K(4019584K), 0.2889787 secs] [Times: user=0.26 sys=0.00, real=0.28 secs] 77769.440: [CMS-concurrent-mark-start] 77772.168: [CMS-concurrent-mark: 2.728/2.728 secs] [Times: user=5.36 sys=0.13, real=2.75 secs] 77772.168: [CMS-concurrent-preclean-start] 77772.178: [CMS-concurrent-preclean: 0.010/0.010 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 77772.178: [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time 77777.294: [CMS-concurrent-abortable-preclean: 0.344/5.116 secs] [Times: user=3.39 sys=0.00, real=5.13 secs] 77777.302: [GC[YG occupancy: 218737 K (873856 K)]77777.302: [Rescan (parallel) , 0.1573837 secs]77777.460: [weak refs processing, 0.0000945 secs] [1 CMS-remark: 2203641K(3145728K)] 2422379K(4019584K), 0.1575605 secs] [Times: user=0.39 sys=0.00, real=0.17 secs] 77777.475: [CMS-concurrent-sweep-start] 77778.609: [CMS-concurrent-sweep: 1.134/1.134 secs] [Times: user=1.14 sys=0.00, real=1.14 secs] 77778.609: [CMS-concurrent-reset-start] 77778.625: [CMS-concurrent-reset: 0.015/0.015 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 77780.628: [GC [1 CMS-initial-mark: 2203641K(3145728K)] 2424717K(4019584K), 0.2928494 secs] [Times: user=0.28 sys=0.00, real=0.30 secs] 77780.921: [CMS-concurrent-mark-start] 77783.638: [CMS-concurrent-mark: 2.717/2.717 secs] [Times: user=5.33 sys=0.13, real=2.73 secs] 77783.638: [CMS-concurrent-preclean-start] 77783.654: [CMS-concurrent-preclean: 0.016/0.016 secs] [Times: user=0.01 sys=0.00, real=0.02 secs] 77783.654: [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time 77788.832: [CMS-concurrent-abortable-preclean: 0.386/5.178 secs] [Times: user=3.36 sys=0.00, real=5.19 secs] 77788.840: [GC[YG occupancy: 226606 K (873856 K)]77788.840: [Rescan (parallel) , 0.1651500 secs]77789.005: [weak refs processing, 0.0000958 secs] [1 CMS-remark: 2203641K(3145728K)] 2430247K(4019584K), 0.1653619 secs] [Times: user=0.30 sys=0.00, real=0.17 secs] 77789.021: [CMS-concurrent-sweep-start] 77790.051: [CMS-concurrent-sweep: 1.031/1.031 secs] [Times: user=1.05 sys=0.00, real=1.03 secs] 77790.051: [CMS-concurrent-reset-start] 77790.067: [CMS-concurrent-reset: 0.015/0.015 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 77792.070: [GC [1 CMS-initial-mark: 2203641K(3145728K)] 2430289K(4019584K), 0.2979185 secs] [Times: user=0.28 sys=0.00, real=0.30 secs] 77792.368: [CMS-concurrent-mark-start] 77795.085: [CMS-concurrent-mark: 2.717/2.717 secs] [Times: user=5.34 sys=0.20, real=2.72 secs] 77795.085: [CMS-concurrent-preclean-start] 77795.095: [CMS-concurrent-preclean: 0.010/0.010 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 77795.095: [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time 77800.269: [CMS-concurrent-abortable-preclean: 0.484/5.174 secs] [Times: user=3.28 sys=0.00, real=5.17 secs] 77800.275: [GC[YG occupancy: 233897 K (873856 K)]77800.275: [Rescan (parallel) , 0.1660870 secs]77800.442: [weak refs processing, 0.0001040 secs] [1 CMS-remark: 2203641K(3145728K)] 2437538K(4019584K), 0.1662851 secs] [Times: user=0.31 sys=0.00, real=0.17 secs] 77800.457: [CMS-concurrent-sweep-start] 77801.459: [CMS-concurrent-sweep: 1.002/1.002 secs] [Times: user=1.06 sys=0.00, real=1.00 secs] 77801.459: [CMS-concurrent-reset-start] 77801.474: [CMS-concurrent-reset: 0.015/0.015 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 77803.477: [GC [1 CMS-initial-mark: 2203641K(3145728K)] 2438755K(4019584K), 0.3026378 secs] [Times: user=0.30 sys=0.00, real=0.30 secs] 77803.780: [CMS-concurrent-mark-start] 77806.515: [CMS-concurrent-mark: 2.735/2.735 secs] [Times: user=5.41 sys=0.11, real=2.73 secs] 77806.515: [CMS-concurrent-preclean-start] 77806.525: [CMS-concurrent-preclean: 0.010/0.010 secs] [Times: user=0.00 sys=0.00, real=0.02 secs] 77806.525: [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time 77811.723: [CMS-concurrent-abortable-preclean: 0.374/5.197 secs] [Times: user=3.33 sys=0.00, real=5.22 secs] 77811.726: [GC[YG occupancy: 237551 K (873856 K)]77811.726: [Rescan (parallel) , 0.1518526 secs]77811.878: [weak refs processing, 0.0000969 secs] [1 CMS-remark: 2203641K(3145728K)] 2441193K(4019584K), 0.1520584 secs] [Times: user=0.38 sys=0.00, real=0.16 secs] 77811.893: [CMS-concurrent-sweep-start] 77812.890: [CMS-concurrent-sweep: 0.997/0.997 secs] [Times: user=1.08 sys=0.00, real=1.00 secs] 77812.890: [CMS-concurrent-reset-start] 77812.905: [CMS-concurrent-reset: 0.015/0.015 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 77814.909: [GC [1 CMS-initial-mark: 2203641K(3145728K)] 2445359K(4019584K), 0.3071683 secs] [Times: user=0.28 sys=0.00, real=0.30 secs] 77815.216: [CMS-concurrent-mark-start] 77817.955: [CMS-concurrent-mark: 2.739/2.739 secs] [Times: user=5.33 sys=0.13, real=2.75 secs] 77817.955: [CMS-concurrent-preclean-start] 77817.965: [CMS-concurrent-preclean: 0.010/0.010 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 77817.965: [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time 77823.178: [CMS-concurrent-abortable-preclean: 0.482/5.213 secs] [Times: user=3.27 sys=0.00, real=5.20 secs] 77823.184: [GC[YG occupancy: 243681 K (873856 K)]77823.184: [Rescan (parallel) , 0.1612718 secs]77823.345: [weak refs processing, 0.0001191 secs] [1 CMS-remark: 2203641K(3145728K)] 2447322K(4019584K), 0.1615056 secs] [Times: user=0.31 sys=0.00, real=0.17 secs] 77823.361: [CMS-concurrent-sweep-start] 77824.356: [CMS-concurrent-sweep: 0.995/0.995 secs] [Times: user=1.08 sys=0.00, real=1.00 secs] 77824.356: [CMS-concurrent-reset-start] 77824.371: [CMS-concurrent-reset: 0.015/0.015 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 77825.194: [GC [1 CMS-initial-mark: 2203641K(3145728K)] 2449146K(4019584K), 0.3122333 secs] [Times: user=0.30 sys=0.00, real=0.31 secs] 77825.506: [CMS-concurrent-mark-start] 77828.241: [CMS-concurrent-mark: 2.735/2.735 secs] [Times: user=5.31 sys=0.17, real=2.73 secs] 77828.241: [CMS-concurrent-preclean-start] 77828.252: [CMS-concurrent-preclean: 0.010/0.010 secs] [Times: user=0.03 sys=0.00, real=0.02 secs] 77828.252: [CMS-concurrent-abortable-preclean-start] -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19773575.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From Peter.Kessler at Sun.COM Thu Oct 2 19:05:47 2008 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Thu, 02 Oct 2008 12:05:47 -0700 Subject: Sun > Forums > Isolating a PermGen error Message-ID: <48E51B8B.6010100@Sun.COM> Transferring this thread to hotspot-gc-use (as requested) to get advice from the experts on how to diagnose class loader problems. I would start by adding -XX:+TraceClassLoading -XX:+TraceClassUnloading to the command line and seeing if there were obvious classes that get loaded but not unloaded. I don't know of any available statistics for the size of the interned String table. But it is all open source, so you could add something. (Warning: That code is ugly, and it's among the oldest code in the VM.) But likely other people have other, better ideas. ... peter > Subject: Re: Sun > Forums > Isolating a PermGen error > Date: Thu, 02 Oct 2008 21:53:37 +0300 > From: Eyal Zfira > To: Peter B. Kessler > > The PermGen usage leap is caused by running a crystal report for the 1st > time. I noticed (by analyzing a heap dump) that there's a crystal thread > keeping some objects alive. My problem is that the PermGen usage keeps > raising with every report I generate (I have an open thread with Crystal > as well). I also noticed (using JConsole) that the loaded classes are > not kept still while the PermGen usage still rises. Is there a way to > find out whether it's interned strings or class problem? What is the > best way to "attack" a misused classloader problem? > > Eyal > > On Thu, Oct 2, 2008 at 9:09 PM, Peter B. Kessler > wrote: > > Thanks for the detailed log. > > You are, as you suspected, running out of permanent generation > space. That doesn't tell you why you are filling that space, but it > does tell you where to look: loaded classes and interned Strings. > > Except for the collection at 191.200, none of your collections frees > up any real space in the permanent generation, and that's after a > run up from ~40MB to 64MB from 183.652 to 190.850. Can you > correlate that part of the run with things your application is > doing? (That might also be a red herring.) > > If those objects are live (that is, if the collector is doing its > job, which I think it is), then you will have to figure out why they > are being retained. That's real work. If you were expecting > classes to be unloaded, you'll have to find why they are being > retained. Usually that turns out to be because of the way you've > split class up among classloaders. If you are interning that many > Strings, then you'll have to increase the size of the permanent > generation, or write your own equivalent of String.intern (think > WeakHashMap) so the unique copies of the Strings are kept in the > heap, not in the permanent generation. > > ... peter > > Eyal Zfira wrote: > > Peter, > > First of all, thanks for the quick response. > You are more than welcome to publish this discussion (I'll > subscribe to the mailing list as well). > > Here is the more detailed GC log. I'm also monitoring the > application using JConsole and I keep seeing the PermGen memory > raising. .... _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From jon.masamitsu at sun.com Thu Oct 2 22:08:40 2008 From: jon.masamitsu at sun.com (jon.masamitsu at sun.com) Date: Thu, 02 Oct 2008 22:08:40 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6660681: Incrementally reserve pages on win server 2003 for better large page affinity Message-ID: <20081002220844.7DBCBDA72@hg.openjdk.java.net> Changeset: ee21eaa8ffe1 Author: jmasa Date: 2008-10-02 12:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ee21eaa8ffe1 6660681: Incrementally reserve pages on win server 2003 for better large page affinity Summary: For windows server 2003 added option to reserve large pages individually. Reviewed-by: alanb, jcoomes, tonyp, apetrusenko ! src/os/linux/vm/globals_linux.hpp ! src/os/solaris/vm/globals_solaris.hpp ! src/os/windows/vm/globals_windows.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/share/vm/runtime/globals.hpp From dragonken at gmail.com Sun Oct 5 17:38:30 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Sun, 5 Oct 2008 10:38:30 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: <19773575.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> Message-ID: <19827116.post@talk.nabble.com> Anyone help? Someone has exactly same case to me and he posted the case at Jon Masamitsu's blog: http://blogs.sun.com/jonthecollector/entry/jdk6_gc_release_notes quote: Trying the new CMS in 1.6 and it seems to work nicely for a while but then it starts kicking out these CMS aborts. I can find nothing anywhere talking about what is happening. This happens over and over until a full GC happens. >From what I can tell the CMS collector never completes and is therefore not doing anything except taking CPU time. CMS: abort preclean due to time 407.606: [CMS-concurrent-abortable-preclean: 0.149/5.058 secs] The CMS will be triggered by -XX:CMSInitiatingOccupancyFraction=70 but it seems that it has no effect but continue keeping CMS until a Full GC (caused by 'concurrent mode failure'). In my case, it always happen in non-busy hours but the CMS behave normally in busy / peak hours. I think it is not related to 'cms abort preclean' but it's really taking CPU time but do nothing (around 4 hours) and it has chance to have a big GC when the old-gen is full. Best Regards, Ken -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19827116.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From eyalzf at gmail.com Sun Oct 5 12:13:10 2008 From: eyalzf at gmail.com (Eyal Zfira) Date: Sun, 5 Oct 2008 14:13:10 +0200 Subject: Sun > Forums > Isolating a PermGen error Message-ID: <62909b7c0810050513q35c39628if266ae280fff90bf@mail.gmail.com> I added these parameters to see which classes are loaded and unloaded. Here is the command line parameters: -Dprogram.name=run.bat -Djava.awt.headless=true -ea -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8000,suspend=n,server=y -DforceStart=false -DsaveCache=false -DdeleteMessages=false -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl -Djboss.platform.mbeanserver -Dcom.sun.management.jmxremote -Xloggc:c:\loggc.txt -XX:+PrintGCDetails -XX:+TraceClassLoading -XX:+TraceClassUnloading -Xms512m -Xmx512m -Djava.library.path=../lib/ -Dwrapper.key=N75jMiF5OGsUNzXK -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=3272 -Dwrapper.version=3.2.3 -Dwrapper.native_library=wrapper -Dwrapper.cpu.timeout=600 -Dwrapper.jvmid=1 I see that after Crystal classes are being loaded for the first time (3-4k classes) there are no additional classes loaded. But I still see the PermGen memory raising. Does that means I must have a String.intern() problem? Thanks, Eyal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From michael.finocchiaro at gmail.com Mon Oct 6 13:45:39 2008 From: michael.finocchiaro at gmail.com (Michael Finocchiaro) Date: Mon, 6 Oct 2008 15:45:39 +0200 Subject: JNI implications on HotSpot Message-ID: <8b61e5430810060645t3c0c9fd2ub0de176dd3bae92d@mail.gmail.com> I was wondering if there were any thoughts, or better yet, white papers, on the performance implications of JNI code on HotSpot performance and configuration. The malloc()s in the native JNI code are allocated on the Eden heap with other Java objects and subject to the same rules? Or not? Any boundary conditions to beware of? Google was not particularly helpful so I am coming to the experts :) Cheers, Fino Michael Finocchiaro michael.finocchiaro at gmail.com Mobile Telephone: +33 6 85 46 07 62 MSN: le_fino at hotmail.com Blog: http://mfinocchiaro.wordpress.com Bookmarks: http://del.icio.us/michael.finocchiaro -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From rainer.jung at kippdata.de Sun Oct 5 13:28:56 2008 From: rainer.jung at kippdata.de (Rainer Jung) Date: Sun, 05 Oct 2008 15:28:56 +0200 Subject: More PrintGCApplicationStoppedTime messages in Java 6 Message-ID: <48E8C118.9010302@kippdata.de> Hi, the number of messages Total time for which application threads were stopped: X.Y seconds produced by PrintGCApplicationStoppedTime increased a lot between Java 5 and 6. All of the additional messages refer to extremely short pause times, and none of the prints anything when adding PrintHeadAtGC, so it looks like they are not directly related to actually running a GC task. Can someone give an indication, what other typical reasons for those pauses exist? I tried to track it back from vm/runtime/vmThread.cpp, but wasn't really successful. Regards, Rainer _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Jon.Masamitsu at Sun.COM Mon Oct 6 15:17:16 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 06 Oct 2008 08:17:16 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <19827116.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> Message-ID: <48EA2BFC.2020309@Sun.COM> On 10/05/08 10:38, Ken-- at newsgroupstats.hk wrote: > Anyone help? Someone has exactly same case to me and he posted the case at > Jon Masamitsu's blog: > > http://blogs.sun.com/jonthecollector/entry/jdk6_gc_release_notes > > quote: > Trying the new CMS in 1.6 and it seems to work nicely for a while but then > it starts kicking out these CMS aborts. I can find nothing anywhere talking > about what is happening. This happens over and over until a full GC happens. >>From what I can tell the CMS collector never completes and is therefore not > doing anything except taking CPU time. CMS: abort preclean due to time > 407.606: [CMS-concurrent-abortable-preclean: 0.149/5.058 secs] This "abort" message stops a second precleaning phase. This second precleaning phase is only meant to run for a lesser amount of time and the "abort" does not indicate any problem. That phase is meant to be "aborted". It's rather an unfortunate choice of words on our part. > > The CMS will be triggered by -XX:CMSInitiatingOccupancyFraction=70 but it > seems that it has no effect but continue keeping CMS until a Full GC (caused > by 'concurrent mode failure'). In my case, it always happen in non-busy > hours but the CMS behave normally in busy / peak hours. > > I think it is not related to 'cms abort preclean' but it's really taking CPU > time but do nothing (around 4 hours) and it has chance to have a big GC when > the old-gen is full. The CMS collections cycles are being started because the old (tenured) generation does have > 70% occupancy (at least in this fragment from the log that your sent earlier). 76632.391: [GC[YG occupancy: 176683 K (873856 K)]76632.391: [Rescan (parallel) , 0.1555281 secs]76632.546: [weak refs processing, 0.0003456 secs] [1 CMS-remark: 2230653K(3145728K)] 2407337K(4019584K), 0.1559517 secs] Looking at [1 CMS-remark: 2230653K(3145728K)] the 2230653K is the amount of the old generation that is being used and 3145728K is the total old generation size and 2230653K/3145728K is just over 70%. I didn't find a concurrent mode failure in your mail from 10/1. Can you sent a log showing the output with the concurrent mode failure? > > Best Regards, > Ken > > > > > > > From dragonken at gmail.com Mon Oct 6 16:44:47 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Mon, 6 Oct 2008 09:44:47 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: <48EA2BFC.2020309@Sun.COM> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> Message-ID: <19841670.post@talk.nabble.com> Thanks for your quick response. The application started at 1/10 was crash this morning. I lost the gc log file as I quickly restart the application to avoid service interruption to our clients. >From the hotspot error file(attached), it show that it crash when old generation 99% full. Anyway, it's another problem. http://www.nabble.com/file/p19841670/hs_err_pid2476.log hs_err_pid2476.log I have another application with similar JVM options set and have exactly behavior: JVM Options: -Djava.security.policy=./java.policy -XX:+PrintGCDetails -XX:+PrintGCTaskTimeStamps -XX:+PrintHeapAtGC -Xloggc:hkexquoteserver_gc.log -Xms4G -Xmx4G -XX:NewSize=1G -XX:MaxNewSize=1G -XX:+PrintTenuringDistribution -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=4 -XX:CMSInitiatingOccupancyFraction=70 -XX:TargetSurvivorRatio=90 -Dcom.sun.management.jmxremote.port=18003 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false GC Logs: http://www.nabble.com/file/p19841670/gc.zip gc.zip JConsole: http://www.nabble.com/file/p19841670/jconsole.jpg http://www.nabble.com/file/p19841670/jconsole2.jpg - long lasting CMSs from 426789 to 504376 - CMS cannot free space in old generation within this period. What I expected is to free old-gen memory to around 500M full at 426789. - concurrent mode failure at 504379 Thanks and Best Regards, Ken -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19841670.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From dragonken at gmail.com Mon Oct 6 17:58:46 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Mon, 6 Oct 2008 10:58:46 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: <19841670.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> Message-ID: <19842992.post@talk.nabble.com> Just for info. I double check with the vm options, I did edit the startup bat to disable auto duty cycle of CMS at 2/10 morning. Regards, Ken Ken-- at newsgroupstats.hk wrote: > > Thanks for your quick response. The application started at 1/10 was crash > this morning. I lost the gc log file as I quickly restart the application > to avoid service interruption to our clients. > > From the hotspot error file(attached), it show that it crash when old > generation 99% full. Anyway, it's another problem. > > http://www.nabble.com/file/p19841670/hs_err_pid2476.log > hs_err_pid2476.log > > I have another application with similar JVM options set and have exactly > behavior: > > JVM Options: > > -Djava.security.policy=./java.policy -XX:+PrintGCDetails > -XX:+PrintGCTaskTimeStamps -XX:+PrintHeapAtGC > -Xloggc:hkexquoteserver_gc.log -Xms4G -Xmx4G -XX:NewSize=1G > -XX:MaxNewSize=1G -XX:+PrintTenuringDistribution -XX:+DisableExplicitGC > -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=4 > -XX:CMSInitiatingOccupancyFraction=70 -XX:TargetSurvivorRatio=90 > -Dcom.sun.management.jmxremote.port=18003 > -Dcom.sun.management.jmxremote.authenticate=false > -Dcom.sun.management.jmxremote.ssl=false > > GC Logs: > http://www.nabble.com/file/p19841670/gc.zip gc.zip > > JConsole: > http://www.nabble.com/file/p19841670/jconsole.jpg > > http://www.nabble.com/file/p19841670/jconsole2.jpg > > > - long lasting CMSs from 426789 to 504376 > - CMS cannot free space in old generation within this period. What I > expected is to free old-gen memory to around 500M full at 426789. > - concurrent mode failure at 504379 > > Thanks and Best Regards, > Ken > > > > > > > -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19842992.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From kirk.pepperdine at gmail.com Mon Oct 6 17:45:42 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Mon, 06 Oct 2008 19:45:42 +0200 Subject: CMS collection keep working during holiday In-Reply-To: <19841670.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> Message-ID: <48EA4EC6.5060906@javaperformancetuning.com> Hi Ken, Can I suggest that you back off on some of the switch settings. I think that GC might work better if ergonomics where allowed to adjust some of the sizes. This may prevent the horrible GC you are experiencing. Is suspect that an attempt at compaction in this condition (which the switch settings would exacerbate) would be devastating. I see SurvivorRatio=4 and then TargetSurvivorRatio=90. These completely conflicting settings. I don't know which one would win but I would guess SurvivorRatio=4. Some switch settings are fixing values where as other switch setting work as suggestions for ergonomics. Fixing values limit what ergonomics can do for you and ergonomics are designed to adjust configurations to help you meet your pause time and GC throughput goals. Parallel in new is default for 1.5+. For a first run I'd use.... -Xmx4 -XX:+UseConcMarkSweepGC + diagnostics + security settings Regards, Kirk Ken-- at newsgroupstats.hk wrote: > Thanks for your quick response. The application started at 1/10 was crash > this morning. I lost the gc log file as I quickly restart the application to > avoid service interruption to our clients. > > >From the hotspot error file(attached), it show that it crash when old > generation 99% full. Anyway, it's another problem. > > http://www.nabble.com/file/p19841670/hs_err_pid2476.log hs_err_pid2476.log > > I have another application with similar JVM options set and have exactly > behavior: > > JVM Options: > > -Djava.security.policy=./java.policy -XX:+PrintGCDetails > -XX:+PrintGCTaskTimeStamps -XX:+PrintHeapAtGC -Xloggc:hkexquoteserver_gc.log > -Xms4G -Xmx4G -XX:NewSize=1G -XX:MaxNewSize=1G > -XX:+PrintTenuringDistribution -XX:+DisableExplicitGC > -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=4 > -XX:CMSInitiatingOccupancyFraction=70 -XX:TargetSurvivorRatio=90 > -Dcom.sun.management.jmxremote.port=18003 > -Dcom.sun.management.jmxremote.authenticate=false > -Dcom.sun.management.jmxremote.ssl=false > > GC Logs: > http://www.nabble.com/file/p19841670/gc.zip gc.zip > > JConsole: > http://www.nabble.com/file/p19841670/jconsole.jpg > > http://www.nabble.com/file/p19841670/jconsole2.jpg > > > - long lasting CMSs from 426789 to 504376 > - CMS cannot free space in old generation within this period. What I > expected is to free old-gen memory to around 500M full at 426789. > - concurrent mode failure at 504379 > > Thanks and Best Regards, > Ken > > > > > > > From Jon.Masamitsu at Sun.COM Mon Oct 6 20:12:32 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 06 Oct 2008 13:12:32 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <19842992.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19842992.post@talk.nabble.com> Message-ID: <48EA7130.6060600@Sun.COM> On 10/06/08 10:58, Ken-- at newsgroupstats.hk wrote: > Just for info. I double check with the vm options, I did edit the startup bat > to disable auto duty cycle of CMS at 2/10 morning. How did you change the flags for 2/10 from those below? > > Regards, > Ken > > > Ken-- at newsgroupstats.hk wrote: >> Thanks for your quick response. The application started at 1/10 was crash >> this morning. I lost the gc log file as I quickly restart the application >> to avoid service interruption to our clients. >> >> From the hotspot error file(attached), it show that it crash when old >> generation 99% full. Anyway, it's another problem. >> >> http://www.nabble.com/file/p19841670/hs_err_pid2476.log >> hs_err_pid2476.log >> >> I have another application with similar JVM options set and have exactly >> behavior: >> >> JVM Options: >> >> -Djava.security.policy=./java.policy -XX:+PrintGCDetails >> -XX:+PrintGCTaskTimeStamps -XX:+PrintHeapAtGC >> -Xloggc:hkexquoteserver_gc.log -Xms4G -Xmx4G -XX:NewSize=1G >> -XX:MaxNewSize=1G -XX:+PrintTenuringDistribution -XX:+DisableExplicitGC >> -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=4 >> -XX:CMSInitiatingOccupancyFraction=70 -XX:TargetSurvivorRatio=90 >> -Dcom.sun.management.jmxremote.port=18003 >> -Dcom.sun.management.jmxremote.authenticate=false >> -Dcom.sun.management.jmxremote.ssl=false >> From Jon.Masamitsu at Sun.COM Tue Oct 7 03:35:21 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 06 Oct 2008 20:35:21 -0700 Subject: Nursery and Tenured generation sizing In-Reply-To: <545E8962B7529546962672A564039F990F75B8D5@exchange.guidewire.com> References: <545E8962B7529546962672A564039F990F75B8D5@exchange.guidewire.com> Message-ID: <48EAD8F9.8000707@sun.com> What's your command line? Alex Aisinzon wrote: > > All > > > > Our application is very memory intensive and behaves well with a lot > of memory. 3GB is close to the 32 bits limit on our platform. > > In these tests, the amount of long lived is below 1GB. > > I running various performance tests and I am not seeing some definite > advantage in using an as large as possible nursery even though this is > one of the tenet of the generational garbage collector. > > By example, a performance run with 1GB tenured and 2GB nursery is not > better performing than one with 2GB tenured and 1GB nursery even > though, in both cases, there are very few full collections. > > I have been using ParNewGC and will try again with ParallelGC. > > This logic has worked very well on another JVM and I see no reason why > it would not work equally well with the Sun JDK 1.5. > > > > Let me know what you think > > > > Alex Aisinzon > > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Jon.Masamitsu at Sun.COM Tue Oct 7 03:43:15 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 06 Oct 2008 20:43:15 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <19842992.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19842992.post@talk.nabble.com> Message-ID: <48EADAD3.3080505@sun.com> Ken, As you've indicated the CMS concurrent collections look like they are not behaving correctly. I'll see if I can come up with a simple test case to reproduce this behavior. I'll get back to you if I learn anything. Jon Ken-- at newsgroupstats.hk wrote: > Just for info. I double check with the vm options, I did edit the startup bat > to disable auto duty cycle of CMS at 2/10 morning. > > Regards, > Ken > > > Ken-- at newsgroupstats.hk wrote: > >> Thanks for your quick response. The application started at 1/10 was crash >> this morning. I lost the gc log file as I quickly restart the application >> to avoid service interruption to our clients. >> >> From the hotspot error file(attached), it show that it crash when old >> generation 99% full. Anyway, it's another problem. >> >> http://www.nabble.com/file/p19841670/hs_err_pid2476.log >> hs_err_pid2476.log >> >> I have another application with similar JVM options set and have exactly >> behavior: >> >> JVM Options: >> >> -Djava.security.policy=./java.policy -XX:+PrintGCDetails >> -XX:+PrintGCTaskTimeStamps -XX:+PrintHeapAtGC >> -Xloggc:hkexquoteserver_gc.log -Xms4G -Xmx4G -XX:NewSize=1G >> -XX:MaxNewSize=1G -XX:+PrintTenuringDistribution -XX:+DisableExplicitGC >> -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=4 >> -XX:CMSInitiatingOccupancyFraction=70 -XX:TargetSurvivorRatio=90 >> -Dcom.sun.management.jmxremote.port=18003 >> -Dcom.sun.management.jmxremote.authenticate=false >> -Dcom.sun.management.jmxremote.ssl=false >> >> GC Logs: >> http://www.nabble.com/file/p19841670/gc.zip gc.zip >> >> JConsole: >> http://www.nabble.com/file/p19841670/jconsole.jpg >> >> http://www.nabble.com/file/p19841670/jconsole2.jpg >> >> >> - long lasting CMSs from 426789 to 504376 >> - CMS cannot free space in old generation within this period. What I >> expected is to free old-gen memory to around 500M full at 426789. >> - concurrent mode failure at 504379 >> >> Thanks and Best Regards, >> Ken >> >> >> >> >> >> >> >> > > From dragonken at gmail.com Tue Oct 7 03:59:54 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Mon, 6 Oct 2008 20:59:54 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: <48EA7130.6060600@Sun.COM> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19842992.post@talk.nabble.com> <48EA7130.6060600@Sun.COM> Message-ID: <19850548.post@talk.nabble.com> > How did you change the flags for 2/10 from those below? I changed the jvm options from : -verbose:gc -XX:+PrintGCDetails -Xloggc:powerserver_gc.log -Djava.security.policy=.\java.policy -Xms4G -Xmx4G -XX:NewSize=1G -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=4 -XX:CMSInitiatingOccupancyFraction=70 -XX:TargetSurvivorRatio=90 -Dcom.sun.management.jmxremote.port=18002 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false to : -verbose:gc -XX:+PrintGCDetails -Xloggc:powerserver_gc.log -Djava.security.policy=.\java.policy -Xms4G -Xmx4G -XX:NewSize=1G -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=4 -XX:CMSInitiatingOccupancyFraction=70 -XX:-CMSIncrementalPacing -XX:CMSIncrementalDutyCycle=10 -XX:TargetSurvivorRatio=90 -Dcom.sun.management.jmxremote.port=18002 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false just added 2 more flag: XX:-CMSIncrementalPacing -XX:CMSIncrementalDutyCycle=10 -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19850548.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From igor.veresov at sun.com Tue Oct 7 06:16:41 2008 From: igor.veresov at sun.com (igor.veresov at sun.com) Date: Tue, 07 Oct 2008 06:16:41 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6753547: NUMA allocator: Invalid chunk size computation during adaptive resizing Message-ID: <20081007061646.4A85BDD6E@hg.openjdk.java.net> Changeset: ab4a7734b9c4 Author: iveresov Date: 2008-10-06 20:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ab4a7734b9c4 6753547: NUMA allocator: Invalid chunk size computation during adaptive resizing Summary: The per-lgrp chuck size can be incorrectly computed (causing an assertion failure) because of the non-associativity of the floating point operations. The fix is to rearrange the operations. Reviewed-by: ysr ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp From dragonken at gmail.com Wed Oct 8 05:14:35 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Tue, 7 Oct 2008 22:14:35 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: <19841670.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> Message-ID: <19872463.post@talk.nabble.com> Follow up to the jconsole above. This gif is captured today. You can see the first CMS after a FULL GC is working. The 2nd one is working too but the memory free from 2nd generation is much less than the first CMS. The memory free by 3rd CMS is further decreased. The 5th CMS cannot free enough memory to make occanpcy in old-gen to less than 70%. So, continue non-stopping CMS happen again until a Full GC (triggered by Concurrent Mode Failure). http://www.nabble.com/file/p19872463/jconsole_20081008.jpg -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872463.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From Y.S.Ramakrishna at Sun.COM Wed Oct 8 05:26:34 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Tue, 07 Oct 2008 22:26:34 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <19872463.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> Message-ID: Could you run with the additional option +PrintReferenceGC and see if it sheds additional light on the problem? (Please share the resulting GC logs.) If at all possible, you might try rev'ing down to 6.0 and seeing if the same behaviour reproduces or not? I understand that some or all of this may not be possible in a production setting. -- ramki ----- Original Message ----- From: "Ken-- at newsgroupstats.hk" Date: Tuesday, October 7, 2008 10:17 pm Subject: Re: CMS collection keep working during holiday To: hotspot-gc-dev at openjdk.java.net > Follow up to the jconsole above. This gif is captured today. You can > see the > first CMS after a FULL GC is working. The 2nd one is working too but the > memory free from 2nd generation is much less than the first CMS. The memory > free by 3rd CMS is further decreased. > > The 5th CMS cannot free enough memory to make occanpcy in old-gen to less > than 70%. So, continue non-stopping CMS happen again until a Full GC > (triggered by Concurrent Mode Failure). > > http://www.nabble.com/file/p19872463/jconsole_20081008.jpg > > > > > > > -- > View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872463.html > Sent from the OpenJDK Hotspot Garbage Collection mailing list archive > at Nabble.com. > From dragonken at gmail.com Wed Oct 8 06:12:13 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Tue, 7 Oct 2008 23:12:13 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> Message-ID: <19872900.post@talk.nabble.com> Thanks to your quick response. I will do it now but it require 1 - 2 days to reproduce the result. It seems that my case is very special. What the application is simply a stock quote client server and store daily stock quote and chart data in memory. The lived objects need around 80M memory at day open and 500M memory at day end. y.s.ramakrishna wrote: > > > Could you run with the additional option +PrintReferenceGC and see if > it sheds additional light on the problem? (Please share the resulting > GC logs.) > > If at all possible, you might try rev'ing down to 6.0 and seeing > if the same behaviour reproduces or not? > > I understand that some or all of this may not be possible in a > production setting. > > -- ramki > > ----- Original Message ----- > From: "Ken-- at newsgroupstats.hk" > Date: Tuesday, October 7, 2008 10:17 pm > Subject: Re: CMS collection keep working during holiday > To: hotspot-gc-dev at openjdk.java.net > > >> Follow up to the jconsole above. This gif is captured today. You can >> see the >> first CMS after a FULL GC is working. The 2nd one is working too but the >> memory free from 2nd generation is much less than the first CMS. The >> memory >> free by 3rd CMS is further decreased. >> >> The 5th CMS cannot free enough memory to make occanpcy in old-gen to less >> than 70%. So, continue non-stopping CMS happen again until a Full GC >> (triggered by Concurrent Mode Failure). >> >> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg >> >> >> >> >> >> >> -- >> View this message in context: >> http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872463.html >> Sent from the OpenJDK Hotspot Garbage Collection mailing list archive >> at Nabble.com. >> > > -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872900.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From Y.S.Ramakrishna at Sun.COM Wed Oct 8 07:15:26 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Wed, 08 Oct 2008 00:15:26 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <19872900.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <19872900.post@talk.nabble.com> Message-ID: Hi Ken -- You do see of course that in the gc.zip that you made available, there were 4 promotion failures, followed by compacting collections, as listed below in chronological order:- 163116.821: [GC 163116.821: [ParNew: 873856K->174720K(873856K), 0.4830286 secs] 1508484K->961405K(4019584K), 0.4831137 secs] [Times: user=1.59 sys=0.01, real=0. 49 secs] ... 165310.759: [GC 165310.759: [ParNew (promotion failed): 873856K->873856K(873856K), 0.8919148 secs]165311.651:[CMS: 1911965K->785641K(3145728K), 2.9784355 secs] 2733287K->785641K(4019584K), 3.8704903 secs] [Times: user=4.80 sys=0.16, real=3.88 secs] ... 231411.554: [GC 231411.554: [ParNew: 873856K->174720K(873856K), 0.5915618 secs] 1676990K->1122182K(4019584K), 0.5916525 secs] [Times: user=1.45 sys=0.00, real=0 .59 secs] ... 233946.300: [GC 233946.300: [ParNew (promotion failed): 873856K->873856K(873856K), 0.9428034 secs]233947.243: [CMS: 2172134K->570964K(3145728K), 2.7655578 secs] 2969591K->570964K(4019584K), 3.7084973 secs] [Times: user=5.17 sys=0.09, real=3.70 secs] ... 247864.029: [GC 247864.029: [ParNew (promotion failed): 873856K->873855K(873856K), 0.8641325 secs]247864.893: [CMS: 1845477K->499108K(3145728K), 2.2010342 secs] 2628538K->499108K(4019584K), 3.0652834 secs] [Times: user=4.30 sys=0.06, real=3.06 secs] ... 248187.856: [GC 248187.856: [ParNew: 699136K->174719K(873856K), 0.3926926 secs] 1050016K->610565K(4019584K), 0.3927797 secs] [Times: user=1.45 sys=0.03, real=0. 39 secs] ... 265611.034: [GC 265611.034: [ParNew (promotion failed): 873856K->873856K(873856K), 0.6459451 secs]265611.680: [CMS: 1854348K->502128K(3145728K), 2.2556597 secs] 2714667K->502128K(4019584K), 2.9017069 secs] [Times: user=4.19 sys=0.08, real=2.89 secs] ... 502712.808: [GC 502712.808: [ParNew: 873856K->174720K(873856K), 1.2972687 secs] 3806995K->3167193K(4019584K), 1.2973536 secs] [Times: user=1.75 sys=0.00, real=1 .30 secs] ... 504379.249: [GC 504379.249: [ParNew: 873856K->873856K(873856K), 0.0000241 secs]504379.249: [CMS504379.358: [CMS-concurrent-abortable-preclean: 0.209/2.471 secs] [Times: user=1.28 sys=0.00, real=2.48 secs] (concurrent mode failure): 2938816K->424257K(3145728K), 5.2334306 secs] 3812672K->424257K(4019584K), 5.2335621 secs] [Times: user=5.11 sys=0.02, real=5.23 secs] In other words, CMS often does not manage to clear the allocated memory. But the CMS collection preceding the promotion failure indicates heap usage only a little more than what you see after the mark-compact collection. There is almost certainly something fishy going on here. It may be related to Reference objects and their referents being split across generations, but it's not completely clear. [Perhaps you can check if your application makes use of Soft/Weak/References in some funny way, so as to perhaps cause the Reference and referent to be split between the old and new generations?] Now one thing we know about the difference between CMS and a full mark-compact collection is that CMS treats the young gen as a source of roots for the CMS and perm gen collection, whereas this is not so for the latter. In pathological cases, a dead cycle spanning the young gen and the old gen would remain uncollected by CMS but be collected by the mark-compact collection. Now, I don't think that would be happening in your case, but I do see that the frequency of ParNew collections in your case is fairly low -- about 1 every 6 minutes or so. With a tenuring threshold of 11, it's possible for a dead cycle to live for a full hour before it gets promoted into the old generation whence it would be eligible for collection. In some cases, the CMS initiating occupancy fraction has not been hit (and a CMS collection not even attempte) before a promotion failure occurs. This would appear to call for more frequent CMS collections following ParNew collections, even something drastic like:- CMSInitiatingOccupancyFraction=25 This would of course cause your back to back CMS collections that would peg your CPU, in order to avoid that, you might disable the CMS "timeout" via:- CMSWaitDuration=1200000 i.e. make it 20 minutes (=120000 ms). In addition, I find that your scavenges are unnecessarily copying survivors back-and-forth 11 times or so, I'd just scrunch that down to:- MaxTenuringThreshold=1 (or at most 2) This may or may not address the problem you are seeing here but it's at least a start towards eliminating at least some of the suspects and of course of eliminating the "busy work" that CMS is doing during the holidays. -- ramki ----- Original Message ----- From: "Ken-- at newsgroupstats.hk" Date: Tuesday, October 7, 2008 11:14 pm Subject: Re: CMS collection keep working during holiday To: hotspot-gc-dev at openjdk.java.net > Thanks to your quick response. I will do it now but it require 1 - 2 > days to > reproduce the result. > > It seems that my case is very special. > > What the application is simply a stock quote client server and store daily > stock quote and chart data in memory. The lived objects need around 80M > memory at day open and 500M memory at day end. > > > > > y.s.ramakrishna wrote: > > > > > > Could you run with the additional option +PrintReferenceGC and see if > > it sheds additional light on the problem? (Please share the resulting > > GC logs.) > > > > If at all possible, you might try rev'ing down to 6.0 and seeing > > if the same behaviour reproduces or not? > > > > I understand that some or all of this may not be possible in a > > production setting. > > > > -- ramki > > > > ----- Original Message ----- > > From: "Ken-- at newsgroupstats.hk" > > Date: Tuesday, October 7, 2008 10:17 pm > > Subject: Re: CMS collection keep working during holiday > > To: hotspot-gc-dev at openjdk.java.net > > > > > >> Follow up to the jconsole above. This gif is captured today. You > can > >> see the > >> first CMS after a FULL GC is working. The 2nd one is working too > but the > >> memory free from 2nd generation is much less than the first CMS. The > >> memory > >> free by 3rd CMS is further decreased. > >> > >> The 5th CMS cannot free enough memory to make occanpcy in old-gen > to less > >> than 70%. So, continue non-stopping CMS happen again until a Full GC > >> (triggered by Concurrent Mode Failure). > >> > >> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg > >> > >> > >> > >> > >> > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872463.html > >> Sent from the OpenJDK Hotspot Garbage Collection mailing list > archive > >> at Nabble.com. > >> > > > > > > -- > View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872900.html > Sent from the OpenJDK Hotspot Garbage Collection mailing list archive > at Nabble.com. > From Y.S.Ramakrishna at Sun.COM Wed Oct 8 07:43:00 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Wed, 08 Oct 2008 00:43:00 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <19872900.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <19872900.post@talk.nabble.com> Message-ID: Let me see if i understood that:- > What the application is simply a stock quote client server and store daily > stock quote and chart data in memory. The lived objects need around 80M > memory at day open and 500M memory at day end. So you expect that the long-lived objects that will eventually get promoted into the old generation, will start out at about 80 MB at the start of the trading day and will end up about 500 MB at the end of the trading day. What happens at the end of the trading day? Do you discard the entire table, so that the set of long-lived objects would be expected to shrink back to 80 MB after the trading day ends? If I understood your problem correctly (and correct me if i am wrong) you find that the old gen occupancy does not shrink down with concurrent collections at the end of the trading day, but shrinks only upon a mark-compact collection (which typically happens as a result of a promotion failure). (Loud thinking: I am assuming that the same effect would be achieved by calling a System.gc() at the end of the trading day after the table of quotes has been dropped. Of course, we need to figure out why CMS may not reclaim the table even though it has been dropped.] Please correct any misunderstanding of the situation. -- ramki > > y.s.ramakrishna wrote: > > > > > > Could you run with the additional option +PrintReferenceGC and see if > > it sheds additional light on the problem? (Please share the resulting > > GC logs.) > > > > If at all possible, you might try rev'ing down to 6.0 and seeing > > if the same behaviour reproduces or not? > > > > I understand that some or all of this may not be possible in a > > production setting. > > > > -- ramki > > > > ----- Original Message ----- > > From: "Ken-- at newsgroupstats.hk" > > Date: Tuesday, October 7, 2008 10:17 pm > > Subject: Re: CMS collection keep working during holiday > > To: hotspot-gc-dev at openjdk.java.net > > > > > >> Follow up to the jconsole above. This gif is captured today. You > can > >> see the > >> first CMS after a FULL GC is working. The 2nd one is working too > but the > >> memory free from 2nd generation is much less than the first CMS. The > >> memory > >> free by 3rd CMS is further decreased. > >> > >> The 5th CMS cannot free enough memory to make occanpcy in old-gen > to less > >> than 70%. So, continue non-stopping CMS happen again until a Full GC > >> (triggered by Concurrent Mode Failure). > >> > >> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg > >> > >> > >> > >> > >> > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872463.html > >> Sent from the OpenJDK Hotspot Garbage Collection mailing list > archive > >> at Nabble.com. > >> > > > > > > -- > View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872900.html > Sent from the OpenJDK Hotspot Garbage Collection mailing list archive > at Nabble.com. > From dragonken at gmail.com Wed Oct 8 08:00:32 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Wed, 8 Oct 2008 01:00:32 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <19872900.post@talk.nabble.com> Message-ID: <19874157.post@talk.nabble.com> Thanks to your quick response. I will firstly produce the result with +XX:+PrictReferece and then alter the vm options to your set for further testing. > [Perhaps you can check if your application makes use of > Soft/Weak/References > in some funny way, so as to perhaps cause the Reference and referent to be > split between the old and new generations?] I didn't specially play soft / weak references. Even I don't exactly know what is weak reference. Your comment alert me that I have called javolution's api (javolution.text.Text and javolution.text.TypeFormat.parseFloat). In the past, we parse the incoming data feed by calling a lot of Float.parseFloat(String). Last year I found that parseFloat create many temp objects resulting many garbages to be collected. After google I found javolution api. It really have better performance. Javolution's Text Object create instance by ObjectFactory which allocate in stack context. http://javolution.org/api/javolution/context/StackContext.html. I am not sure it's cased by javoltion api. Anyway or method to shoot it? Is adding -XX:+PrintReference help? y.s.ramakrishna wrote: > > Hi Ken -- > > You do see of course that in the gc.zip that you made available, > there were 4 promotion failures, followed by compacting collections, > as listed below in chronological order:- > > 163116.821: [GC 163116.821: [ParNew: 873856K->174720K(873856K), 0.4830286 > secs] 1508484K->961405K(4019584K), 0.4831137 secs] [Times: user=1.59 > sys=0.01, real=0. > 49 secs] > ... > 165310.759: [GC 165310.759: [ParNew (promotion failed): > 873856K->873856K(873856K), 0.8919148 secs]165311.651:[CMS: > 1911965K->785641K(3145728K), 2.9784355 secs] 2733287K->785641K(4019584K), > 3.8704903 secs] [Times: user=4.80 sys=0.16, real=3.88 secs] > ... > 231411.554: [GC 231411.554: [ParNew: 873856K->174720K(873856K), 0.5915618 > secs] 1676990K->1122182K(4019584K), 0.5916525 secs] [Times: user=1.45 > sys=0.00, real=0 > .59 secs] > ... > 233946.300: [GC 233946.300: [ParNew (promotion failed): > 873856K->873856K(873856K), 0.9428034 secs]233947.243: [CMS: > 2172134K->570964K(3145728K), 2.7655578 secs] 2969591K->570964K(4019584K), > 3.7084973 secs] [Times: user=5.17 sys=0.09, real=3.70 secs] > ... > 247864.029: [GC 247864.029: [ParNew (promotion failed): > 873856K->873855K(873856K), 0.8641325 secs]247864.893: [CMS: > 1845477K->499108K(3145728K), 2.2010342 secs] 2628538K->499108K(4019584K), > 3.0652834 secs] [Times: user=4.30 sys=0.06, real=3.06 secs] > ... > 248187.856: [GC 248187.856: [ParNew: 699136K->174719K(873856K), 0.3926926 > secs] 1050016K->610565K(4019584K), 0.3927797 secs] [Times: user=1.45 > sys=0.03, real=0. > 39 secs] > ... > 265611.034: [GC 265611.034: [ParNew (promotion failed): > 873856K->873856K(873856K), 0.6459451 secs]265611.680: [CMS: > 1854348K->502128K(3145728K), 2.2556597 secs] 2714667K->502128K(4019584K), > 2.9017069 secs] [Times: user=4.19 sys=0.08, real=2.89 secs] > ... > 502712.808: [GC 502712.808: [ParNew: 873856K->174720K(873856K), 1.2972687 > secs] 3806995K->3167193K(4019584K), 1.2973536 secs] [Times: user=1.75 > sys=0.00, real=1 > .30 secs] > ... > 504379.249: [GC 504379.249: [ParNew: 873856K->873856K(873856K), 0.0000241 > secs]504379.249: [CMS504379.358: [CMS-concurrent-abortable-preclean: > 0.209/2.471 secs] [Times: user=1.28 sys=0.00, real=2.48 secs] (concurrent > mode failure): 2938816K->424257K(3145728K), 5.2334306 secs] > 3812672K->424257K(4019584K), 5.2335621 secs] [Times: > user=5.11 sys=0.02, real=5.23 secs] > > In other words, CMS often does not manage to clear the allocated > memory. But the CMS collection preceding the promotion failure > indicates heap usage only a little more than what you see after > the mark-compact collection. There is almost certainly something > fishy going on here. It may be related to Reference objects and their > referents being split across generations, but it's not completely clear. > > [Perhaps you can check if your application makes use of > Soft/Weak/References > in some funny way, so as to perhaps cause the Reference and referent to be > split between the old and new generations?] > > Now one thing we know about the difference between CMS and a full > mark-compact > collection is that CMS treats the young gen as a source of roots for the > CMS and perm gen collection, whereas this is not so for the latter. > In pathological cases, a dead cycle spanning the young gen and the > old gen would remain uncollected by CMS but be collected by the > mark-compact > collection. Now, I don't think that would be happening in your case, but I > do see that the frequency of ParNew collections in your case is fairly low > -- > about 1 every 6 minutes or so. With a tenuring threshold of 11, it's > possible > for a dead cycle to live for a full hour before it gets promoted into the > old generation whence it would be eligible for collection. > > In some cases, the CMS initiating occupancy fraction has not been hit > (and a CMS collection not even attempte) before a promotion failure > occurs. This would appear to call for more frequent CMS collections > following ParNew collections, even something drastic like:- > > CMSInitiatingOccupancyFraction=25 > > This would of course cause your back to back CMS collections that > would peg your CPU, in order to avoid that, you might disable the > CMS "timeout" via:- > > CMSWaitDuration=1200000 > > i.e. make it 20 minutes (=120000 ms). > > In addition, I find that your scavenges are unnecessarily copying > survivors back-and-forth 11 times or so, I'd just scrunch that down > to:- > > MaxTenuringThreshold=1 (or at most 2) > > This may or may not address the problem you are seeing here but > it's at least a start towards eliminating at least some of > the suspects and of course of eliminating the "busy work" > that CMS is doing during the holidays. > > -- ramki > > ----- Original Message ----- > From: "Ken-- at newsgroupstats.hk" > Date: Tuesday, October 7, 2008 11:14 pm > Subject: Re: CMS collection keep working during holiday > To: hotspot-gc-dev at openjdk.java.net > > >> Thanks to your quick response. I will do it now but it require 1 - 2 >> days to >> reproduce the result. >> >> It seems that my case is very special. >> >> What the application is simply a stock quote client server and store >> daily >> stock quote and chart data in memory. The lived objects need around 80M >> memory at day open and 500M memory at day end. >> >> >> >> >> y.s.ramakrishna wrote: >> > >> > >> > Could you run with the additional option +PrintReferenceGC and see if >> > it sheds additional light on the problem? (Please share the resulting >> > GC logs.) >> > >> > If at all possible, you might try rev'ing down to 6.0 and seeing >> > if the same behaviour reproduces or not? >> > >> > I understand that some or all of this may not be possible in a >> > production setting. >> > >> > -- ramki >> > >> > ----- Original Message ----- >> > From: "Ken-- at newsgroupstats.hk" >> > Date: Tuesday, October 7, 2008 10:17 pm >> > Subject: Re: CMS collection keep working during holiday >> > To: hotspot-gc-dev at openjdk.java.net >> > >> > >> >> Follow up to the jconsole above. This gif is captured today. You >> can >> >> see the >> >> first CMS after a FULL GC is working. The 2nd one is working too >> but the >> >> memory free from 2nd generation is much less than the first CMS. The >> >> memory >> >> free by 3rd CMS is further decreased. >> >> >> >> The 5th CMS cannot free enough memory to make occanpcy in old-gen >> to less >> >> than 70%. So, continue non-stopping CMS happen again until a Full GC >> >> (triggered by Concurrent Mode Failure). >> >> >> >> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872463.html >> >> Sent from the OpenJDK Hotspot Garbage Collection mailing list >> archive >> >> at Nabble.com. >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872900.html >> Sent from the OpenJDK Hotspot Garbage Collection mailing list archive >> at Nabble.com. >> > > -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19874157.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From dragonken at gmail.com Wed Oct 8 08:13:17 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Wed, 8 Oct 2008 01:13:17 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <19872900.post@talk.nabble.com> Message-ID: <19874318.post@talk.nabble.com> Thanks to your quick response. You are correct. I use this option set to find out how large is my lived objects: -Xmx1536M -Xms1536M -XX:NewSize=256M -XX:MaxNewSize=256M -XX:+ExplicitGCInvokesConcurrent (Yes, pressing Full-GC in jconsole or call System.gc() in application can have same effect.) The application will daily reset all lived objects at 9:00am(holiday or non-trading day will not). Day open at 9:30am and day end at 4:30pm. From jconsole, I can see the heap chart raise steadily from 80M(9:30am) to 5xxM(4:30pm), if use the vm options above. Y Srinivas Ramakrishna wrote: > > > Let me see if i understood that:- > >> What the application is simply a stock quote client server and store >> daily >> stock quote and chart data in memory. The lived objects need around 80M >> memory at day open and 500M memory at day end. > > So you expect that the long-lived objects that will eventually get > promoted into the old generation, will start out at about 80 MB > at the start of the trading day and will end up about 500 MB at the > end of the trading day. > > What happens at the end of the trading day? Do you discard the entire > table, so that the set of long-lived objects would be expected to shrink > back to 80 MB after the trading day ends? > > If I understood your problem correctly (and correct me if i am wrong) > you find that the old gen occupancy does not shrink down with > concurrent collections at the end of the trading day, but shrinks only > upon a mark-compact collection (which typically happens as a result of > a promotion failure). > > (Loud thinking: I am assuming that the same effect would be achieved > by calling a System.gc() at the end of the trading day after the > table of quotes has been dropped. Of course, we need to figure out > why CMS may not reclaim the table even though it has been dropped.] > > Please correct any misunderstanding of the situation. > -- ramki > >> >> y.s.ramakrishna wrote: >> > >> > >> > Could you run with the additional option +PrintReferenceGC and see if >> > it sheds additional light on the problem? (Please share the resulting >> > GC logs.) >> > >> > If at all possible, you might try rev'ing down to 6.0 and seeing >> > if the same behaviour reproduces or not? >> > >> > I understand that some or all of this may not be possible in a >> > production setting. >> > >> > -- ramki >> > >> > ----- Original Message ----- >> > From: "Ken-- at newsgroupstats.hk" >> > Date: Tuesday, October 7, 2008 10:17 pm >> > Subject: Re: CMS collection keep working during holiday >> > To: hotspot-gc-dev at openjdk.java.net >> > >> > >> >> Follow up to the jconsole above. This gif is captured today. You >> can >> >> see the >> >> first CMS after a FULL GC is working. The 2nd one is working too >> but the >> >> memory free from 2nd generation is much less than the first CMS. The >> >> memory >> >> free by 3rd CMS is further decreased. >> >> >> >> The 5th CMS cannot free enough memory to make occanpcy in old-gen >> to less >> >> than 70%. So, continue non-stopping CMS happen again until a Full GC >> >> (triggered by Concurrent Mode Failure). >> >> >> >> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872463.html >> >> Sent from the OpenJDK Hotspot Garbage Collection mailing list >> archive >> >> at Nabble.com. >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872900.html >> Sent from the OpenJDK Hotspot Garbage Collection mailing list archive >> at Nabble.com. >> > > -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19874318.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From dragonken at gmail.com Wed Oct 8 08:26:09 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Wed, 8 Oct 2008 01:26:09 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <19872900.post@talk.nabble.com> Message-ID: <19874498.post@talk.nabble.com> I have started same applications in a separated old 32bits windows with your additional suggested options VM arguments:? -Djava.security.policy=.\java.policy -Xms1536M -Xmx1536M -XX:NewSize=256M -XX:+PrintGCDetails -XX:+PrintGCTaskTimeStamps -XX:+PrintHeapAtGC -Xloggc:hkexquoteserver_gc.log -XX:+PrintReferenceGC -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=4 -XX:CMSInitiatingOccupancyFraction=70 -XX:TargetSurvivorRatio=90 -Dcom.sun.management.jmxremote.port=18002 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false http://www.nabble.com/file/p19874498/gc_20081008.zip gc_20081008.zip I will upload the gc log again once the problem is reproduced. Thanks to all. Regards, Ken -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19874498.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From Y.S.Ramakrishna at Sun.COM Wed Oct 8 09:10:38 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Wed, 08 Oct 2008 02:10:38 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <48EC7118.8050009@javaperformancetuning.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <19872900.post@talk.nabble.com> <48EC7118.8050009@javaperformancetuning.com> Message-ID: Hi Kirk -- > Nice analysis. Maybe I've missed it but I've not seen anything that > rules out a simple object leak. Until the leak has been ruled out > would > you prefer to keep objects out of tenured rather than quickly > promoting > them to a space that is already under enormous pressure? Do you see > extra copying as even being relevant to this problem? The extra copying is relevant only in as much as avoiding it will reduce the scavenge pauses to approximately 1/5 (or lower) of their current value. However, you are right that this will not change by much the promotion _rate_ into the tenured gen. (it will increase by a tad, but not by much.) Thus, tenuring after aging for a single scavenge appears to be a win-win. Now the reason I suggested the quick tenuring was because i suspected that the difference between CMS and mark-compact collections is showing up because the new gen is treated as a source of roots into the old gen and perhaps the quicker tenuring will reduce the # "false roots" if you will (see my reference to Reference objects and to cycles spanning across the generations; the idea is to avoid carrying around such potential garbage). You are right though that perhaps it's a simple object leak. What makes it strange, and makes it somewhat unlikely to be a simple memory leak is how a mark-compact collection reclaims the space whereas a concurrent collection does not (even accounting for some small amount of floating garbage because of concurrent marking -- of which there should be little in the present case of long inter-scavenge durations and frequent back-to-back CMS collections). As regards pressure on the tenured gen: the logs actually indicate that the promotion rate into the old gen is not that great (note that each scavenge promotes only about 10-11 MB or so of data into the old gen and scavenges happen only about once every 6 minutes, making for a promotion rate of about 30 KB/s which is fairly low. As you will have noted the CMS cycles are essentially "busy work" cycles (in that the work is unnecessary and does not accomplish anything; thus must not be mistaken for the need for a lot of work). It is true, however, that there is some "pressure" in the sense that the occupancy, as described by Ken, keeps increasing over the course of the day ... -- ramki > > Regards, > Kirk > > Y Srinivas Ramakrishna wrote: > > Hi Ken -- > > > > You do see of course that in the gc.zip that you made available, > > there were 4 promotion failures, followed by compacting collections, > > as listed below in chronological order:- > > > > 163116.821: [GC 163116.821: [ParNew: 873856K->174720K(873856K), > 0.4830286 secs] 1508484K->961405K(4019584K), 0.4831137 secs] [Times: > user=1.59 sys=0.01, real=0. > > 49 secs] > > ... > > 165310.759: [GC 165310.759: [ParNew (promotion failed): > 873856K->873856K(873856K), 0.8919148 secs]165311.651:[CMS: > 1911965K->785641K(3145728K), 2.9784355 secs] > 2733287K->785641K(4019584K), 3.8704903 secs] [Times: user=4.80 > sys=0.16, real=3.88 secs] > > ... > > 231411.554: [GC 231411.554: [ParNew: 873856K->174720K(873856K), > 0.5915618 secs] 1676990K->1122182K(4019584K), 0.5916525 secs] [Times: > user=1.45 sys=0.00, real=0 > > .59 secs] > > ... > > 233946.300: [GC 233946.300: [ParNew (promotion failed): > 873856K->873856K(873856K), 0.9428034 secs]233947.243: [CMS: > 2172134K->570964K(3145728K), 2.7655578 secs] > 2969591K->570964K(4019584K), 3.7084973 secs] [Times: user=5.17 > sys=0.09, real=3.70 secs] > > ... > > 247864.029: [GC 247864.029: [ParNew (promotion failed): > 873856K->873855K(873856K), 0.8641325 secs]247864.893: [CMS: > 1845477K->499108K(3145728K), 2.2010342 secs] > 2628538K->499108K(4019584K), 3.0652834 secs] [Times: user=4.30 > sys=0.06, real=3.06 secs] > > ... > > 248187.856: [GC 248187.856: [ParNew: 699136K->174719K(873856K), > 0.3926926 secs] 1050016K->610565K(4019584K), 0.3927797 secs] [Times: > user=1.45 sys=0.03, real=0. > > 39 secs] > > ... > > 265611.034: [GC 265611.034: [ParNew (promotion failed): > 873856K->873856K(873856K), 0.6459451 secs]265611.680: [CMS: > 1854348K->502128K(3145728K), 2.2556597 secs] > 2714667K->502128K(4019584K), 2.9017069 secs] [Times: user=4.19 > sys=0.08, real=2.89 secs] > > ... > > 502712.808: [GC 502712.808: [ParNew: 873856K->174720K(873856K), > 1.2972687 secs] 3806995K->3167193K(4019584K), 1.2973536 secs] [Times: > user=1.75 sys=0.00, real=1 > > .30 secs] > > ... > > 504379.249: [GC 504379.249: [ParNew: 873856K->873856K(873856K), > 0.0000241 secs]504379.249: [CMS504379.358: > [CMS-concurrent-abortable-preclean: 0.209/2.471 secs] [Times: > user=1.28 sys=0.00, real=2.48 secs] (concurrent mode failure): > 2938816K->424257K(3145728K), 5.2334306 secs] > 3812672K->424257K(4019584K), 5.2335621 secs] [Times: > > user=5.11 sys=0.02, real=5.23 secs] > > > > In other words, CMS often does not manage to clear the allocated > > memory. But the CMS collection preceding the promotion failure > > indicates heap usage only a little more than what you see after > > the mark-compact collection. There is almost certainly something > > fishy going on here. It may be related to Reference objects and their > > referents being split across generations, but it's not completely clear. > > > > [Perhaps you can check if your application makes use of Soft/Weak/References > > in some funny way, so as to perhaps cause the Reference and referent > to be > > split between the old and new generations?] > > > > Now one thing we know about the difference between CMS and a full mark-compact > > collection is that CMS treats the young gen as a source of roots for > the > > CMS and perm gen collection, whereas this is not so for the latter. > > In pathological cases, a dead cycle spanning the young gen and the > > old gen would remain uncollected by CMS but be collected by the mark-compact > > collection. Now, I don't think that would be happening in your case, > but I > > do see that the frequency of ParNew collections in your case is > fairly low -- > > about 1 every 6 minutes or so. With a tenuring threshold of 11, it's > possible > > for a dead cycle to live for a full hour before it gets promoted > into the > > old generation whence it would be eligible for collection. > > > > In some cases, the CMS initiating occupancy fraction has not been hit > > (and a CMS collection not even attempte) before a promotion failure > > occurs. This would appear to call for more frequent CMS collections > > following ParNew collections, even something drastic like:- > > > > CMSInitiatingOccupancyFraction=25 > > > > This would of course cause your back to back CMS collections that > > would peg your CPU, in order to avoid that, you might disable the > > CMS "timeout" via:- > > > > CMSWaitDuration=1200000 > > > > i.e. make it 20 minutes (=120000 ms). > > > > In addition, I find that your scavenges are unnecessarily copying > > survivors back-and-forth 11 times or so, I'd just scrunch that down > > to:- > > > > MaxTenuringThreshold=1 (or at most 2) > > > > This may or may not address the problem you are seeing here but > > it's at least a start towards eliminating at least some of > > the suspects and of course of eliminating the "busy work" > > that CMS is doing during the holidays. > > > > -- ramki > > > > ----- Original Message ----- > > From: "Ken-- at newsgroupstats.hk" > > Date: Tuesday, October 7, 2008 11:14 pm > > Subject: Re: CMS collection keep working during holiday > > To: hotspot-gc-dev at openjdk.java.net > > > > > > > >> Thanks to your quick response. I will do it now but it require 1 - > 2 > >> days to > >> reproduce the result. > >> > >> It seems that my case is very special. > >> > >> What the application is simply a stock quote client server and > store daily > >> stock quote and chart data in memory. The lived objects need around > 80M > >> memory at day open and 500M memory at day end. > >> > >> > >> > >> > >> y.s.ramakrishna wrote: > >> > >>> Could you run with the additional option +PrintReferenceGC and see > if > >>> it sheds additional light on the problem? (Please share the resulting > >>> GC logs.) > >>> > >>> If at all possible, you might try rev'ing down to 6.0 and seeing > >>> if the same behaviour reproduces or not? > >>> > >>> I understand that some or all of this may not be possible in a > >>> production setting. > >>> > >>> -- ramki > >>> > >>> ----- Original Message ----- > >>> From: "Ken-- at newsgroupstats.hk" > >>> Date: Tuesday, October 7, 2008 10:17 pm > >>> Subject: Re: CMS collection keep working during holiday > >>> To: hotspot-gc-dev at openjdk.java.net > >>> > >>> > >>> > >>>> Follow up to the jconsole above. This gif is captured today. You > > >>>> > >> can > >> > >>>> see the > >>>> first CMS after a FULL GC is working. The 2nd one is working too > > >>>> > >> but the > >> > >>>> memory free from 2nd generation is much less than the first CMS. > The > >>>> memory > >>>> free by 3rd CMS is further decreased. > >>>> > >>>> The 5th CMS cannot free enough memory to make occanpcy in old-gen > > >>>> > >> to less > >> > >>>> than 70%. So, continue non-stopping CMS happen again until a Full > GC > >>>> (triggered by Concurrent Mode Failure). > >>>> > >>>> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> View this message in context: > >>>> http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872463.html > >>>> Sent from the OpenJDK Hotspot Garbage Collection mailing list > >>>> > >> archive > >> > >>>> at Nabble.com. > >>>> > >>>> > >>> > >> -- > >> View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872900.html > >> Sent from the OpenJDK Hotspot Garbage Collection mailing list > archive > >> at Nabble.com. > >> > >> > > > > > From Y.S.Ramakrishna at Sun.COM Wed Oct 8 09:17:29 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Wed, 08 Oct 2008 02:17:29 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <19874318.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <19872900.post@talk.nabble.com> <19874318.post@talk.nabble.com> Message-ID: Hi Ken -- > > You are correct. > > I use this option set to find out how large is my lived objects: > > -Xmx1536M -Xms1536M -XX:NewSize=256M -XX:MaxNewSize=256M > -XX:+ExplicitGCInvokesConcurrent > > (Yes, pressing Full-GC in jconsole or call System.gc() in application > can > have same effect.) A word of caution, re the differences between a concurrent collection and a mark-compact collection as discussed earlier... Note that ExplicitGCInvokesConcurrent will upon a System.gc() or jconsole/FullGC precipitate a concurrent collection, not a mark-compact collection (which you would get in the absence of the ExplicitGCInvokesConcurrent flag) when using the CMS collector. > > The application will daily reset all lived objects at 9:00am(holiday or > non-trading day will not). Day open at 9:30am and day end at 4:30pm. From > jconsole, I can see the heap chart raise steadily from 80M(9:30am) to > 5xxM(4:30pm), if use the vm options above. Ah, that is an important data point, because it seems to imply that at least when trading is not in session, CMS collection behaves like mark-compact collection in terms of reclaiming space... -- ramki > > > > Y Srinivas Ramakrishna wrote: > > > > > > Let me see if i understood that:- > > > >> What the application is simply a stock quote client server and store > >> daily > >> stock quote and chart data in memory. The lived objects need around > 80M > >> memory at day open and 500M memory at day end. > > > > So you expect that the long-lived objects that will eventually get > > promoted into the old generation, will start out at about 80 MB > > at the start of the trading day and will end up about 500 MB at the > > end of the trading day. > > > > What happens at the end of the trading day? Do you discard the entire > > table, so that the set of long-lived objects would be expected to shrink > > back to 80 MB after the trading day ends? > > > > If I understood your problem correctly (and correct me if i am wrong) > > you find that the old gen occupancy does not shrink down with > > concurrent collections at the end of the trading day, but shrinks only > > upon a mark-compact collection (which typically happens as a result > of > > a promotion failure). > > > > (Loud thinking: I am assuming that the same effect would be achieved > > by calling a System.gc() at the end of the trading day after the > > table of quotes has been dropped. Of course, we need to figure out > > why CMS may not reclaim the table even though it has been dropped.] > > > > Please correct any misunderstanding of the situation. > > -- ramki > > > >> > >> y.s.ramakrishna wrote: > >> > > >> > > >> > Could you run with the additional option +PrintReferenceGC and > see if > >> > it sheds additional light on the problem? (Please share the resulting > >> > GC logs.) > >> > > >> > If at all possible, you might try rev'ing down to 6.0 and seeing > >> > if the same behaviour reproduces or not? > >> > > >> > I understand that some or all of this may not be possible in a > >> > production setting. > >> > > >> > -- ramki > >> > > >> > ----- Original Message ----- > >> > From: "Ken-- at newsgroupstats.hk" > >> > Date: Tuesday, October 7, 2008 10:17 pm > >> > Subject: Re: CMS collection keep working during holiday > >> > To: hotspot-gc-dev at openjdk.java.net > >> > > >> > > >> >> Follow up to the jconsole above. This gif is captured today. You > > >> can > >> >> see the > >> >> first CMS after a FULL GC is working. The 2nd one is working too > > >> but the > >> >> memory free from 2nd generation is much less than the first CMS. > The > >> >> memory > >> >> free by 3rd CMS is further decreased. > >> >> > >> >> The 5th CMS cannot free enough memory to make occanpcy in > old-gen > >> to less > >> >> than 70%. So, continue non-stopping CMS happen again until a > Full GC > >> >> (triggered by Concurrent Mode Failure). > >> >> > >> >> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> View this message in context: > >> >> > >> http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872463.html > >> >> Sent from the OpenJDK Hotspot Garbage Collection mailing list > >> archive > >> >> at Nabble.com. > >> >> > >> > > >> > > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872900.html > >> Sent from the OpenJDK Hotspot Garbage Collection mailing list > archive > >> at Nabble.com. > >> > > > > > > -- > View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19874318.html > Sent from the OpenJDK Hotspot Garbage Collection mailing list archive > at Nabble.com. > From dragonken at gmail.com Wed Oct 8 11:37:29 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Wed, 8 Oct 2008 04:37:29 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> Message-ID: <19877052.post@talk.nabble.com> Y Srinivas Ramakrishna wrote: > > > Could you run with the additional option +PrintReferenceGC and see if > it sheds additional light on the problem? (Please share the resulting > GC logs.) > > If at all possible, you might try rev'ing down to 6.0 and seeing > if the same behaviour reproduces or not? > > I understand that some or all of this may not be possible in a > production setting. > > -- ramki > Attached http://www.nabble.com/file/p19877052/gc_20081008.zip gc_20081008.zip -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19877052.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From kirk.pepperdine at gmail.com Wed Oct 8 07:08:10 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Wed, 08 Oct 2008 09:08:10 +0200 Subject: CMS collection keep working during holiday In-Reply-To: <19872463.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> Message-ID: <48EC5C5A.4030401@javaperformancetuning.com> Ken-- at newsgroupstats.hk wrote: > Follow up to the jconsole above. This gif is captured today. You can see the > first CMS after a FULL GC is working. The 2nd one is working too but the > memory free from 2nd generation is much less than the first CMS. The memory > free by 3rd CMS is further decreased. > > The 5th CMS cannot free enough memory to make occanpcy in old-gen to less > than 70%. So, continue non-stopping CMS happen again until a Full GC > (triggered by Concurrent Mode Failure). > > http://www.nabble.com/file/p19872463/jconsole_20081008.jpg > > > > > > > If GC is failing to recover memory, you either have a memory leak or long loitering objects. I'd suggest visualvm or netbeans memory profiling using the generations option to find out what objects are surviving Regards, Kirk From kirk.pepperdine at gmail.com Wed Oct 8 08:36:40 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Wed, 08 Oct 2008 10:36:40 +0200 Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <19872900.post@talk.nabble.com> Message-ID: <48EC7118.8050009@javaperformancetuning.com> Hi Srinivas, Ken, Nice analysis. Maybe I've missed it but I've not seen anything that rules out a simple object leak. Until the leak has been ruled out would you prefer to keep objects out of tenured rather than quickly promoting them to a space that is already under enormous pressure? Do you see extra copying as even being relevant to this problem? Regards, Kirk Y Srinivas Ramakrishna wrote: > Hi Ken -- > > You do see of course that in the gc.zip that you made available, > there were 4 promotion failures, followed by compacting collections, > as listed below in chronological order:- > > 163116.821: [GC 163116.821: [ParNew: 873856K->174720K(873856K), 0.4830286 secs] 1508484K->961405K(4019584K), 0.4831137 secs] [Times: user=1.59 sys=0.01, real=0. > 49 secs] > ... > 165310.759: [GC 165310.759: [ParNew (promotion failed): 873856K->873856K(873856K), 0.8919148 secs]165311.651:[CMS: 1911965K->785641K(3145728K), 2.9784355 secs] 2733287K->785641K(4019584K), 3.8704903 secs] [Times: user=4.80 sys=0.16, real=3.88 secs] > ... > 231411.554: [GC 231411.554: [ParNew: 873856K->174720K(873856K), 0.5915618 secs] 1676990K->1122182K(4019584K), 0.5916525 secs] [Times: user=1.45 sys=0.00, real=0 > .59 secs] > ... > 233946.300: [GC 233946.300: [ParNew (promotion failed): 873856K->873856K(873856K), 0.9428034 secs]233947.243: [CMS: 2172134K->570964K(3145728K), 2.7655578 secs] 2969591K->570964K(4019584K), 3.7084973 secs] [Times: user=5.17 sys=0.09, real=3.70 secs] > ... > 247864.029: [GC 247864.029: [ParNew (promotion failed): 873856K->873855K(873856K), 0.8641325 secs]247864.893: [CMS: 1845477K->499108K(3145728K), 2.2010342 secs] 2628538K->499108K(4019584K), 3.0652834 secs] [Times: user=4.30 sys=0.06, real=3.06 secs] > ... > 248187.856: [GC 248187.856: [ParNew: 699136K->174719K(873856K), 0.3926926 secs] 1050016K->610565K(4019584K), 0.3927797 secs] [Times: user=1.45 sys=0.03, real=0. > 39 secs] > ... > 265611.034: [GC 265611.034: [ParNew (promotion failed): 873856K->873856K(873856K), 0.6459451 secs]265611.680: [CMS: 1854348K->502128K(3145728K), 2.2556597 secs] 2714667K->502128K(4019584K), 2.9017069 secs] [Times: user=4.19 sys=0.08, real=2.89 secs] > ... > 502712.808: [GC 502712.808: [ParNew: 873856K->174720K(873856K), 1.2972687 secs] 3806995K->3167193K(4019584K), 1.2973536 secs] [Times: user=1.75 sys=0.00, real=1 > .30 secs] > ... > 504379.249: [GC 504379.249: [ParNew: 873856K->873856K(873856K), 0.0000241 secs]504379.249: [CMS504379.358: [CMS-concurrent-abortable-preclean: 0.209/2.471 secs] [Times: user=1.28 sys=0.00, real=2.48 secs] (concurrent mode failure): 2938816K->424257K(3145728K), 5.2334306 secs] 3812672K->424257K(4019584K), 5.2335621 secs] [Times: > user=5.11 sys=0.02, real=5.23 secs] > > In other words, CMS often does not manage to clear the allocated > memory. But the CMS collection preceding the promotion failure > indicates heap usage only a little more than what you see after > the mark-compact collection. There is almost certainly something > fishy going on here. It may be related to Reference objects and their > referents being split across generations, but it's not completely clear. > > [Perhaps you can check if your application makes use of Soft/Weak/References > in some funny way, so as to perhaps cause the Reference and referent to be > split between the old and new generations?] > > Now one thing we know about the difference between CMS and a full mark-compact > collection is that CMS treats the young gen as a source of roots for the > CMS and perm gen collection, whereas this is not so for the latter. > In pathological cases, a dead cycle spanning the young gen and the > old gen would remain uncollected by CMS but be collected by the mark-compact > collection. Now, I don't think that would be happening in your case, but I > do see that the frequency of ParNew collections in your case is fairly low -- > about 1 every 6 minutes or so. With a tenuring threshold of 11, it's possible > for a dead cycle to live for a full hour before it gets promoted into the > old generation whence it would be eligible for collection. > > In some cases, the CMS initiating occupancy fraction has not been hit > (and a CMS collection not even attempte) before a promotion failure > occurs. This would appear to call for more frequent CMS collections > following ParNew collections, even something drastic like:- > > CMSInitiatingOccupancyFraction=25 > > This would of course cause your back to back CMS collections that > would peg your CPU, in order to avoid that, you might disable the > CMS "timeout" via:- > > CMSWaitDuration=1200000 > > i.e. make it 20 minutes (=120000 ms). > > In addition, I find that your scavenges are unnecessarily copying > survivors back-and-forth 11 times or so, I'd just scrunch that down > to:- > > MaxTenuringThreshold=1 (or at most 2) > > This may or may not address the problem you are seeing here but > it's at least a start towards eliminating at least some of > the suspects and of course of eliminating the "busy work" > that CMS is doing during the holidays. > > -- ramki > > ----- Original Message ----- > From: "Ken-- at newsgroupstats.hk" > Date: Tuesday, October 7, 2008 11:14 pm > Subject: Re: CMS collection keep working during holiday > To: hotspot-gc-dev at openjdk.java.net > > > >> Thanks to your quick response. I will do it now but it require 1 - 2 >> days to >> reproduce the result. >> >> It seems that my case is very special. >> >> What the application is simply a stock quote client server and store daily >> stock quote and chart data in memory. The lived objects need around 80M >> memory at day open and 500M memory at day end. >> >> >> >> >> y.s.ramakrishna wrote: >> >>> Could you run with the additional option +PrintReferenceGC and see if >>> it sheds additional light on the problem? (Please share the resulting >>> GC logs.) >>> >>> If at all possible, you might try rev'ing down to 6.0 and seeing >>> if the same behaviour reproduces or not? >>> >>> I understand that some or all of this may not be possible in a >>> production setting. >>> >>> -- ramki >>> >>> ----- Original Message ----- >>> From: "Ken-- at newsgroupstats.hk" >>> Date: Tuesday, October 7, 2008 10:17 pm >>> Subject: Re: CMS collection keep working during holiday >>> To: hotspot-gc-dev at openjdk.java.net >>> >>> >>> >>>> Follow up to the jconsole above. This gif is captured today. You >>>> >> can >> >>>> see the >>>> first CMS after a FULL GC is working. The 2nd one is working too >>>> >> but the >> >>>> memory free from 2nd generation is much less than the first CMS. The >>>> memory >>>> free by 3rd CMS is further decreased. >>>> >>>> The 5th CMS cannot free enough memory to make occanpcy in old-gen >>>> >> to less >> >>>> than 70%. So, continue non-stopping CMS happen again until a Full GC >>>> (triggered by Concurrent Mode Failure). >>>> >>>> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872463.html >>>> Sent from the OpenJDK Hotspot Garbage Collection mailing list >>>> >> archive >> >>>> at Nabble.com. >>>> >>>> >>> >> -- >> View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872900.html >> Sent from the OpenJDK Hotspot Garbage Collection mailing list archive >> at Nabble.com. >> >> > > From kirk.pepperdine at gmail.com Wed Oct 8 09:30:32 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Wed, 08 Oct 2008 11:30:32 +0200 Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <19872900.post@talk.nabble.com> <48EC7118.8050009@javaperformancetuning.com> Message-ID: <48EC7DB8.50602@javaperformancetuning.com> Y Srinivas Ramakrishna wrote: > Hi Kirk -- > > >> Nice analysis. Maybe I've missed it but I've not seen anything that >> rules out a simple object leak. Until the leak has been ruled out >> would >> you prefer to keep objects out of tenured rather than quickly >> promoting >> them to a space that is already under enormous pressure? Do you see >> extra copying as even being relevant to this problem? >> > > The extra copying is relevant only in as much as avoiding it will > reduce the scavenge pauses to approximately 1/5 (or lower) of > their current value. However, you are right that this will not > change by much the promotion _rate_ into the tenured gen. > (it will increase by a tad, but not by much.) Thus, tenuring > after aging for a single scavenge appears to be a win-win. > ok, that makes sense. > Now the reason I suggested the quick tenuring was because > i suspected that the difference between CMS and mark-compact > collections is showing up because the new gen is treated > as a source of roots into the old gen and perhaps the quicker > tenuring will reduce the # "false roots" if you will > (see my reference to Reference objects and to cycles > spanning across the generations; the idea is to avoid > carrying around such potential garbage). > ok, but the jconsole snaps show that old is quite full and isn't emptying... > You are right though that perhaps it's a simple object leak. > What makes it strange, and makes it somewhat unlikely to be a simple > memory leak is how a mark-compact collection reclaims the > space whereas a concurrent collection does not (even accounting > for some small amount of floating garbage because of concurrent > marking -- of which there should be little in the present case > of long inter-scavenge durations and frequent back-to-back CMS > collections). > Ok, this is the bit that I missed. So this actually appears to be strong evidence that CMS is failing. Same application only two different implementations of memory management, one reclaims and the other doesn't. I was thinking in relation to your comment on false roots was that forcing more young collections might actually result in more being released if your hypothesis is correct in this case. > As regards pressure on the tenured gen: the logs actually indicate > that the promotion rate into the old gen is not that great (note > that each scavenge promotes only about 10-11 MB or so of data > into the old gen and scavenges happen only about once every 6 minutes, > making for a promotion rate of about 30 KB/s which is fairly low. > As you will have noted the CMS cycles are essentially "busy work" > cycles (in that the work is unnecessary and does not accomplish > anything; thus must not be mistaken for the need for a lot of > work). It is true, however, that there is some "pressure" > in the sense that the occupancy, as described by Ken, keeps > increasing over the course of the day ... > right, I wasn't concerned with rate only with occupancy. Throwing stuff into tenured when it is mostly full... What do you think the effect of creating large survivor space might have on the problem? I'm wondering if a limited Eden would trigger more scavenges which wouldn't have to deal with "false" roots? Of course this would increase the overall copying cost but I have managed to trick JVMs into being stable for long periods of time using this technique in the past. No matter, it would beinteresting to bang through a days worth of activity with the vm under a scope. Regards, Kirk > -- ramki > > >> Regards, >> Kirk >> >> Y Srinivas Ramakrishna wrote: >> >>> Hi Ken -- >>> >>> You do see of course that in the gc.zip that you made available, >>> there were 4 promotion failures, followed by compacting collections, >>> as listed below in chronological order:- >>> >>> 163116.821: [GC 163116.821: [ParNew: 873856K->174720K(873856K), >>> >> 0.4830286 secs] 1508484K->961405K(4019584K), 0.4831137 secs] [Times: >> user=1.59 sys=0.01, real=0. >> >>> 49 secs] >>> ... >>> 165310.759: [GC 165310.759: [ParNew (promotion failed): >>> >> 873856K->873856K(873856K), 0.8919148 secs]165311.651:[CMS: >> 1911965K->785641K(3145728K), 2.9784355 secs] >> 2733287K->785641K(4019584K), 3.8704903 secs] [Times: user=4.80 >> sys=0.16, real=3.88 secs] >> >>> ... >>> 231411.554: [GC 231411.554: [ParNew: 873856K->174720K(873856K), >>> >> 0.5915618 secs] 1676990K->1122182K(4019584K), 0.5916525 secs] [Times: >> user=1.45 sys=0.00, real=0 >> >>> .59 secs] >>> ... >>> 233946.300: [GC 233946.300: [ParNew (promotion failed): >>> >> 873856K->873856K(873856K), 0.9428034 secs]233947.243: [CMS: >> 2172134K->570964K(3145728K), 2.7655578 secs] >> 2969591K->570964K(4019584K), 3.7084973 secs] [Times: user=5.17 >> sys=0.09, real=3.70 secs] >> >>> ... >>> 247864.029: [GC 247864.029: [ParNew (promotion failed): >>> >> 873856K->873855K(873856K), 0.8641325 secs]247864.893: [CMS: >> 1845477K->499108K(3145728K), 2.2010342 secs] >> 2628538K->499108K(4019584K), 3.0652834 secs] [Times: user=4.30 >> sys=0.06, real=3.06 secs] >> >>> ... >>> 248187.856: [GC 248187.856: [ParNew: 699136K->174719K(873856K), >>> >> 0.3926926 secs] 1050016K->610565K(4019584K), 0.3927797 secs] [Times: >> user=1.45 sys=0.03, real=0. >> >>> 39 secs] >>> ... >>> 265611.034: [GC 265611.034: [ParNew (promotion failed): >>> >> 873856K->873856K(873856K), 0.6459451 secs]265611.680: [CMS: >> 1854348K->502128K(3145728K), 2.2556597 secs] >> 2714667K->502128K(4019584K), 2.9017069 secs] [Times: user=4.19 >> sys=0.08, real=2.89 secs] >> >>> ... >>> 502712.808: [GC 502712.808: [ParNew: 873856K->174720K(873856K), >>> >> 1.2972687 secs] 3806995K->3167193K(4019584K), 1.2973536 secs] [Times: >> user=1.75 sys=0.00, real=1 >> >>> .30 secs] >>> ... >>> 504379.249: [GC 504379.249: [ParNew: 873856K->873856K(873856K), >>> >> 0.0000241 secs]504379.249: [CMS504379.358: >> [CMS-concurrent-abortable-preclean: 0.209/2.471 secs] [Times: >> user=1.28 sys=0.00, real=2.48 secs] (concurrent mode failure): >> 2938816K->424257K(3145728K), 5.2334306 secs] >> 3812672K->424257K(4019584K), 5.2335621 secs] [Times: >> >>> user=5.11 sys=0.02, real=5.23 secs] >>> >>> In other words, CMS often does not manage to clear the allocated >>> memory. But the CMS collection preceding the promotion failure >>> indicates heap usage only a little more than what you see after >>> the mark-compact collection. There is almost certainly something >>> fishy going on here. It may be related to Reference objects and their >>> referents being split across generations, but it's not completely clear. >>> >>> [Perhaps you can check if your application makes use of Soft/Weak/References >>> in some funny way, so as to perhaps cause the Reference and referent >>> >> to be >> >>> split between the old and new generations?] >>> >>> Now one thing we know about the difference between CMS and a full mark-compact >>> collection is that CMS treats the young gen as a source of roots for >>> >> the >> >>> CMS and perm gen collection, whereas this is not so for the latter. >>> In pathological cases, a dead cycle spanning the young gen and the >>> old gen would remain uncollected by CMS but be collected by the mark-compact >>> collection. Now, I don't think that would be happening in your case, >>> >> but I >> >>> do see that the frequency of ParNew collections in your case is >>> >> fairly low -- >> >>> about 1 every 6 minutes or so. With a tenuring threshold of 11, it's >>> >> possible >> >>> for a dead cycle to live for a full hour before it gets promoted >>> >> into the >> >>> old generation whence it would be eligible for collection. >>> >>> In some cases, the CMS initiating occupancy fraction has not been hit >>> (and a CMS collection not even attempte) before a promotion failure >>> occurs. This would appear to call for more frequent CMS collections >>> following ParNew collections, even something drastic like:- >>> >>> CMSInitiatingOccupancyFraction=25 >>> >>> This would of course cause your back to back CMS collections that >>> would peg your CPU, in order to avoid that, you might disable the >>> CMS "timeout" via:- >>> >>> CMSWaitDuration=1200000 >>> >>> i.e. make it 20 minutes (=120000 ms). >>> >>> In addition, I find that your scavenges are unnecessarily copying >>> survivors back-and-forth 11 times or so, I'd just scrunch that down >>> to:- >>> >>> MaxTenuringThreshold=1 (or at most 2) >>> >>> This may or may not address the problem you are seeing here but >>> it's at least a start towards eliminating at least some of >>> the suspects and of course of eliminating the "busy work" >>> that CMS is doing during the holidays. >>> >>> -- ramki >>> >>> ----- Original Message ----- >>> From: "Ken-- at newsgroupstats.hk" >>> Date: Tuesday, October 7, 2008 11:14 pm >>> Subject: Re: CMS collection keep working during holiday >>> To: hotspot-gc-dev at openjdk.java.net >>> >>> >>> >>> >>>> Thanks to your quick response. I will do it now but it require 1 - >>>> >> 2 >> >>>> days to >>>> reproduce the result. >>>> >>>> It seems that my case is very special. >>>> >>>> What the application is simply a stock quote client server and >>>> >> store daily >> >>>> stock quote and chart data in memory. The lived objects need around >>>> >> 80M >> >>>> memory at day open and 500M memory at day end. >>>> >>>> >>>> >>>> >>>> y.s.ramakrishna wrote: >>>> >>>> >>>>> Could you run with the additional option +PrintReferenceGC and see >>>>> >> if >> >>>>> it sheds additional light on the problem? (Please share the resulting >>>>> GC logs.) >>>>> >>>>> If at all possible, you might try rev'ing down to 6.0 and seeing >>>>> if the same behaviour reproduces or not? >>>>> >>>>> I understand that some or all of this may not be possible in a >>>>> production setting. >>>>> >>>>> -- ramki >>>>> >>>>> ----- Original Message ----- >>>>> From: "Ken-- at newsgroupstats.hk" >>>>> Date: Tuesday, October 7, 2008 10:17 pm >>>>> Subject: Re: CMS collection keep working during holiday >>>>> To: hotspot-gc-dev at openjdk.java.net >>>>> >>>>> >>>>> >>>>> >>>>>> Follow up to the jconsole above. This gif is captured today. You >>>>>> >>>>>> >>>>>> >>>> can >>>> >>>> >>>>>> see the >>>>>> first CMS after a FULL GC is working. The 2nd one is working too >>>>>> >>>>>> >>>>>> >>>> but the >>>> >>>> >>>>>> memory free from 2nd generation is much less than the first CMS. >>>>>> >> The >> >>>>>> memory >>>>>> free by 3rd CMS is further decreased. >>>>>> >>>>>> The 5th CMS cannot free enough memory to make occanpcy in old-gen >>>>>> >>>>>> >>>>>> >>>> to less >>>> >>>> >>>>>> than 70%. So, continue non-stopping CMS happen again until a Full >>>>>> >> GC >> >>>>>> (triggered by Concurrent Mode Failure). >>>>>> >>>>>> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872463.html >>>>>> Sent from the OpenJDK Hotspot Garbage Collection mailing list >>>>>> >>>>>> >>>> archive >>>> >>>> >>>>>> at Nabble.com. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> -- >>>> View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872900.html >>>> Sent from the OpenJDK Hotspot Garbage Collection mailing list >>>> >> archive >> >>>> at Nabble.com. >>>> >>>> >>>> >>> >>> > > From Antonios.Printezis at sun.com Wed Oct 8 14:24:10 2008 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Wed, 08 Oct 2008 10:24:10 -0400 Subject: CMS collection keep working during holiday In-Reply-To: <48EC5C5A.4030401@javaperformancetuning.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> Message-ID: <48ECC28A.8030004@sun.com> jmap -histo too Tony kirk wrote: > Ken-- at newsgroupstats.hk wrote: >> Follow up to the jconsole above. This gif is captured today. You can >> see the >> first CMS after a FULL GC is working. The 2nd one is working too but the >> memory free from 2nd generation is much less than the first CMS. The >> memory >> free by 3rd CMS is further decreased. >> >> The 5th CMS cannot free enough memory to make occanpcy in old-gen to >> less >> than 70%. So, continue non-stopping CMS happen again until a Full GC >> (triggered by Concurrent Mode Failure). >> >> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg >> >> >> >> >> >> > If GC is failing to recover memory, you either have a memory leak or > long loitering objects. I'd suggest visualvm or netbeans memory > profiling using the generations option to find out what objects are > surviving > > Regards, > Kirk -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux) From dragonken at gmail.com Wed Oct 8 16:13:16 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Wed, 8 Oct 2008 09:13:16 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: <48ECC28A.8030004@sun.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> Message-ID: <19882121.post@talk.nabble.com> Attached. http://www.nabble.com/file/p19882121/histo.txt histo.txt antonios.printezis wrote: > > jmap -histo too > > Tony > > kirk wrote: >> Ken-- at newsgroupstats.hk wrote: >>> Follow up to the jconsole above. This gif is captured today. You can >>> see the >>> first CMS after a FULL GC is working. The 2nd one is working too but the >>> memory free from 2nd generation is much less than the first CMS. The >>> memory >>> free by 3rd CMS is further decreased. >>> >>> The 5th CMS cannot free enough memory to make occanpcy in old-gen to >>> less >>> than 70%. So, continue non-stopping CMS happen again until a Full GC >>> (triggered by Concurrent Mode Failure). >>> >>> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg >>> >>> >>> >>> >>> >>> >> If GC is failing to recover memory, you either have a memory leak or >> long loitering objects. I'd suggest visualvm or netbeans memory >> profiling using the generations option to find out what objects are >> surviving >> >> Regards, >> Kirk > > -- > --------------------------------------------------------------------- > | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | > | | MS UBUR02-311 | > | e-mail: tony.printezis at sun.com | 35 Network Drive | > | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | > --------------------------------------------------------------------- > e-mail client: Thunderbird (Linux) > > > > -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19882121.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From Antonios.Printezis at sun.com Wed Oct 8 19:18:33 2008 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Wed, 08 Oct 2008 15:18:33 -0400 Subject: CMS collection keep working during holiday In-Reply-To: <19882121.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> Message-ID: <48ED0789.50106@sun.com> Hi, A single snapshot doesn't really tell us anything . You have to take two or three, as CMS cycles happen and are not clearing as much memory as you think should be cleared, to see which classes are growing in the heap. BTW, this is the first time I see a histogram with more hash map, than hash map entries! :-) Tony Ken-- at newsgroupstats.hk wrote: > Attached. > http://www.nabble.com/file/p19882121/histo.txt histo.txt > > > > > antonios.printezis wrote: > >> jmap -histo too >> >> Tony >> >> kirk wrote: >> >>> Ken-- at newsgroupstats.hk wrote: >>> >>>> Follow up to the jconsole above. This gif is captured today. You can >>>> see the >>>> first CMS after a FULL GC is working. The 2nd one is working too but the >>>> memory free from 2nd generation is much less than the first CMS. The >>>> memory >>>> free by 3rd CMS is further decreased. >>>> >>>> The 5th CMS cannot free enough memory to make occanpcy in old-gen to >>>> less >>>> than 70%. So, continue non-stopping CMS happen again until a Full GC >>>> (triggered by Concurrent Mode Failure). >>>> >>>> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> If GC is failing to recover memory, you either have a memory leak or >>> long loitering objects. I'd suggest visualvm or netbeans memory >>> profiling using the generations option to find out what objects are >>> surviving >>> >>> Regards, >>> Kirk >>> >> -- >> --------------------------------------------------------------------- >> | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | >> | | MS UBUR02-311 | >> | e-mail: tony.printezis at sun.com | 35 Network Drive | >> | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | >> --------------------------------------------------------------------- >> e-mail client: Thunderbird (Linux) >> >> >> >> >> > > -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux) From kirk.pepperdine at gmail.com Wed Oct 8 19:50:54 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Wed, 08 Oct 2008 21:50:54 +0200 Subject: CMS collection keep working during holiday In-Reply-To: <19882121.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> Message-ID: <48ED0F1E.2080107@javaperformancetuning.com> Ken-- at newsgroupstats.hk wrote: > Attached. > http://www.nabble.com/file/p19882121/histo.txt histo.txt > wierd, HashMap$Entry is the top item in the list.. 666 soft references and a bunch of weak references. The interesting one is com.mycompany.objs.ObjPriceLog. Have you sed'ed this file ;-)... Why is ObjPriceLog hanging about? Regards, Kirk > > > > antonios.printezis wrote: > >> jmap -histo too >> >> Tony >> >> kirk wrote: >> >>> Ken-- at newsgroupstats.hk wrote: >>> >>>> Follow up to the jconsole above. This gif is captured today. You can >>>> see the >>>> first CMS after a FULL GC is working. The 2nd one is working too but the >>>> memory free from 2nd generation is much less than the first CMS. The >>>> memory >>>> free by 3rd CMS is further decreased. >>>> >>>> The 5th CMS cannot free enough memory to make occanpcy in old-gen to >>>> less >>>> than 70%. So, continue non-stopping CMS happen again until a Full GC >>>> (triggered by Concurrent Mode Failure). >>>> >>>> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> If GC is failing to recover memory, you either have a memory leak or >>> long loitering objects. I'd suggest visualvm or netbeans memory >>> profiling using the generations option to find out what objects are >>> surviving >>> >>> Regards, >>> Kirk >>> >> -- >> --------------------------------------------------------------------- >> | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | >> | | MS UBUR02-311 | >> | e-mail: tony.printezis at sun.com | 35 Network Drive | >> | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | >> --------------------------------------------------------------------- >> e-mail client: Thunderbird (Linux) >> >> >> >> >> > > From Jon.Masamitsu at Sun.COM Wed Oct 8 22:09:18 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Wed, 08 Oct 2008 15:09:18 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <19882121.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> Message-ID: <48ED2F8E.3050703@Sun.COM> Ken, One of the differences between the CMS concurrent collection of the old gen and a full collection (concurrent mode fail) is the way SoftReferences are processed when the heap is full of live data. A full collection will clear all SoftReferences before it throws an out-of-memory. If a full collection is done and the heap is still full of live data, a full collection will clear all SoftReferences. When CMS does a concurrent collection and the heap is still full, a concurrent mode failure occurs resulting in a full collection. And as with full collections, all the SoftReferences will be cleared if necessary. If you set -XX: SoftRefLRUPolicyMSPerMB=0 SoftReferences will be cleared promptly and should tell us if we're encountering this difference in the way SoftReferences are handled. Jon On 10/08/08 09:13, Ken-- at newsgroupstats.hk wrote: > Attached. > http://www.nabble.com/file/p19882121/histo.txt histo.txt > > > > > antonios.printezis wrote: >> jmap -histo too >> >> Tony >> >> kirk wrote: >>> Ken-- at newsgroupstats.hk wrote: >>>> Follow up to the jconsole above. This gif is captured today. You can >>>> see the >>>> first CMS after a FULL GC is working. The 2nd one is working too but the >>>> memory free from 2nd generation is much less than the first CMS. The >>>> memory >>>> free by 3rd CMS is further decreased. >>>> >>>> The 5th CMS cannot free enough memory to make occanpcy in old-gen to >>>> less >>>> than 70%. So, continue non-stopping CMS happen again until a Full GC >>>> (triggered by Concurrent Mode Failure). >>>> >>>> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg >>>> >>>> >>>> >>>> >>>> >>>> >>> If GC is failing to recover memory, you either have a memory leak or >>> long loitering objects. I'd suggest visualvm or netbeans memory >>> profiling using the generations option to find out what objects are >>> surviving >>> >>> Regards, >>> Kirk >> -- >> --------------------------------------------------------------------- >> | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | >> | | MS UBUR02-311 | >> | e-mail: tony.printezis at sun.com | 35 Network Drive | >> | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | >> --------------------------------------------------------------------- >> e-mail client: Thunderbird (Linux) >> >> >> >> > From dragonken at gmail.com Thu Oct 9 03:39:09 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Wed, 8 Oct 2008 20:39:09 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: <48ED0F1E.2080107@javaperformancetuning.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED0F1E.2080107@javaperformancetuning.com> Message-ID: <19891748.post@talk.nabble.com> Thanks to your quick response. There is around 13000 listed stocks in my local stock market and over 80% of them have transaction. There are 285 minutes in trading hours so number of instance of ObjPriceLog is around 3,000,000 which is expected. I have no idea why there are so many HashMap$Entry. I suspect that's come from com.sun.jmx.remote.util.OrderClassLoaders. Actually jmap -histo is my first step for trouble shooting at the very beginning. Why there are so many wierd instance is because I have this flag: -XX:+DisableExplicitGC With this flag turned on, all calls to System.gc() is ignored even you press the 'Perform-GC' button in Jconsole. Removing this flag will have a much clear histo. I will cap a histo (without this flag turned on) and post here tomorrow. I will try to use jhat to figure why there are so many soft reference (and firstly, I have to learn what soft reference is) and where is those HashMapEntrys come from. Thanks to all of you and your professional comment! Best Regards, Ken kirk-17 wrote: > > Ken-- at newsgroupstats.hk wrote: >> Attached. >> http://www.nabble.com/file/p19882121/histo.txt histo.txt >> > wierd, HashMap$Entry is the top item in the list.. 666 soft references > and a bunch of weak references. The interesting one is > com.mycompany.objs.ObjPriceLog. Have you sed'ed this file ;-)... Why is > ObjPriceLog hanging about? > > Regards, > Kirk >> >> >> >> antonios.printezis wrote: >> >>> jmap -histo too >>> >>> Tony >>> >>> kirk wrote: >>> >>>> Ken-- at newsgroupstats.hk wrote: >>>> >>>>> Follow up to the jconsole above. This gif is captured today. You can >>>>> see the >>>>> first CMS after a FULL GC is working. The 2nd one is working too but >>>>> the >>>>> memory free from 2nd generation is much less than the first CMS. The >>>>> memory >>>>> free by 3rd CMS is further decreased. >>>>> >>>>> The 5th CMS cannot free enough memory to make occanpcy in old-gen to >>>>> less >>>>> than 70%. So, continue non-stopping CMS happen again until a Full GC >>>>> (triggered by Concurrent Mode Failure). >>>>> >>>>> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> If GC is failing to recover memory, you either have a memory leak or >>>> long loitering objects. I'd suggest visualvm or netbeans memory >>>> profiling using the generations option to find out what objects are >>>> surviving >>>> >>>> Regards, >>>> Kirk >>>> >>> -- >>> --------------------------------------------------------------------- >>> | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | >>> | | MS UBUR02-311 | >>> | e-mail: tony.printezis at sun.com | 35 Network Drive | >>> | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | >>> --------------------------------------------------------------------- >>> e-mail client: Thunderbird (Linux) >>> >>> >>> >>> >>> >> >> > > > -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19891748.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From Y.S.Ramakrishna at Sun.COM Thu Oct 9 04:02:57 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Wed, 08 Oct 2008 21:02:57 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <19891748.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED0F1E.2080107@javaperformancetuning.com> <19891748.post@talk.nabble.com> Message-ID: Hi Ken -- > Actually jmap -histo is my first step for trouble shooting at the very > beginning. Why there are so many wierd instance is because I have this > flag: > > -XX:+DisableExplicitGC > > With this flag turned on, all calls to System.gc() is ignored even you > press > the 'Perform-GC' button in Jconsole. Removing this flag will have a much > clear histo. I will cap a histo (without this flag turned on) and post > here > tomorrow. If you use jmap -histo:live from the command-line you will get a full gc before the histogram is computed. This full gc will be done despite having +DisableExplicitGC. -- ramki From dragonken at gmail.com Thu Oct 9 04:49:56 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Wed, 8 Oct 2008 21:49:56 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED0F1E.2080107@javaperformancetuning.com> <19891748.post@talk.nabble.com> Message-ID: <19892359.post@talk.nabble.com> Thanks to your quick response. This command option is very useful. I was trying to find a way to manually trigger full gc with DisableExplicitGC turned on :> Attached the live histo. http://www.nabble.com/file/p19892359/histo3.txt histo3.txt Thanks and Best Regards, Ken Y Srinivas Ramakrishna wrote: > > > > Hi Ken -- > >> Actually jmap -histo is my first step for trouble shooting at the very >> beginning. Why there are so many wierd instance is because I have this >> flag: >> >> -XX:+DisableExplicitGC >> >> With this flag turned on, all calls to System.gc() is ignored even you >> press >> the 'Perform-GC' button in Jconsole. Removing this flag will have a much >> clear histo. I will cap a histo (without this flag turned on) and post >> here >> tomorrow. > > If you use jmap -histo:live from the command-line you will > get a full gc before the histogram is computed. This full gc will > be done despite having +DisableExplicitGC. > > -- ramki > > -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19892359.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From dragonken at gmail.com Thu Oct 9 06:24:10 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Wed, 8 Oct 2008 23:24:10 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: <48ED2F8E.3050703@Sun.COM> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED2F8E.3050703@Sun.COM> Message-ID: <19893088.post@talk.nabble.com> I have added XX: SoftRefLRUPolicyMSPerMB=0 and the result is the same. :-( VM optoins: -Djava.security.policy=.\java.policy -Xms1536M -Xmx1536M -XX:NewSize=256M -XX:+PrintGCDetails -XX:+PrintGCTaskTimeStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -XX:+PrintReferenceGC -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=4 -XX:CMSInitiatingOccupancyFraction=55 -XX:TargetSurvivorRatio=90 -XX:SoftRefLRUPolicyMSPerMB=0 -Dcom.sun.management.jmxremote.port=18002 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false I have adjusted the XX:CMSInitiatingOccupancyFraction to 55 this time. Please ignore the last full gc in the chart. The full gc is triggered by jmap -histo:live. http://www.nabble.com/file/p19893088/jconsole_20081009.jpg http://www.nabble.com/file/p19893088/gc.log gc.log Jon Masamitsu wrote: > > Ken, > > One of the differences between the CMS concurrent > collection of the old gen and a full collection > (concurrent mode fail) is the way SoftReferences > are processed when the heap is full of live data. > A full collection will clear all SoftReferences > before it throws an out-of-memory. If a full > collection is done and the heap is still full > of live data, a full collection will clear all > SoftReferences. When CMS does a concurrent > collection and the heap is still full, a > concurrent mode failure occurs resulting in > a full collection. And as with full collections, > all the SoftReferences will be cleared if > necessary. If you set -XX: SoftRefLRUPolicyMSPerMB=0 > SoftReferences will be cleared promptly and should > tell us if we're encountering this difference in > the way SoftReferences are handled. > > Jon > > -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19893088.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From dragonken at gmail.com Thu Oct 9 10:07:49 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Thu, 9 Oct 2008 03:07:49 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: <19893088.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED2F8E.3050703@Sun.COM> <19893088.post@talk.nabble.com> Message-ID: <19895899.post@talk.nabble.com> Hi, I have jhat the vm heap but I don't know how to trace the problem. I tried to click HashMap$Entry / HashMap and there is so many instances and halt my browser. I found many references to HashMap are com.sun.jmx.remote.util.OrderClassLoaders at 0x49448a18 (54 bytes) : field packages sun.rmi.server.LoaderHandler$Loader at 0x17be85d0 (75 bytes) : field packages java.security.BasicPermissionCollection at 0x40b740e8 (18 bytes) : field perms Up to now, I believe my application has no memory leaks as my application is running very well without CMS collector and DisableExplicitGC. But I need CMS and DisableExplicitGC in order to have short gc pause time. There must be somewhere fool the CMS collector. Any idea to shoot the problem? Is that my application problem or jvm itself? Thanks and Best Regards, Ken -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19895899.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From kirk.pepperdine at gmail.com Thu Oct 9 07:10:03 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Thu, 09 Oct 2008 09:10:03 +0200 Subject: CMS collection keep working during holiday In-Reply-To: <48ED0789.50106@sun.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED0789.50106@sun.com> Message-ID: <48EDAE4B.60904@javaperformancetuning.com> Tony Printezis wrote: > Hi, > > A single snapshot doesn't really tell us anything . You have to take > two or three, as CMS cycles happen and are not clearing as much memory > as you think should be cleared, to see which classes are growing in > the heap. > > BTW, this is the first time I see a histogram with more hash map, than > hash map entries! :-) +1 -- Kirk From Antonios.Printezis at sun.com Thu Oct 9 13:54:47 2008 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Thu, 09 Oct 2008 09:54:47 -0400 Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED0F1E.2080107@javaperformancetuning.com> <19891748.post@talk.nabble.com> Message-ID: <48EE0D27.5020208@sun.com> Y Srinivas Ramakrishna wrote: > If you use jmap -histo:live from the command-line you will > get a full gc before the histogram is computed. This full gc will > be done despite having +DisableExplicitGC. > In fact, given that we want to find out what's growing in the heap during the CMS cycles (which seems to be GCed during Full GCs), it's better to use jmap -histo (i.e., no :live) to avoid the Full GC. But I'm forgetting: which VM Ken using? IIRC only jmap in 6 has the :live / no :live functionality (before that, it always did a Full GC, which is not what you want some of the time). Tony -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux) From Y.S.Ramakrishna at Sun.COM Thu Oct 9 16:09:46 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Thu, 09 Oct 2008 09:09:46 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <48EE0D27.5020208@sun.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED0F1E.2080107@javaperformancetuning.com> <19891748.post@talk.nabble.com> <48EE0D27.5020208@sun.com> Message-ID: > Y Srinivas Ramakrishna wrote: > > If you use jmap -histo:live from the command-line you will > > get a full gc before the histogram is computed. This full gc will > > be done despite having +DisableExplicitGC. > > > In fact, given that we want to find out what's growing in the heap > during the CMS cycles (which seems to be GCed during Full GCs), it's > better to use jmap -histo (i.e., no :live) to avoid the Full GC. But > I'm Right, both would be useful. (My suggestion was merely in response to Ken's remark that he wanted the full gc which he was not getting from jconsole because of hist +DisableExplicitGC. Indeed, the first one that Ken posted (which might have been from a different VM and therefore not comparable apples-to-apples with this dump) was indeed without :live and did show the large number of hash tables / entries, as you pointed out, which this one, following a full gc, does not. And so the mystery deepens as to why CMS was apparently keeping these objects which mark-compact is apparently able to reclaim.) > forgetting: which VM Ken using? IIRC only jmap in 6 has the :live / no > > :live functionality (before that, it always did a Full GC, which is > not > what you want some of the time). To the parenthetic remark: AFAIR, the pre-6.0 jvm's just dumped, no full gc -- thus jmap -histo did not change across 6.0; 6.0 added the new :live feature; the latter feature could be simulated in pre-6.0 JVM's by means of +PrintClassHistogram+SIGQUIT(ctl-break). AFAICT, Ken is using 6u7 here. -- ramki > > Tony > > -- > --------------------------------------------------------------------- > | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | > | | MS UBUR02-311 | > | e-mail: tony.printezis at sun.com | 35 Network Drive | > | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | > --------------------------------------------------------------------- > e-mail client: Thunderbird (Linux) > > From Antonios.Printezis at sun.com Thu Oct 9 16:32:38 2008 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Thu, 09 Oct 2008 12:32:38 -0400 Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED0F1E.2080107@javaperformancetuning.com> <19891748.post@talk.nabble.com> <48EE0D27.5020208@sun.com> Message-ID: <48EE3226.8000105@sun.com> Y Srinivas Ramakrishna wrote: > To the parenthetic remark: AFAIR, the pre-6.0 jvm's just dumped, no full gc -- > thus jmap -histo did not change across 6.0; 6.0 added the new :live > feature; the latter feature could be simulated in pre-6.0 JVM's > by means of +PrintClassHistogram+SIGQUIT(ctl-break). AFAICT, Ken is using 6u7 > here. > Yep, I stand corrected. Pre-6 jmap didn't do a Full GC before the heap iteration... Tony -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux) From Y.S.Ramakrishna at Sun.COM Thu Oct 9 16:48:12 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Thu, 09 Oct 2008 09:48:12 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <19895899.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED2F8E.3050703@Sun.COM> <19893088.post@talk.nabble.com> <19895899.post@talk.nabble.com> Message-ID: The mention of class loaders below reminds me to remind you that CMS by default will not collect class objects. To force CMS to collect classes in the perm gen, you would want to -XX:+CMSClassUnloadingEnabled. Try to see if that made any difference to the apparent inability of CMS to collect those apparently otherwise unreachable objects. -- ramki ----- Original Message ----- From: "Ken-- at newsgroupstats.hk" Date: Thursday, October 9, 2008 3:10 am Subject: Re: CMS collection keep working during holiday To: hotspot-gc-dev at openjdk.java.net > Hi, > > I have jhat the vm heap but I don't know how to trace the problem. I tried > to click HashMap$Entry / HashMap and there is so many instances and > halt my > browser. I found many references to HashMap are > > com.sun.jmx.remote.util.OrderClassLoaders at 0x49448a18 (54 bytes) : field > packages > sun.rmi.server.LoaderHandler$Loader at 0x17be85d0 (75 bytes) : field packages > java.security.BasicPermissionCollection at 0x40b740e8 (18 bytes) : field > perms > > Up to now, I believe my application has no memory leaks as my > application is > running very well without CMS collector and DisableExplicitGC. But I need > CMS and DisableExplicitGC in order to have short gc pause time. > > There must be somewhere fool the CMS collector. Any idea to shoot the > problem? Is that my application problem or jvm itself? > > Thanks and Best Regards, > Ken > -- > View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19895899.html > Sent from the OpenJDK Hotspot Garbage Collection mailing list archive > at Nabble.com. > From Y.S.Ramakrishna at Sun.COM Thu Oct 9 17:16:06 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Thu, 09 Oct 2008 10:16:06 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <48EE3B3F.7050107@javaperformancetuning.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED2F8E.3050703@Sun.COM> <19893088.post@talk.nabble.com> <19895899.post@talk.nabble.com> <48EE3B3F.7050107@javaperformancetuning.com> Message-ID: Hi Kirk -- > of course... look at this > > VM optoins: -Djava.security.policy=.\java.policy -Xms1536M -Xmx1536M > -XX:NewSize=256M -XX:+PrintGCDetails -XX:+PrintGCTaskTimeStamps > -XX:+PrintHeapAtGC -Xloggc:gc.log -XX:+PrintReferenceGC > -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC > -XX:SurvivorRatio=4 -XX:CMSInitiatingOccupancyFraction=55 > -XX:TargetSurvivorRatio=90 -XX:SoftRefLRUPolicyMSPerMB=0 > -Dcom.sun.management.jmxremote.port=18002 > -Dcom.sun.management.jmxremote.authenticate=false > -Dcom.sun.management.jmxremote.ssl=false Thanks for confirming. > > Perm space is ignored! Does he need to add > -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled Right; however, as of 6.0, the second flag is not needed; just -XX:+CMSClassUnloadingEnabled should suffice. -- ramki > > Kirk > > > Y Srinivas Ramakrishna wrote: > > The mention of class loaders below reminds me to remind you that > > CMS by default will not collect class objects. To force CMS > > to collect classes in the perm gen, you would want to > > -XX:+CMSClassUnloadingEnabled. Try to see if that made any > > difference to the apparent inability of CMS to collect > > those apparently otherwise unreachable objects. > > > > -- ramki > > > > ----- Original Message ----- > > From: "Ken-- at newsgroupstats.hk" > > Date: Thursday, October 9, 2008 3:10 am > > Subject: Re: CMS collection keep working during holiday > > To: hotspot-gc-dev at openjdk.java.net > > > > > > > >> Hi, > >> > >> I have jhat the vm heap but I don't know how to trace the problem. > I tried > >> to click HashMap$Entry / HashMap and there is so many instances and > > >> halt my > >> browser. I found many references to HashMap are > >> > >> com.sun.jmx.remote.util.OrderClassLoaders at 0x49448a18 (54 bytes) : field > >> packages > >> sun.rmi.server.LoaderHandler$Loader at 0x17be85d0 (75 bytes) : field packages > >> java.security.BasicPermissionCollection at 0x40b740e8 (18 bytes) : > field > >> perms > >> > >> Up to now, I believe my application has no memory leaks as my > >> application is > >> running very well without CMS collector and DisableExplicitGC. But > I need > >> CMS and DisableExplicitGC in order to have short gc pause time. > >> > >> There must be somewhere fool the CMS collector. Any idea to shoot the > >> problem? Is that my application problem or jvm itself? > >> > >> Thanks and Best Regards, > >> Ken > >> -- > >> View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19895899.html > >> Sent from the OpenJDK Hotspot Garbage Collection mailing list > archive > >> at Nabble.com. > >> > >> > > > > > From Peter.Kessler at Sun.COM Thu Oct 9 17:18:29 2008 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Thu, 09 Oct 2008 10:18:29 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <48EE0D27.5020208@sun.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED0F1E.2080107@javaperformancetuning.com> <19891748.post@talk.nabble.com> <48EE0D27.5020208@sun.com> Message-ID: <48EE3CE5.1010907@Sun.COM> Would it be diagnostic to get a "jmap -histo" right after a CMS cycle completes (e.g., by watching the GC log), followed immediately by a "jmap -histo:live" to force a full compacting GC? Differencing those might tell you what CMS isn't seeing. There will be some "fuzz" in the result because the application continues running and allocating short-lived objects, e.g., during the concurrent mark and concurrent sweep, and which the full collection will collect, but maybe someone who knows the application could see past the differences in short-lived stuff. ... peter Tony Printezis wrote: > > Y Srinivas Ramakrishna wrote: >> If you use jmap -histo:live from the command-line you will >> get a full gc before the histogram is computed. This full gc will >> be done despite having +DisableExplicitGC. >> > In fact, given that we want to find out what's growing in the heap > during the CMS cycles (which seems to be GCed during Full GCs), it's > better to use jmap -histo (i.e., no :live) to avoid the Full GC. But I'm > forgetting: which VM Ken using? IIRC only jmap in 6 has the :live / no > :live functionality (before that, it always did a Full GC, which is not > what you want some of the time). > > Tony > From kirk.pepperdine at gmail.com Thu Oct 9 17:03:52 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Thu, 09 Oct 2008 19:03:52 +0200 Subject: CMS collection keep working during holiday In-Reply-To: <48EE0D27.5020208@sun.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED0F1E.2080107@javaperformancetuning.com> <19891748.post@talk.nabble.com> <48EE0D27.5020208@sun.com> Message-ID: <48EE3978.1030009@javaperformancetuning.com> Tony Printezis wrote: > > Y Srinivas Ramakrishna wrote: >> If you use jmap -histo:live from the command-line you will >> get a full gc before the histogram is computed. This full gc will >> be done despite having +DisableExplicitGC. >> > In fact, given that we want to find out what's growing in the heap > during the CMS cycles (which seems to be GCed during Full GCs), it's > better to use jmap -histo (i.e., no :live) to avoid the Full GC. But > I'm forgetting: which VM Ken using? IIRC only jmap in 6 has the :live > / no :live functionality (before that, it always did a Full GC, which > is not what you want some of the time). What I found interesting was the diff between the live and full histogram as it seems to be an indicator of churn. -- Kirk From kirk.pepperdine at gmail.com Thu Oct 9 17:11:27 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Thu, 09 Oct 2008 19:11:27 +0200 Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED2F8E.3050703@Sun.COM> <19893088.post@talk.nabble.com> <19895899.post@talk.nabble.com> Message-ID: <48EE3B3F.7050107@javaperformancetuning.com> of course... look at this VM optoins: -Djava.security.policy=.\java.policy -Xms1536M -Xmx1536M -XX:NewSize=256M -XX:+PrintGCDetails -XX:+PrintGCTaskTimeStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -XX:+PrintReferenceGC -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=4 -XX:CMSInitiatingOccupancyFraction=55 -XX:TargetSurvivorRatio=90 -XX:SoftRefLRUPolicyMSPerMB=0 -Dcom.sun.management.jmxremote.port=18002 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false Perm space is ignored! Does he need to add -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled Kirk Y Srinivas Ramakrishna wrote: > The mention of class loaders below reminds me to remind you that > CMS by default will not collect class objects. To force CMS > to collect classes in the perm gen, you would want to > -XX:+CMSClassUnloadingEnabled. Try to see if that made any > difference to the apparent inability of CMS to collect > those apparently otherwise unreachable objects. > > -- ramki > > ----- Original Message ----- > From: "Ken-- at newsgroupstats.hk" > Date: Thursday, October 9, 2008 3:10 am > Subject: Re: CMS collection keep working during holiday > To: hotspot-gc-dev at openjdk.java.net > > > >> Hi, >> >> I have jhat the vm heap but I don't know how to trace the problem. I tried >> to click HashMap$Entry / HashMap and there is so many instances and >> halt my >> browser. I found many references to HashMap are >> >> com.sun.jmx.remote.util.OrderClassLoaders at 0x49448a18 (54 bytes) : field >> packages >> sun.rmi.server.LoaderHandler$Loader at 0x17be85d0 (75 bytes) : field packages >> java.security.BasicPermissionCollection at 0x40b740e8 (18 bytes) : field >> perms >> >> Up to now, I believe my application has no memory leaks as my >> application is >> running very well without CMS collector and DisableExplicitGC. But I need >> CMS and DisableExplicitGC in order to have short gc pause time. >> >> There must be somewhere fool the CMS collector. Any idea to shoot the >> problem? Is that my application problem or jvm itself? >> >> Thanks and Best Regards, >> Ken >> -- >> View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19895899.html >> Sent from the OpenJDK Hotspot Garbage Collection mailing list archive >> at Nabble.com. >> >> > > From dragonken at gmail.com Fri Oct 10 05:58:55 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Thu, 9 Oct 2008 22:58:55 -0700 (PDT) Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED2F8E.3050703@Sun.COM> <19893088.post@talk.nabble.com> <19895899.post@talk.nabble.com> <48EE3B3F.7050107@javaperformancetuning.com> Message-ID: <19912471.post@talk.nabble.com> Thanks to all of you. It seems work after adding -XX:+CMSClassUnloadingEnabled as you suggested. So, why classloader create so many HashMap entries and Vector elements? It seems that only a few people have this problem. vm options: -server -showversion -Djava.security.policy=.\java.policy -Xms1536M -Xmx1536M -XX:NewSize=256M -XX:+PrintGCDetails -XX:+PrintGCTaskTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -Xloggc:gc.log -XX:+PrintReferenceGC -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=4 -XX:CMSInitiatingOccupancyFraction=55 -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:MaxTenuringThreshold=1 -XX:SoftRefLRUPolicyMSPerMB=0 -Dcom.sun.management.jmxremote.port=18002 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false gc log: http://www.nabble.com/file/p19912471/gc.log gc.log jconsole: http://www.nabble.com/file/p19912471/jconsole_20081010.jpg > Y Srinivas Ramakrishna wrote: > > The mention of class loaders below reminds me to remind you that > > CMS by default will not collect class objects. To force CMS > > to collect classes in the perm gen, you would want to > > -XX:+CMSClassUnloadingEnabled. Try to see if that made any > > difference to the apparent inability of CMS to collect > > those apparently otherwise unreachable objects. > > > > -- ramki > > > > ----- Original Message ----- > > From: "Ken-- at newsgroupstats.hk" > > Date: Thursday, October 9, 2008 3:10 am > > Subject: Re: CMS collection keep working during holiday > > To: hotspot-gc-dev at openjdk.java.net > > > > -- View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19912471.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From Y.S.Ramakrishna at Sun.COM Fri Oct 10 18:35:57 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Fri, 10 Oct 2008 11:35:57 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <19912471.post@talk.nabble.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED2F8E.3050703@Sun.COM> <19893088.post@talk.nabble.com> <19895899.post@talk.nabble.com> <48EE3B3F.7050107@javaperformancetuning.com> <19912471.post@talk.nabble.com> Message-ID: Hi Ken -- Good to know that your main problem was solved. > Thanks to all of you. It seems work after adding > -XX:+CMSClassUnloadingEnabled as you suggested. > > So, why classloader create so many HashMap entries and Vector > elements? It > seems that only a few people have this problem. I suspect that if you used jconsole to track the #classes loaded, it would likely show an unbounded upward trend (or at least an upward trend that would correlate with the slope of the lower envelope of the old generation occupancy). The vectors are class loaders that your application container(s) use to load classes. The problem with CMS's default of not concurrently collecting classes here is that the classes which live in the perm gen point to their class loaders which live in the regular heap (old gen, eventually). So the class loaders do not get collected either. Further, the uncollected classes may have heavy-weight static fields associated with them (data which again lives in the regular heap). Thus what might be a few small classes that we schlep around in our perm gen, might be holding onto a lot of garbage that collects in the old gen. That's what we saw in your application. It so happens that in some cases you can actually clearly see the deleterious effect of accumulating perm gen garbage on the performance of not only CMS (which, as in your case, had an artifically bloated footprint and was running useless cycles), but on scavenges -- the latter is two-fold: firstly the quasi-immortal (modulo mark-compact which reclaims them) class loaders and other class-cohorts act as barriers to coalition and tend to fragment the old gen, causing much pain to scavenges, which slow down over time; further, the dead classes in the perm gen act as "dead roots" that inflates the root-scanning time for scavenges and further slows down scavenges. In a recent exchange, i think on this list, we saw a nice expample of that. We can probably extract a time-series plot of the scavenge times from your logs to see if we see a similar trending which is often a signature of problems such as these. (Of course similar signatures would appear also with some memory leaks, as Tony and Kirk suspected earlier.) Now a word about the default setting of CMSClassUnloadingEnabled. This setting was selected a number of years ago when it was relatively uncommon to have applications running in containers. In such cases, one would expect a small upper bound on the number of classes an application would load and thus it did not hurt much to not unload unreachable classes, thus avoid the extra work that CMS would need to do especially during the stop-world remark pause. That default setting however appears to be the wrong setting for the way a large majority of the applications are run today inside containers which causes a proliferation of classes and loaders. We have had a bug [1] filed for flipping the switch for a while but have not bitten the bullet and either take the resulting hit on CMS remark times (or appropriately deal with it; [2] is only one of several possibilities here). I think we'll address [1] soon, so that most users (such as Ken would not have to worry about this setting. Instead, power users who know what they are doing andcan compute a sufficiently small and tight upper bound on the total number and size of classes (and cohorts) they load during the life of their application would be required to throw off the switch explicitly. In my own recent (and admittedly somewhat biased) experience, the fraction of applications for which a non-trivial upper bound exists has been shrinking over time as more and more applications deploy on Java EE / application servers / containers. Comments, votes, plebiscite? -- ramki [1] 6329603 CMS: +CMSClassUnloadingEnabled and +CMSPermGenSweepingEnabled by default [2] 6543076 CMS: Adaptive collection of perm gen > > vm options: > > -server -showversion -Djava.security.policy=.\java.policy -Xms1536M > -Xmx1536M -XX:NewSize=256M -XX:+PrintGCDetails -XX:+PrintGCTaskTimeStamps > -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -Xloggc:gc.log > -XX:+PrintReferenceGC -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC -XX:SurvivorRatio=4 -XX:CMSInitiatingOccupancyFraction=55 > -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled > -XX:MaxTenuringThreshold=1 -XX:SoftRefLRUPolicyMSPerMB=0 > -Dcom.sun.management.jmxremote.port=18002 > -Dcom.sun.management.jmxremote.authenticate=false > -Dcom.sun.management.jmxremote.ssl=false > > > gc log: > http://www.nabble.com/file/p19912471/gc.log gc.log > > jconsole: > http://www.nabble.com/file/p19912471/jconsole_20081010.jpg > > > > > > Y Srinivas Ramakrishna wrote: > > > The mention of class loaders below reminds me to remind you that > > > CMS by default will not collect class objects. To force CMS > > > to collect classes in the perm gen, you would want to > > > -XX:+CMSClassUnloadingEnabled. Try to see if that made any > > > difference to the apparent inability of CMS to collect > > > those apparently otherwise unreachable objects. > > > > > > -- ramki > > > > > > ----- Original Message ----- > > > From: "Ken-- at newsgroupstats.hk" > > > Date: Thursday, October 9, 2008 3:10 am > > > Subject: Re: CMS collection keep working during holiday > > > To: hotspot-gc-dev at openjdk.java.net > > > > > > > > -- > View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19912471.html > Sent from the OpenJDK Hotspot Garbage Collection mailing list archive > at Nabble.com. > From Y.S.Ramakrishna at Sun.COM Fri Oct 10 19:07:33 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Fri, 10 Oct 2008 12:07:33 -0700 Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED2F8E.3050703@Sun.COM> <19893088.post@talk.nabble.com> <19895899.post@talk.nabble.com> <48EE3B3F.7050107@javaperformancetuning.com> <19912471.post@talk.nabble.com> Message-ID: As the old saying goes, a picture (attached, courtesy of gchisto) is worth a thousand words (well, actually only about 190 words below, but still). See how the scavenge times become so much better following the full gc's? (For some reason gchisto and our log fixer are unable to fix up and recognise the most dramatic one far to the right at timestamp 504379.249. > It so happens that in some cases you can actually clearly see the > deleterious effect of accumulating perm gen garbage on the performance > of not only CMS (which, as in your case, had an artifically bloated > footprint and was running useless cycles), but on scavenges -- > the latter is two-fold: firstly the quasi-immortal (modulo > mark-compact which reclaims them) class loaders and other class-cohorts > act as barriers to coalition and tend to fragment the old gen, causing > much pain to scavenges, which slow down over time; further, > the dead classes in the perm gen act as "dead roots" that inflates > the root-scanning time for scavenges and further slows down scavenges. > In a recent exchange, i think on this list, we saw a nice expample > of that. We can probably extract a time-series plot of the scavenge > times from your logs to see if we see a similar trending which > is often a signature of problems such as these. (Of course similar > signatures would appear also with some memory leaks, as Tony and Kirk > suspected earlier.) -- ramki -------------- next part -------------- A non-text attachment was scrubbed... Name: timeseries_gc.png Type: image/png Size: 27329 bytes Desc: not available URL: From john.coomes at sun.com Sat Oct 11 03:25:24 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 11 Oct 2008 03:25:24 +0000 Subject: hg: jdk7/hotspot-gc: 2 new changesets Message-ID: <20081011032524.41646D006@hg.openjdk.java.net> Changeset: 744554f5a329 Author: xdono Date: 2008-10-02 19:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/744554f5a329 6754988: Update copyright year Summary: Update for files that have been modified starting July 2008 Reviewed-by: ohair, tbell ! make/jprt.gmk Changeset: cc47a76899ed Author: xdono Date: 2008-10-09 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/cc47a76899ed Added tag jdk7-b37 for changeset 744554f5a329 ! .hgtags From john.coomes at sun.com Sat Oct 11 03:26:39 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 11 Oct 2008 03:26:39 +0000 Subject: hg: jdk7/hotspot-gc/corba: 2 new changesets Message-ID: <20081011032641.5BAE5D00B@hg.openjdk.java.net> Changeset: 59d5848bdede Author: xdono Date: 2008-10-02 19:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/59d5848bdede 6754988: Update copyright year Summary: Update for files that have been modified starting July 2008 Reviewed-by: ohair, tbell ! make/com/sun/corba/minclude/com_sun_corba_se_impl_dynamicany.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_encoding.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_ior.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_protocol.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_legacy_interceptor.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_monitoring.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_presentation_rmi.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_transport.jmk ! make/com/sun/corba/minclude/org_omg_CosNaming.jmk ! make/com/sun/corba/minclude/org_omg_DynamicAny.jmk ! make/com/sun/corba/minclude/org_omg_PortableInterceptor.jmk ! make/com/sun/corba/se/sources/Makefile ! make/javax/xa/Makefile ! make/org/omg/CORBA/Makefile Changeset: e1db87477f0c Author: xdono Date: 2008-10-09 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/e1db87477f0c Added tag jdk7-b37 for changeset 59d5848bdede ! .hgtags From john.coomes at sun.com Sat Oct 11 03:29:16 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 11 Oct 2008 03:29:16 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b37 for changeset af49591bc486 Message-ID: <20081011032918.DFDFCD011@hg.openjdk.java.net> Changeset: e9f750f0a3a0 Author: xdono Date: 2008-10-09 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/e9f750f0a3a0 Added tag jdk7-b37 for changeset af49591bc486 ! .hgtags From john.coomes at sun.com Sat Oct 11 03:30:35 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 11 Oct 2008 03:30:35 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b37 for changeset a2a6f9edf761 Message-ID: <20081011033038.13659D016@hg.openjdk.java.net> Changeset: 9ce439969184 Author: xdono Date: 2008-10-09 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/9ce439969184 Added tag jdk7-b37 for changeset a2a6f9edf761 ! .hgtags From john.coomes at sun.com Sat Oct 11 03:32:36 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 11 Oct 2008 03:32:36 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 29 new changesets Message-ID: <20081011033833.EC6DBD01D@hg.openjdk.java.net> Changeset: 094873a59791 Author: sjiang Date: 2008-09-09 14:17 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/094873a59791 6736611: [Evt Srv] EventSubscriber.unsubscribe removes other listeners Reviewed-by: emcmanus ! src/share/classes/javax/management/event/EventSubscriber.java + test/javax/management/eventService/SubUnsubTest.java Changeset: 1643868af837 Author: emcmanus Date: 2008-09-09 14:57 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1643868af837 6746196: Some JMX classes do not compile with Eclipse compiler Reviewed-by: dfuchs Contributed-by: roman.kennke at aicas.com ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java Changeset: 5778303e2e14 Author: dfuchs Date: 2008-09-09 17:01 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/5778303e2e14 6745832: jmx namespaces: Some refactoring/commenting would improve code readability. Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/interceptor/DispatchInterceptor.java ! src/share/classes/com/sun/jmx/interceptor/DomainDispatchInterceptor.java ! src/share/classes/com/sun/jmx/interceptor/NamespaceDispatchInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/Util.java ! src/share/classes/com/sun/jmx/namespace/DomainInterceptor.java ! src/share/classes/com/sun/jmx/namespace/HandlerInterceptor.java ! src/share/classes/com/sun/jmx/namespace/JMXNamespaceUtils.java ! src/share/classes/com/sun/jmx/namespace/NamespaceInterceptor.java ! src/share/classes/com/sun/jmx/namespace/RoutingConnectionProxy.java ! src/share/classes/com/sun/jmx/namespace/RoutingMBeanServerConnection.java ! src/share/classes/com/sun/jmx/namespace/RoutingProxy.java ! src/share/classes/com/sun/jmx/namespace/RoutingServerProxy.java ! src/share/classes/javax/management/namespace/JMXDomain.java ! src/share/classes/javax/management/namespace/JMXNamespace.java ! src/share/classes/javax/management/namespace/JMXNamespaces.java ! src/share/classes/javax/management/namespace/JMXRemoteNamespace.java ! src/share/classes/javax/management/namespace/MBeanServerConnectionWrapper.java ! test/javax/management/namespace/Wombat.java Changeset: 84417fdd8358 Author: martin Date: 2008-09-09 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/84417fdd8358 6728229: (str) StringBuilder.append(CharSequence) does not throw IndexOutOfBoundsException Summary: Major spec rework Reviewed-by: alanb ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java Changeset: 12f5110538d3 Author: martin Date: 2008-09-09 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/12f5110538d3 6733145: (bf) CharBuffer.subSequence can be updated to take advantage of covariant returns Summary: Change return type to CharBuffer Reviewed-by: alanb ! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java ! src/share/classes/java/nio/Direct-X-Buffer.java ! src/share/classes/java/nio/Heap-X-Buffer.java ! src/share/classes/java/nio/StringCharBuffer.java ! src/share/classes/java/nio/X-Buffer.java Changeset: 2b44dd8ed72d Author: emcmanus Date: 2008-09-10 13:36 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2b44dd8ed72d 6734813: Provide a way to construct an ObjectName without checked exceptions 6746649: ObjectName constructors and methods declare unchecked exceptions in throws clauses Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/Repository.java ! src/share/classes/com/sun/jmx/mbeanserver/Util.java ! src/share/classes/com/sun/jmx/namespace/DomainInterceptor.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/javax/management/MBeanServerDelegate.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/QueryNotificationFilter.java ! src/share/classes/javax/management/event/EventClientDelegateMBean.java ! src/share/classes/javax/management/namespace/MBeanServerSupport.java ! src/share/classes/sun/management/Util.java + test/javax/management/ObjectName/ValueOfTest.java Changeset: b35ccd203a7e Author: emcmanus Date: 2008-09-10 14:56 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b35ccd203a7e 6746759: Fix for 6734813 introduced build break Reviewed-by: dfuchs ! src/share/classes/sun/management/ClassLoadingImpl.java ! src/share/classes/sun/management/CompilationImpl.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/HotspotInternal.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MemoryImpl.java ! src/share/classes/sun/management/OperatingSystemImpl.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/ThreadImpl.java Changeset: 3e7b9a0f3a6f Author: dfuchs Date: 2008-09-10 16:27 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3e7b9a0f3a6f 6746754: jmx namespace: test for leading separator missing 6669137: RFE: InstanceNotFoundException should have a constructor that takes an ObjectName 6746796: jmx namespaces: Several tests are missing an @bug or @run keyword Summary: Note on 6669137: first implementation of 6669137 was actually pushed with 5072476 - here we only have a small update and a test case. Also re-fixes 6737133: Compilation failure of test/javax/management/eventService/LeaseManagerDeadlockTest.java which had failed. Reviewed-by: emcmanus, yjoan ! src/share/classes/com/sun/jmx/namespace/RoutingProxy.java ! src/share/classes/javax/management/InstanceNotFoundException.java + test/javax/management/MBeanServer/InstanceNotFoundExceptionTest.java ! test/javax/management/MBeanServerFactory/NamedMBeanServerTest.java ! test/javax/management/eventService/LeaseManagerDeadlockTest.java ! test/javax/management/namespace/DomainCreationTest.java ! test/javax/management/namespace/EventWithNamespaceControlTest.java ! test/javax/management/namespace/EventWithNamespaceTest.java ! test/javax/management/namespace/ExportNamespaceTest.java ! test/javax/management/namespace/JMXDomainTest.java ! test/javax/management/namespace/JMXNamespaceSecurityTest.java ! test/javax/management/namespace/JMXNamespaceTest.java ! test/javax/management/namespace/JMXNamespaceViewTest.java ! test/javax/management/namespace/JMXNamespacesTest.java ! test/javax/management/namespace/JMXRemoteNamespaceTest.java ! test/javax/management/namespace/LazyDomainTest.java + test/javax/management/namespace/LeadingSeparatorsTest.java ! test/javax/management/namespace/NamespaceCreationTest.java ! test/javax/management/namespace/NamespaceNotificationsTest.java ! test/javax/management/namespace/NullObjectNameTest.java ! test/javax/management/namespace/QueryNamesTest.java ! test/javax/management/namespace/RemoveNotificationListenerTest.java ! test/javax/management/namespace/RoutingServerProxyTest.java ! test/javax/management/namespace/SerialParamProcessorTest.java ! test/javax/management/namespace/SourceNamespaceTest.java ! test/javax/management/namespace/VirtualMBeanNotifTest.java ! test/javax/management/namespace/VirtualMBeanTest.java ! test/javax/management/namespace/VirtualNamespaceQueryTest.java ! test/javax/management/namespace/VirtualPropsTest.java Changeset: bee470ba5b24 Author: bristor Date: 2008-09-11 14:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/bee470ba5b24 6440786: Cannot create a ZIP file containing zero entries Summary: Allow reading and writing of ZIP files with zero entries. Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/native/java/util/zip/zip_util.c + test/java/util/zip/TestEmptyZip.java Changeset: ebc38225b4a9 Author: emcmanus Date: 2008-09-12 15:17 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ebc38225b4a9 6747411: EventClient causes thread leaks Summary: Reworked thread management in EventClient and related classes. Reviewed-by: sjiang, dfuchs ! src/share/classes/com/sun/jmx/event/LeaseManager.java ! src/share/classes/com/sun/jmx/event/RepeatedSingletonJob.java ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java ! src/share/classes/javax/management/event/EventClient.java ! src/share/classes/javax/management/event/FetchingEventRelay.java ! src/share/classes/javax/management/event/RMIPushEventForwarder.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java + test/javax/management/eventService/EventClientThreadTest.java ! test/javax/management/eventService/SharingThreadTest.java Changeset: 6a49dd6635ba Author: dfuchs Date: 2008-09-12 17:58 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6a49dd6635ba 6747899: jmx namespaces: hooks for permission checks should be defined in HandlerInterceptor Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/namespace/HandlerInterceptor.java ! src/share/classes/com/sun/jmx/namespace/RoutingMBeanServerConnection.java Changeset: 09a7e38337e9 Author: dfuchs Date: 2008-09-12 19:06 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/09a7e38337e9 6747983: jmx namespace: unspecified self-link detection logic Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/namespace/NamespaceInterceptor.java ! src/share/classes/javax/management/namespace/JMXRemoteNamespace.java ! test/javax/management/namespace/JMXNamespaceTest.java Changeset: def697d44797 Author: tbell Date: 2008-09-12 23:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/def697d44797 Merge Changeset: 044bfa235270 Author: dfuchs Date: 2008-09-17 13:40 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/044bfa235270 6748745: JConsole: plotters don't resize well when the window is resized Summary: part of the fix was contributed by jfdenise Reviewed-by: jfdenise ! src/share/classes/sun/tools/jconsole/Plotter.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java ! src/share/classes/sun/tools/jconsole/inspector/XPlotter.java ! src/share/classes/sun/tools/jconsole/inspector/XPlottingViewer.java Changeset: eb342082e2b6 Author: jccollet Date: 2008-09-04 15:26 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/eb342082e2b6 6692802: HttpCookie needs to support HttpOnly attribute Summary: Added HttpOnly tag support to HttpCookie class. Reviewed-by: chegar, michaelm ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java Changeset: d276b0716d13 Author: wetmore Date: 2008-09-05 00:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d276b0716d13 Merge Changeset: bcb61dfc8514 Author: weijun Date: 2008-09-08 14:17 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/bcb61dfc8514 6740833: krb5.conf does not accept kdc=hostname (no spaces around =) Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Config.java Changeset: b0378bb50d83 Author: michaelm Date: 2008-09-11 17:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b0378bb50d83 6744329: Exception in light weight http server code Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ChunkedOutputStream.java + test/com/sun/net/httpserver/bugs/B6744329.java Changeset: 80fe10573687 Author: mullan Date: 2008-09-11 14:05 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/80fe10573687 6465942: Add problem identification facility to the CertPathValidator framework Summary: Add support to the java.security.cert APIs for determining the reason that a certification path is invalid. Reviewed-by: vinnie ! src/share/classes/java/security/cert/CertPathValidatorException.java + src/share/classes/java/security/cert/PKIXReason.java ! src/share/classes/sun/security/provider/certpath/BasicChecker.java ! src/share/classes/sun/security/provider/certpath/ConstraintsChecker.java ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/KeyChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/PKIXMasterCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/PolicyChecker.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java ! test/java/security/cert/CertPathValidator/nameConstraintsRFC822/ValidateCertPath.java + test/java/security/cert/CertPathValidatorException/ReasonTest.java + test/java/security/cert/CertPathValidatorException/Serial.java + test/java/security/cert/CertPathValidatorException/cert_file + test/java/security/cert/CertPathValidatorException/jdk6.serial ! test/java/security/cert/PolicyNode/GetPolicyQualifiers.java Changeset: 482a1857b598 Author: mullan Date: 2008-09-11 18:13 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/482a1857b598 Merge Changeset: 80fd09f239f4 Author: wetmore Date: 2008-09-15 00:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/80fd09f239f4 Merge Changeset: 0100b3e66894 Author: wetmore Date: 2008-09-16 00:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0100b3e66894 Merge Changeset: e81a1ebde376 Author: wetmore Date: 2008-09-18 00:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e81a1ebde376 Merge Changeset: a1ab54c36c8a Author: sjiang Date: 2008-09-22 15:43 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a1ab54c36c8a 6697180: JMX query results in java.io.IOException: Illegal state - also a deadlock can also be seen Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java + test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java Changeset: 4a62773bf60e Author: jjh Date: 2008-09-22 19:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4a62773bf60e 6263966: TEST: com/sun/jdi/ClassesByName2Test.java has a race Summary: Have the debuggee stop at a bkpt instead of running to completion. Reviewed-by: tbell ! test/com/sun/jdi/ClassesByName2Test.java Changeset: b54ba7058851 Author: tbell Date: 2008-09-22 22:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b54ba7058851 Merge Changeset: ed8f850f9f94 Author: tbell Date: 2008-09-26 15:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ed8f850f9f94 Merge Changeset: 14f50aee4989 Author: xdono Date: 2008-10-02 19:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/14f50aee4989 6754988: Update copyright year Summary: Update for files that have been modified starting July 2008 Reviewed-by: ohair, tbell ! make/com/sun/inputmethods/indicim/Makefile ! make/com/sun/inputmethods/thaiim/Makefile ! make/com/sun/java/pack/Makefile ! make/com/sun/security/auth/module/Makefile ! make/common/BuildToolJar.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/internal/ImportComponents.gmk ! make/common/shared/Defs-java.gmk ! make/common/shared/Defs-windows.gmk ! make/java/fdlibm/Makefile ! make/java/hpi/windows/Makefile ! make/java/java/FILES_java.gmk ! make/java/java_crw_demo/Makefile ! make/java/java_hprof_demo/Makefile ! make/java/management/Makefile ! make/java/net/Makefile ! make/java/net/mapfile-vers ! make/java/nio/FILES_java.gmk ! make/java/nio/genCoder.sh ! make/java/npt/Makefile ! make/java/zip/Makefile ! make/javax/swing/beaninfo/SwingBeans.gmk ! make/jpda/back/Makefile ! make/jpda/transport/shmem/Makefile ! make/jpda/transport/socket/Makefile ! make/jprt.properties ! make/mksample/nio/Makefile ! make/mksample/nio/multicast/Makefile ! make/netbeans/jconsole/build.properties ! make/netbeans/jconsole/build.xml ! make/sun/cmm/kcms/Makefile ! make/sun/font/t2k/Makefile ! make/sun/image/generic/Makefile ! make/sun/image/vis/Makefile ! make/sun/jconsole/Makefile ! make/sun/jdbc/Makefile ! make/sun/jpeg/Makefile ! make/sun/net/spi/nameservice/dns/Makefile ! make/sun/text/Makefile ! src/share/back/ThreadReferenceImpl.c ! src/share/back/eventFilter.c ! src/share/back/transport.c ! src/share/classes/com/sun/jmx/defaults/JmxProperties.java ! src/share/classes/com/sun/jmx/event/DaemonThreadFactory.java ! src/share/classes/com/sun/jmx/event/EventBuffer.java ! src/share/classes/com/sun/jmx/event/EventClientFactory.java ! src/share/classes/com/sun/jmx/event/EventConnection.java ! src/share/classes/com/sun/jmx/event/EventParams.java ! src/share/classes/com/sun/jmx/event/LeaseManager.java ! src/share/classes/com/sun/jmx/event/LeaseRenewer.java ! src/share/classes/com/sun/jmx/event/ReceiverBuffer.java ! src/share/classes/com/sun/jmx/event/RepeatedSingletonJob.java ! src/share/classes/com/sun/jmx/mbeanserver/DynamicMBean2.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInjector.java ! src/share/classes/com/sun/jmx/mbeanserver/NotifySupport.java ! src/share/classes/com/sun/jmx/mbeanserver/PerThreadGroupPool.java ! src/share/classes/com/sun/jmx/mbeanserver/StandardMBeanIntrospector.java ! src/share/classes/com/sun/jmx/mbeanserver/SunJmxMBeanServer.java ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java ! src/share/classes/com/sun/jmx/remote/internal/ProxyInputStream.java ! src/share/classes/com/sun/jmx/remote/internal/ProxyRef.java ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/com/sun/jmx/remote/util/EventClientConnection.java ! src/share/classes/com/sun/jmx/snmp/tasks/ThreadService.java ! src/share/classes/com/sun/tools/jdi/MonitorInfoImpl.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/VMAction.java ! src/share/classes/com/sun/tools/jdi/VMState.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java ! src/share/classes/java/nio/Direct-X-Buffer.java ! src/share/classes/java/nio/Heap-X-Buffer.java ! src/share/classes/java/nio/X-Buffer.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/SelectionKey.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/channels/exceptions ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/channels/spi/AbstractSelector.java ! src/share/classes/java/nio/charset/Charset-X-Coder.java ! src/share/classes/java/nio/charset/CoderResult.java ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/Timer.java ! src/share/classes/javax/management/Description.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/management/DescriptorFields.java ! src/share/classes/javax/management/DescriptorKey.java ! src/share/classes/javax/management/DynamicWrapperMBean.java ! src/share/classes/javax/management/Impact.java ! src/share/classes/javax/management/InstanceNotFoundException.java ! src/share/classes/javax/management/MBean.java ! src/share/classes/javax/management/MBeanOperationInfo.java ! src/share/classes/javax/management/MBeanPermission.java ! src/share/classes/javax/management/MBeanRegistration.java ! src/share/classes/javax/management/MBeanServerConnection.java ! src/share/classes/javax/management/MBeanServerDelegate.java ! src/share/classes/javax/management/MBeanServerFactory.java ! src/share/classes/javax/management/MBeanServerNotification.java ! src/share/classes/javax/management/ManagedAttribute.java ! src/share/classes/javax/management/ManagedOperation.java ! src/share/classes/javax/management/NotificationBroadcasterSupport.java ! src/share/classes/javax/management/NotificationInfo.java ! src/share/classes/javax/management/NotificationInfos.java ! src/share/classes/javax/management/SendNotification.java ! src/share/classes/javax/management/StandardEmitterMBean.java ! src/share/classes/javax/management/event/EventClient.java ! src/share/classes/javax/management/event/EventClientDelegate.java ! src/share/classes/javax/management/event/EventClientDelegateMBean.java ! src/share/classes/javax/management/event/EventClientNotFoundException.java ! src/share/classes/javax/management/event/EventConsumer.java ! src/share/classes/javax/management/event/EventForwarder.java ! src/share/classes/javax/management/event/EventReceiver.java ! src/share/classes/javax/management/event/EventRelay.java ! src/share/classes/javax/management/event/FetchingEventForwarder.java ! src/share/classes/javax/management/event/FetchingEventRelay.java ! src/share/classes/javax/management/event/ListenerInfo.java ! src/share/classes/javax/management/event/NotificationManager.java ! src/share/classes/javax/management/event/RMIPushEventForwarder.java ! src/share/classes/javax/management/event/RMIPushEventRelay.java ! src/share/classes/javax/management/event/RMIPushServer.java ! src/share/classes/javax/management/openmbean/CompositeDataSupport.java ! src/share/classes/javax/management/openmbean/TabularDataSupport.java ! src/share/classes/javax/management/remote/JMXConnector.java ! src/share/classes/javax/management/remote/JMXConnectorServer.java ! src/share/classes/javax/management/remote/JMXConnectorServerMBean.java ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/share/classes/javax/net/ssl/SSLServerSocket.java ! src/share/classes/sun/font/NullFontScaler.java ! src/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java ! src/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/net/httpserver/ChunkedOutputStream.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/SelectorImpl.java ! src/share/classes/sun/nio/ch/SelectorProviderImpl.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/cs/standard-charsets ! src/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java ! src/share/classes/sun/text/resources/FormatData_sv.java ! src/share/classes/sun/tools/jconsole/Plotter.java ! src/share/classes/sun/tools/jmap/JMap.java ! src/share/demo/jvmti/hprof/hprof_io.c ! src/share/demo/jvmti/hprof/hprof_util.c ! src/share/native/java/net/net_util.h ! src/share/native/java/nio/Bits.c ! src/share/native/sun/nio/ch/genSocketOptionRegistry.c ! src/share/transport/shmem/shmemBack.c ! src/share/transport/shmem/shmemBase.c ! src/share/transport/socket/socketTransport.c ! src/share/transport/socket/sysSocket.h ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_Utils.h ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/SocketInputStream.c ! src/solaris/native/java/net/SocketOutputStream.c ! src/solaris/native/java/net/linux_close.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/nio/MappedByteBuffer.c ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c ! src/solaris/native/sun/nio/ch/FileKey.c ! src/solaris/native/sun/nio/ch/InheritedChannel.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c ! src/solaris/native/sun/nio/ch/SocketChannelImpl.c ! src/solaris/native/sun/nio/ch/nio_util.h ! src/solaris/transport/socket/socket_md.c ! src/windows/classes/sun/nio/ch/PipeImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/javavm/export/jvm_md.h ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.h ! src/windows/native/java/net/NetworkInterface_win9x.c ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/SocketOutputStream.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/net_util_md.h ! src/windows/native/sun/net/dns/ResolverConfigurationImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/ServerSocketChannelImpl.c ! src/windows/native/sun/nio/ch/SocketChannelImpl.c ! src/windows/native/sun/nio/ch/WindowsSelectorImpl.c ! src/windows/native/sun/windows/ComCtl32Util.cpp ! src/windows/native/sun/windows/ComCtl32Util.h ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/transport/socket/socket_md.c ! src/windows/transport/socket/socket_md.h ! test/com/sun/jdi/ClassesByName2Test.java ! test/com/sun/jdi/ConnectedVMs.java ! test/com/sun/jdi/MonitorFrameInfo.java ! test/com/sun/jdi/Solaris32AndSolaris64Test.sh ! test/com/sun/jdi/SourceNameFilterTest.java ! test/com/sun/jdi/VMConnection.java ! test/com/sun/net/httpserver/bugs/B6744329.java ! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java ! test/java/lang/management/ThreadMXBean/Locks.java ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/Inet6Address/serialize/Serialize.java ! test/java/nio/channels/FileChannel/ExpandingMap.java ! test/java/nio/channels/Selector/Wakeup.java ! test/javax/management/Introspector/AnnotatedMBeanTest.java ! test/javax/management/Introspector/AnnotatedNotificationInfoTest.java ! test/javax/management/Introspector/MBeanDescriptionTest.java ! test/javax/management/Introspector/ParameterNameTest.java ! test/javax/management/Introspector/ResourceInjectionTest.java ! test/javax/management/Introspector/annot/Name.java ! test/javax/management/MBeanInfo/NotificationInfoTest.java ! test/javax/management/MBeanServer/DynamicWrapperMBeanTest.java ! test/javax/management/MBeanServer/OldMBeanServerTest.java ! test/javax/management/MBeanServerFactory/NamedMBeanServerTest.java ! test/javax/management/ObjectName/ApplyWildcardTest.java ! test/javax/management/ObjectName/SerialCompatTest.java ! test/javax/management/eventService/AddRemoveListenerTest.java ! test/javax/management/eventService/CustomForwarderTest.java ! test/javax/management/eventService/EventManagerTest.java ! test/javax/management/eventService/FetchingTest.java ! test/javax/management/eventService/LeaseTest.java ! test/javax/management/eventService/ListenerTest.java ! test/javax/management/eventService/NotSerializableNotifTest.java ! test/javax/management/eventService/PublishTest.java ! test/javax/management/eventService/ReconnectableConnectorTest.java ! test/javax/management/eventService/SharingThreadTest.java ! test/javax/management/mxbean/ComparatorExceptionTest.java ! test/javax/management/mxbean/GenericArrayTypeTest.java ! test/javax/management/mxbean/LeakTest.java ! test/javax/management/mxbean/MBeanOperationInfoTest.java ! test/javax/management/mxbean/MXBeanTest.java ! test/javax/management/mxbean/SameObjectTwoNamesTest.java ! test/javax/management/mxbean/ThreadMXBeanTest.java ! test/javax/management/mxbean/TigerMXBean.java ! test/javax/management/remote/mandatory/connection/CloseServerTest.java ! test/javax/management/remote/mandatory/connection/DeadLockTest.java ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java ! test/javax/management/remote/mandatory/connection/RMIExitTest.java ! test/javax/management/remote/mandatory/connection/ReconnectTest.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/notif/AddRemoveTest.java ! test/javax/management/remote/mandatory/notif/DiffHBTest.java ! test/javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java ! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java ! test/javax/management/remote/mandatory/notif/NotifBufferSizePropertyNameTest.java ! test/javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java ! test/javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java ! test/javax/management/remote/mandatory/notif/NotificationBufferCreationTest.java ! test/javax/management/remote/mandatory/notif/NotificationBufferDeadlockTest.java ! test/javax/management/remote/mandatory/notif/NotificationEmissionTest.java ! test/javax/management/remote/mandatory/notif/RMINotifTest.java ! test/javax/management/remote/mandatory/notif/UnexpectedNotifTest.java ! test/javax/script/E4XErrorTest.java ! test/javax/script/JavaScriptScopeTest.java ! test/javax/script/NullUndefinedVarTest.java ! test/javax/script/PluggableContextTest.java ! test/javax/script/ProviderTest.java ! test/javax/script/RhinoExceptionTest.java ! test/javax/script/Test1.java ! test/javax/script/Test2.java ! test/javax/script/Test3.java ! test/javax/script/Test4.java ! test/javax/script/Test5.java ! test/javax/script/Test6.java ! test/javax/script/Test7.java ! test/javax/script/Test8.java ! test/javax/script/VersionTest.java ! test/sun/tools/jrunscript/common.sh ! test/sun/tools/jrunscript/jrunscript-DTest.sh ! test/sun/tools/jrunscript/jrunscript-argsTest.sh ! test/sun/tools/jrunscript/jrunscript-cpTest.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh Changeset: db2e128d9f68 Author: xdono Date: 2008-10-09 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/db2e128d9f68 Added tag jdk7-b37 for changeset 14f50aee4989 ! .hgtags From john.coomes at sun.com Sat Oct 11 03:44:53 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 11 Oct 2008 03:44:53 +0000 Subject: hg: jdk7/hotspot-gc/langtools: 9 new changesets Message-ID: <20081011034508.4BBAAD022@hg.openjdk.java.net> Changeset: 91eea580fbe9 Author: jjg Date: 2008-09-09 10:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/91eea580fbe9 6557752: Original type of an AST should be made available even if it is replaced with an ErrorType Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/javax/lang/model/type/ErrorType.java + test/tools/javac/api/6557752/T6557752.java Changeset: a92b756a888f Author: jjg Date: 2008-09-09 10:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/a92b756a888f 6724118: change JavaCompiler to not use Scanner directly 6736119: refactor Parser and Parser.Factory Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/EndPosParser.java + src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Parser.java + src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! test/tools/javac/6304921/TestLog.java Changeset: 7e2249b1c13d Author: tbell Date: 2008-09-12 23:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/7e2249b1c13d Merge Changeset: eff38cc97183 Author: jjg Date: 2008-09-16 18:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/eff38cc97183 6574134: Allow for alternative implementation of Name Table with garbage collection of name bytes Reviewed-by: darcy, mcimadamore ! src/share/classes/com/sun/tools/apt/mirror/AptEnv.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/util/ByteBuffer.java ! src/share/classes/com/sun/tools/javac/util/Convert.java ! src/share/classes/com/sun/tools/javac/util/Name.java + src/share/classes/com/sun/tools/javac/util/Names.java + src/share/classes/com/sun/tools/javac/util/SharedNameTable.java + src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! test/tools/javac/unit/util/convert/EnclosingCandidates.java Changeset: 8ec49685f4e8 Author: jjg Date: 2008-09-18 13:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/8ec49685f4e8 6728697: tools/javac/versionOpt.sh fails on OpenJDK builds Reviewed-by: darcy ! test/Makefile - test/bootclasspath-exclude.jtx + test/tools/javac/VersionOpt.java - test/tools/javac/versionOpt.sh Changeset: 829dea15ff99 Author: jjg Date: 2008-09-18 18:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/829dea15ff99 6744408: Extra ouput is appearing in stderr Reviewed-by: bpatel ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java Changeset: 2e3d9966e62b Author: tbell Date: 2008-09-26 15:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/2e3d9966e62b Merge Changeset: 24a47c3062fe Author: xdono Date: 2008-10-02 19:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/24a47c3062fe 6754988: Update copyright year Summary: Update for files that have been modified starting July 2008 Reviewed-by: ohair, tbell ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/apt/mirror/AptEnv.java ! src/share/classes/com/sun/tools/apt/util/Bark.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/javac/Server.java ! src/share/classes/com/sun/tools/javac/api/JavacScope.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/api/WrappingJavaFileManager.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/model/FilteredMemberList.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java ! src/share/classes/com/sun/tools/javac/parser/EndPosParser.java ! src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/Token.java ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/util/ByteBuffer.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/Convert.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java ! src/share/classes/com/sun/tools/javac/util/Name.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javac/util/SharedNameTable.java ! src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/javax/lang/model/type/ErrorType.java ! src/share/classes/javax/tools/StandardLocation.java ! test/tools/javac/5045412/Bar.java ! test/tools/javac/5045412/Foo.java ! test/tools/javac/6199662/Tree.java ! test/tools/javac/6627362/T6627362.java ! test/tools/javac/6627362/x/E.java ! test/tools/javac/6627362/x/Object.java ! test/tools/javac/api/6557752/T6557752.java ! test/tools/javac/foreach/T6500701.java ! test/tools/javac/synthesize/Boolean.java ! test/tools/javac/synthesize/Byte.java ! test/tools/javac/synthesize/Character.java ! test/tools/javac/synthesize/Cloneable.java ! test/tools/javac/synthesize/Integer.java ! test/tools/javac/synthesize/Long.java ! test/tools/javac/synthesize/Main.java ! test/tools/javac/synthesize/Number.java ! test/tools/javac/synthesize/Object.java ! test/tools/javac/synthesize/Serializable.java ! test/tools/javac/synthesize/Short.java ! test/tools/javac/synthesize/Test.java ! test/tools/javac/synthesize/Void.java ! test/tools/javac/unit/util/convert/EnclosingCandidates.java Changeset: 31f03e49d18d Author: xdono Date: 2008-10-09 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/31f03e49d18d Added tag jdk7-b37 for changeset 24a47c3062fe ! .hgtags From antonios.printezis at sun.com Sat Oct 11 06:49:06 2008 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Sat, 11 Oct 2008 06:49:06 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 11 new changesets Message-ID: <20081011064930.C564CD073@hg.openjdk.java.net> Changeset: e4355b352b7d Author: coleenp Date: 2008-09-26 13:33 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e4355b352b7d 6719149: Wrong "java/lang/String should not be loaded yet" assertion in fastdebug bits with UseStringCache Summary: Assertion is invalid because java.lang.String may be initialized just before this assertion. Reviewed-by: phh ! src/share/vm/runtime/thread.cpp Changeset: 99dd4bbd9eec Author: acorn Date: 2008-09-30 12:24 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/99dd4bbd9eec Merge ! src/share/vm/runtime/thread.cpp Changeset: b7483806cc49 Author: acorn Date: 2008-10-01 20:15 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b7483806cc49 Merge Changeset: 9646293b9637 Author: xdono Date: 2008-09-25 12:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9646293b9637 Added tag jdk7-b36 for changeset e91159f921a5 ! .hgtags Changeset: 0e31d37915ff Author: trims Date: 2008-10-01 16:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0e31d37915ff 6754998: Update Hotspot version for hs14 b06 Summary: Bump Hotspot build number to 06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: af90fe21c1e3 Author: trims Date: 2008-10-01 16:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/af90fe21c1e3 Merge Changeset: c005b6eac36e Author: dcubed Date: 2008-10-02 06:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c005b6eac36e Merge Changeset: f1ecf9191140 Author: trims Date: 2008-10-02 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f1ecf9191140 6755406: minor mistakes in copyright notices Summary: Mismatch in some header copyrights from standard templates Reviewed-by: jcoomes ! make/hotspot_distro ! test/compiler/6646019/Test.java ! test/compiler/6689060/Test.java ! test/compiler/6695810/Test.java Changeset: fad66fdcb7fc Author: xlu Date: 2008-10-06 11:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fad66fdcb7fc 6673124: Runtime.availableProcessors / os::active_processor_count wrong if unused processor sets exist Reviewed-by: acorn, dholmes ! src/os/solaris/vm/os_solaris.cpp Changeset: f008d3631bd1 Author: ksrini Date: 2008-10-08 08:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f008d3631bd1 6755845: JVM_FindClassFromBoot triggers assertions Summary: Fixes assertions caused by one jvm_entry calling another, solved by refactoring code and modified gamma test. Reviewed-by: dholmes, xlu ! src/os/linux/launcher/java.c ! src/os/linux/launcher/java.h ! src/os/linux/launcher/java_md.c ! src/os/solaris/launcher/java.c ! src/os/solaris/launcher/java.h ! src/os/solaris/launcher/java_md.c ! src/share/vm/prims/jvm.cpp Changeset: 05366dad12cf Author: tonyp Date: 2008-10-09 12:06 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/05366dad12cf Merge From rainer.jung at kippdata.de Sun Oct 12 11:44:30 2008 From: rainer.jung at kippdata.de (Rainer Jung) Date: Sun, 12 Oct 2008 13:44:30 +0200 Subject: gclog improvements Message-ID: <48F1E31E.5090707@kippdata.de> Hi, as we all know, GC logging is still vital for finding a good sizing and GC configuration. Unfortunately the gclog gets overwrittten each time the JVM starts due to the way the file gets opened. So in order to keep the files people need to add rotation commands to their start scripts. Often this doesn't happen and especially when emergency restarts where needed, the old gclog is gone. Any plans for changing this? Or maybe even adding log file rotation to the gclog? Furthermore: Until now there is no event based model of monitoring the GC and Memory data. All methods apart from logging are based on a pull model, that retrieves information in regular intervals. The most important information does not exist in regular intervals, but instead immediately after a GC. It would be nice to have some event based model (e.g. like in JVMTI), that allows to track the same data as the gc logging, without using the historically motivated gclog file format. Thanks for your helpful and transparent comments on the mailing lists. Regards, Rainer From rainer.jung at kippdata.de Sun Oct 12 10:58:42 2008 From: rainer.jung at kippdata.de (Rainer Jung) Date: Sun, 12 Oct 2008 12:58:42 +0200 Subject: More PrintGCApplicationStoppedTime messages in Java 6 In-Reply-To: <48EA23A0.4030600@sun.com> References: <48E8C118.9010302@kippdata.de> <48EA23A0.4030600@sun.com> Message-ID: <48F1D862.4030201@kippdata.de> Tony Printezis schrieb: > Rainer, > > Which version of 5 were you using? They could be biased locking > revocation safepoints. Try running with -XX:-UseBiasedLocking to see if > they occur. Biased locking is an important and effective optimization in > most cases and the extra safepoints that it causes are generally benign > and nothing to worry about. Great, that's it. When turning of, I don't get the additional stop times any more. I used Tomcat startup as a simple test case. I understand, that in general it's not a good idea to turn it off, just wanted to understand, where they come from. I used -XX:+TraceBiasedLocking with 1.6.0_07 to further look at those stopp events: Count Message type 54 Aligned thread 0xHEX to 0xHEX 265 Total time for which application threads were stopped: NUM seconds 265 Application time: NUM seconds 252 Revoking bias with potentially per-thread safepoint: 70 Revoking bias by walking my own stack: 1 Revoking bias with global safepoint: 323 Revoking bias of object ... 243 Revoked bias of currently-unlocked object 59 Revoked bias of currently-locked object 21 Revoked bias of object biased toward dead thread 4 * Beginning bulk revocation (kind == rebias) ... 3 * Beginning bulk revocation (kind == revoke) ... 7 * Ending bulk revocation 2 (Skipping revocation of object of type ... because it's no longer biased) 2 * Disabling biased locking for type ... 4 Rebiased object toward thread 0xHEX Of the 265 stop messages, 6 were triggered by Minor GC, the rest belongs to BiasedLocking (all very short). Thanks for the explanation! Regards, Rainer > Tony > > Rainer Jung wrote: >> Hi, >> >> the number of messages >> >> Total time for which application threads were stopped: X.Y seconds >> >> produced by PrintGCApplicationStoppedTime increased a lot between Java 5 >> and 6. All of the additional messages refer to extremely short pause >> times, and none of the prints anything when adding PrintHeadAtGC, so it >> looks like they are not directly related to actually running a GC task. >> >> Can someone give an indication, what other typical reasons for those >> pauses exist? I tried to track it back from vm/runtime/vmThread.cpp, but >> wasn't really successful. >> >> Regards, >> >> Rainer _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Antonios.Printezis at sun.com Mon Oct 13 14:29:23 2008 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Mon, 13 Oct 2008 10:29:23 -0400 Subject: gclog improvements In-Reply-To: <48F1E31E.5090707@kippdata.de> References: <48F1E31E.5090707@kippdata.de> Message-ID: <48F35B43.3030401@sun.com> Rainer, Hi. See inline. Rainer Jung wrote: > Hi, > > as we all know, GC logging is still vital for finding a good sizing and > GC configuration. > > Unfortunately the gclog gets overwrittten each time the JVM starts due > to the way the file gets opened. So in order to keep the files people > need to add rotation commands to their start scripts. Often this doesn't > happen and especially when emergency restarts where needed, the old > gclog is gone. > > Any plans for changing this? Or maybe even adding log file rotation to > the gclog? > We don't have any immediate plans for doing this. Regarding the log file getting overwritten, typically customers launch the JVM from a script and it's easy to create a unique GC log file name from a script (append the start time, pid, or something like that). So, that's an easy issue to solve... > Furthermore: Until now there is no event based model of monitoring the > GC and Memory data. All methods apart from logging are based on a pull > model, that retrieves information in regular intervals. The most > important information does not exist in regular intervals, but instead > immediately after a GC. It would be nice to have some event based model > (e.g. like in JVMTI), that allows to track the same data as the gc > logging, without using the historically motivated gclog file format. > There's a trade-off. I don't like the pull method myself, given that it can skip events, give you inconsistent information, etc. But, to get consistent information you generally have to do a STW pause, and this is too much of an overhead for an application in production. This is why a lot of the monitoring has been implemented asynchronously. Tony > Thanks for your helpful and transparent comments on the mailing lists. > > Regards, > > Rainer > -- ---------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS BUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | ---------------------------------------------------------------------- e-mail client: Thunderbird (Solaris) From Jon.Masamitsu at Sun.COM Mon Oct 13 15:46:16 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 13 Oct 2008 08:46:16 -0700 Subject: Java6u7 : 2 very long Parallel GC (24&30min) without any specific reason In-Reply-To: References: Message-ID: <48F36D48.3050907@Sun.COM> David, Are you setting the maximum heap size on your command line? If not, you may be getting a larger maximum by default. That value has been changed on 64 bit platforms. It used to be 1g (which was ok for 32 bit platforms but makes less sense for 64 bit platforms). Try -Xmx1g which will give you the old behavior. On 10/13/08 06:37, David Tavoularis wrote: > Hi, > > We had 2 very long duration of the Full GC (Parallel GC) running with Java 6u7 (64-bit Solaris), where GC took 24min and then 30min. > Usually, Full GC would hardly take more than 2 minutes. > > We also noticed that the "real" measurement usually comes close to the sum of the "user" and "sys" measurement, but here it outpasses the figures, see : > user=47.85 sys=9.84, real=1450.70 secs This says that the VM is doing lots of waiting. Do you have more than 1 VM running on this machine? Or other applications that are using lots of physical memory? The much larger real time often indicates swapping. > > Any idea what to check from here ? > > > As a workaround, I would like to implement the property "-XX:MaxGCPauseMillis=60000" (10min max for a Full GC). Do you think it is a good idea ? > Using this setting should limit the growth of the heap so that you stay below the 10min pause. You should be able to see the size of the heap in the GC logs (young gen + old (tenured) gen). > Thanks in advance > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From kirk.pepperdine at gmail.com Mon Oct 13 15:21:57 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Mon, 13 Oct 2008 17:21:57 +0200 Subject: CMS collection keep working during holiday In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED2F8E.3050703@Sun.COM> <19893088.post@talk.nabble.com> <19895899.post@talk.nabble.com> <48EE3B3F.7050107@javaperformancetuning.com> <19912471.post@talk.nabble.com> Message-ID: <48F36795.4010601@javaperformancetuning.com> Hi, I've got a histogram that includes a number of classes that I've not seen at the top of a histogram just yet. This is a pre-gc histogram from the 1.5.0_15. Any thoughts on what might cause these to build up? 1 Object Histogram: 2 3 Size Count Class description 4 ------------------------------------------------------- 5 2009570160 35394 int[] 6 25703600 237926 char[] 7 23512384 20129 byte[] 8 18761568 144582 * ConstMethodKlass <---- 9 10416360 144582 * MethodKlass <---- 10 8144800 194428 * SymbolKlass <---- 11 7925040 13619 * ConstantPoolKlass <---- 12 6832800 284700 java.lang.String 13 5619232 13619 * InstanceKlassKlass <---- 14 4503280 11914 * ConstantPoolCacheKlass <---- 15 3498664 37130 java.util.HashMap$Entry[] 16 3116000 97375 java.util.TreeMap$Entry 17 3067808 37737 java.lang.Object[] 18 2498800 31235 java.lang.reflect.Method 19 2364600 98525 java.util.HashMap$Entry 20 1683520 42088 org.apache.velocity.runtime.parser.Token 21 1626552 5532 * MethodDataKlass <---- Regards, Kirk Pepperdine From Y.S.Ramakrishna at Sun.COM Mon Oct 13 15:59:13 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Mon, 13 Oct 2008 08:59:13 -0700 Subject: CMS collection keep working during holiday In-Reply-To: <48F36795.4010601@javaperformancetuning.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED2F8E.3050703@Sun.COM> <19893088.post@talk.nabble.com> <19895899.post@talk.nabble.com> <48EE3B3F.7050107@javaperformancetuning.com> <19912471.post@talk.nabble.com> <48F36795.4010601@javaperformancetuning.com> Message-ID: These are class meta-data that live in the perm gen. -- ramki ----- Original Message ----- From: kirk Date: Monday, October 13, 2008 8:56 am Subject: Re: CMS collection keep working during holiday Cc: hotspot-gc-dev at openjdk.java.net > Hi, > > I've got a histogram that includes a number of classes that I've not > seen at the top of a histogram just yet. This is a pre-gc histogram > from > the 1.5.0_15. Any thoughts on what might cause these to build up? > > 1 Object Histogram: > 2 > 3 Size Count Class description > 4 ------------------------------------------------------- > 5 2009570160 35394 int[] > 6 25703600 237926 char[] > 7 23512384 20129 byte[] > 8 18761568 144582 * ConstMethodKlass <---- > 9 10416360 144582 * MethodKlass <---- > 10 8144800 194428 * SymbolKlass <---- > 11 7925040 13619 * ConstantPoolKlass <---- > 12 6832800 284700 java.lang.String > 13 5619232 13619 * InstanceKlassKlass <---- > 14 4503280 11914 * ConstantPoolCacheKlass <---- > 15 3498664 37130 java.util.HashMap$Entry[] > 16 3116000 97375 java.util.TreeMap$Entry > 17 3067808 37737 java.lang.Object[] > 18 2498800 31235 java.lang.reflect.Method > 19 2364600 98525 java.util.HashMap$Entry > 20 1683520 42088 org.apache.velocity.runtime.parser.Token > 21 1626552 5532 * MethodDataKlass <---- > > Regards, > Kirk Pepperdine > From kirk.pepperdine at gmail.com Mon Oct 13 16:36:20 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Mon, 13 Oct 2008 18:36:20 +0200 Subject: class metadata In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED2F8E.3050703@Sun.COM> <19893088.post@talk.nabble.com> <19895899.post@talk.nabble.com> <48EE3B3F.7050107@javaperformancetuning.com> <19912471.post@talk.nabble.com> <48F36795.4010601@javaperformancetuning.com> Message-ID: <48F37904.70901@gmail.com> Hi Ramki, Thanks. Running the default collectors so I'm believing that these should be collected. These are from the C++ layer? Regards, Kirk Y Srinivas Ramakrishna wrote: > These are class meta-data that live in the perm gen. > > -- ramki > > ----- Original Message ----- > From: kirk > Date: Monday, October 13, 2008 8:56 am > Subject: Re: CMS collection keep working during holiday > Cc: hotspot-gc-dev at openjdk.java.net > > > >> Hi, >> >> I've got a histogram that includes a number of classes that I've not >> seen at the top of a histogram just yet. This is a pre-gc histogram >> from >> the 1.5.0_15. Any thoughts on what might cause these to build up? >> >> 1 Object Histogram: >> 2 >> 3 Size Count Class description >> 4 ------------------------------------------------------- >> 5 2009570160 35394 int[] >> 6 25703600 237926 char[] >> 7 23512384 20129 byte[] >> 8 18761568 144582 * ConstMethodKlass <---- >> 9 10416360 144582 * MethodKlass <---- >> 10 8144800 194428 * SymbolKlass <---- >> 11 7925040 13619 * ConstantPoolKlass <---- >> 12 6832800 284700 java.lang.String >> 13 5619232 13619 * InstanceKlassKlass <---- >> 14 4503280 11914 * ConstantPoolCacheKlass <---- >> 15 3498664 37130 java.util.HashMap$Entry[] >> 16 3116000 97375 java.util.TreeMap$Entry >> 17 3067808 37737 java.lang.Object[] >> 18 2498800 31235 java.lang.reflect.Method >> 19 2364600 98525 java.util.HashMap$Entry >> 20 1683520 42088 org.apache.velocity.runtime.parser.Token >> 21 1626552 5532 * MethodDataKlass <---- >> >> Regards, >> Kirk Pepperdine >> >> > > From Y.S.Ramakrishna at Sun.COM Mon Oct 13 16:51:33 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Mon, 13 Oct 2008 09:51:33 -0700 Subject: class metadata In-Reply-To: <48F37904.70901@gmail.com> References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED2F8E.3050703@Sun.COM> <19893088.post@talk.nabble.com> <19895899.post@talk.nabble.com> <48EE3B3F.7050107@javaperformancetuning.com> <19912471.post@talk.nabble.com> <48F36795.4010601@javaperformancetuning.com> <48F37904.70901@gmail.com> Message-ID: > Thanks. Running the default collectors so I'm believing that these > should be collected. These are from the C++ layer? Sorry, i was not very clear. No, this is from the JVM's representation of the classes used by the application that the JVM is running. It's possible that the classes here are in fact being actively used by your application and/or represent the classes that were loaded by the system class-loader and will therefore never be unloaded? (although the total size occupied by them here appears suspiciously large.) Check "jmap -permstat" for more information; you might also want to try a more recent jvm perhaps. best. -- ramki > > Regards, > Kirk > > Y Srinivas Ramakrishna wrote: > > These are class meta-data that live in the perm gen. > > > > -- ramki > > > > ----- Original Message ----- > > From: kirk > > Date: Monday, October 13, 2008 8:56 am > > Subject: Re: CMS collection keep working during holiday > > Cc: hotspot-gc-dev at openjdk.java.net > > > > > > > >> Hi, > >> > >> I've got a histogram that includes a number of classes that I've > not > >> seen at the top of a histogram just yet. This is a pre-gc histogram > > >> from > >> the 1.5.0_15. Any thoughts on what might cause these to build up? > >> > >> 1 Object Histogram: > >> 2 > >> 3 Size Count Class description > >> 4 ------------------------------------------------------- > >> 5 2009570160 35394 int[] > >> 6 25703600 237926 char[] > >> 7 23512384 20129 byte[] > >> 8 18761568 144582 * ConstMethodKlass <---- > >> 9 10416360 144582 * MethodKlass <---- > >> 10 8144800 194428 * SymbolKlass <---- > >> 11 7925040 13619 * ConstantPoolKlass <---- > >> 12 6832800 284700 java.lang.String > >> 13 5619232 13619 * InstanceKlassKlass <---- > >> 14 4503280 11914 * ConstantPoolCacheKlass <---- > >> 15 3498664 37130 java.util.HashMap$Entry[] > >> 16 3116000 97375 java.util.TreeMap$Entry > >> 17 3067808 37737 java.lang.Object[] > >> 18 2498800 31235 java.lang.reflect.Method > >> 19 2364600 98525 java.util.HashMap$Entry > >> 20 1683520 42088 org.apache.velocity.runtime.parser.Token > >> 21 1626552 5532 * MethodDataKlass <---- > >> > >> Regards, > >> Kirk Pepperdine > >> > >> > > > > > From kirk.pepperdine at gmail.com Mon Oct 13 17:01:56 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Mon, 13 Oct 2008 19:01:56 +0200 Subject: class metadata In-Reply-To: References: <19773575.post@talk.nabble.com> <19827116.post@talk.nabble.com> <48EA2BFC.2020309@Sun.COM> <19841670.post@talk.nabble.com> <19872463.post@talk.nabble.com> <48EC5C5A.4030401@javaperformancetuning.com> <48ECC28A.8030004@sun.com> <19882121.post@talk.nabble.com> <48ED2F8E.3050703@Sun.COM> <19893088.post@talk.nabble.com> <19895899.post@talk.nabble.com> <48EE3B3F.7050107@javaperformancetuning.com> <19912471.post@talk.nabble.com> <48F36795.4010601@javaperformancetuning.com> <48F37904.70901@gmail.com> Message-ID: <48F37F04.6050101@gmail.com> Hi Ramki, Yes, the size is suspiciously large which is why I don't suspect the bootstrap classloader. I'll get a permspace histo. Unfortunately I can't use the 1.6 as I'm tied in by JBoss. We do have a proper staging environment which I'm going to move to. I was just trying to get a characterization of the problem in prod prior to putting a proper heap profiler to work. Thanks for you conformation of my suspicions. Regards, Kirk Y Srinivas Ramakrishna wrote: >> Thanks. Running the default collectors so I'm believing that these >> should be collected. These are from the C++ layer? >> > > Sorry, i was not very clear. No, this is from the JVM's representation of > the classes used by the application that the JVM is running. > It's possible that the classes here are in fact being actively > used by your application and/or represent the classes that were > loaded by the system class-loader and will therefore never be unloaded? > (although the total size occupied by them here appears suspiciously > large.) Check "jmap -permstat" for more information; you might also > want to try a more recent jvm perhaps. > > best. > -- ramki > > > >> Regards, >> Kirk >> >> Y Srinivas Ramakrishna wrote: >> >>> These are class meta-data that live in the perm gen. >>> >>> -- ramki >>> >>> ----- Original Message ----- >>> From: kirk >>> Date: Monday, October 13, 2008 8:56 am >>> Subject: Re: CMS collection keep working during holiday >>> Cc: hotspot-gc-dev at openjdk.java.net >>> >>> >>> >>> >>>> Hi, >>>> >>>> I've got a histogram that includes a number of classes that I've >>>> >> not >> >>>> seen at the top of a histogram just yet. This is a pre-gc histogram >>>> >>>> from >>>> the 1.5.0_15. Any thoughts on what might cause these to build up? >>>> >>>> 1 Object Histogram: >>>> 2 >>>> 3 Size Count Class description >>>> 4 ------------------------------------------------------- >>>> 5 2009570160 35394 int[] >>>> 6 25703600 237926 char[] >>>> 7 23512384 20129 byte[] >>>> 8 18761568 144582 * ConstMethodKlass <---- >>>> 9 10416360 144582 * MethodKlass <---- >>>> 10 8144800 194428 * SymbolKlass <---- >>>> 11 7925040 13619 * ConstantPoolKlass <---- >>>> 12 6832800 284700 java.lang.String >>>> 13 5619232 13619 * InstanceKlassKlass <---- >>>> 14 4503280 11914 * ConstantPoolCacheKlass <---- >>>> 15 3498664 37130 java.util.HashMap$Entry[] >>>> 16 3116000 97375 java.util.TreeMap$Entry >>>> 17 3067808 37737 java.lang.Object[] >>>> 18 2498800 31235 java.lang.reflect.Method >>>> 19 2364600 98525 java.util.HashMap$Entry >>>> 20 1683520 42088 org.apache.velocity.runtime.parser.Token >>>> 21 1626552 5532 * MethodDataKlass <---- >>>> >>>> Regards, >>>> Kirk Pepperdine >>>> >>>> >>>> >>> >>> > > From Jon.Masamitsu at Sun.COM Mon Oct 13 18:39:17 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 13 Oct 2008 11:39:17 -0700 Subject: Java6u7 : 2 very long Parallel GC (24&30min) without any specific reason In-Reply-To: References: <48F36D48.3050907@Sun.COM> Message-ID: <48F395D5.8080802@Sun.COM> On 10/13/08 11:31, David Tavoularis wrote: ... >> Using this setting should limit the growth of the heap >> so that you stay below the 10min pause. You should be >> able to see the size of the heap in the GC logs >> (young gen + old (tenured) gen). > I do not understand, does it mean that ms and mx values from command line will not be taken into account ? > Here ms=mx, so I do not expect any change in the heap size. > We also defined on the command line new=4GB, so old=16GB (approximately), according to GC logs. > If you set ms=mx, then there should be no effect from setting pause time goal. The VM will try to grow/shrink the heap size within the bounds of ms and mx in order to meet the pause time goal. Since you have ms=mx, the VM does not have anything to adjust. _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From igor.veresov at sun.com Tue Oct 14 10:58:50 2008 From: igor.veresov at sun.com (igor.veresov at sun.com) Date: Tue, 14 Oct 2008 10:58:50 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6758633: G1: SEGV with GCOld on Linux Message-ID: <20081014105901.970FFD107@hg.openjdk.java.net> Changeset: 078b8a0d8d7c Author: iveresov Date: 2008-10-13 21:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/078b8a0d8d7c 6758633: G1: SEGV with GCOld on Linux Summary: Avoid growth of a GrowableArray backend of HeapRegionSeq. Reviewed-by: tonyp, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp From rainer.jung at kippdata.de Tue Oct 14 15:15:10 2008 From: rainer.jung at kippdata.de (Rainer Jung) Date: Tue, 14 Oct 2008 17:15:10 +0200 Subject: gclog improvements In-Reply-To: <48F35B43.3030401@sun.com> References: <48F1E31E.5090707@kippdata.de> <48F35B43.3030401@sun.com> Message-ID: <48F4B77E.1080806@kippdata.de> Tony Printezis schrieb: >> Unfortunately the gclog gets overwrittten each time the JVM starts due >> to the way the file gets opened. So in order to keep the files people >> need to add rotation commands to their start scripts. Often this doesn't >> happen and especially when emergency restarts where needed, the old >> gclog is gone. >> >> Any plans for changing this? Or maybe even adding log file rotation to >> the gclog? >> > We don't have any immediate plans for doing this. Regarding the log file > getting overwritten, typically customers launch the JVM from a script > and it's easy to create a unique GC log file name from a script (append > the start time, pid, or something like that). So, that's an easy issue > to solve... Yes, but I do now see a lot of customers running their midrange server apps on Windows. Those are of course services started by Java service wrappers, which are not themselves easily scriptable. Especially automatic restarts triggered by built-in watchdogs do not have any scripting mechanism. >> Furthermore: Until now there is no event based model of monitoring the >> GC and Memory data. All methods apart from logging are based on a pull >> model, that retrieves information in regular intervals. The most >> important information does not exist in regular intervals, but instead >> immediately after a GC. It would be nice to have some event based model >> (e.g. like in JVMTI), that allows to track the same data as the gc >> logging, without using the historically motivated gclog file format. >> > There's a trade-off. I don't like the pull method myself, given that it > can skip events, give you inconsistent information, etc. But, to get > consistent information you generally have to do a STW pause, and this is > too much of an overhead for an application in production. This is why a > lot of the monitoring has been implemented asynchronously. So there is a problem in getting a perfect solution. An approximation could be: - provide a buffer with the information obtained after the last Minor/Major GC (e.g. GC type, count, total and filled sizes of the various memory regions, durations of the last run) - fire an asynchronous event (not STW) to allow agents to retrieve the buffered data That's a hybrid, that would try to provide some benefits of the event model, without risking long STW pauses. Of course one would have to think about synchronizing read/write access to the buffer, but without an actual agent running, there would be no contention, and with an agent running there would be only noticable performance impact, if there were lots of GCs and additionally the agent did expensive operations while retrieving the buffers. Regards, Rainer From Antonios.Printezis at sun.com Tue Oct 14 15:50:06 2008 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Tue, 14 Oct 2008 11:50:06 -0400 Subject: gclog improvements In-Reply-To: <48F4B77E.1080806@kippdata.de> References: <48F1E31E.5090707@kippdata.de> <48F35B43.3030401@sun.com> <48F4B77E.1080806@kippdata.de> Message-ID: <48F4BFAE.504@sun.com> Rainer, Rainer Jung wrote: > Tony Printezis schrieb: > >> We don't have any immediate plans for doing this. Regarding the log file >> getting overwritten, typically customers launch the JVM from a script >> and it's easy to create a unique GC log file name from a script (append >> the start time, pid, or something like that). So, that's an easy issue >> to solve... >> > > Yes, but I do now see a lot of customers running their midrange server > apps on Windows. I'm _so_ sorry. :-) > Those are of course services started by Java service > wrappers, which are not themselves easily scriptable. Especially > automatic restarts triggered by built-in watchdogs do not have any > scripting mechanism. > I'm happy to say I don't know much about the intricacies of scripting under Windows. >>> Furthermore: Until now there is no event based model of monitoring the >>> GC and Memory data. All methods apart from logging are based on a pull >>> model, that retrieves information in regular intervals. The most >>> important information does not exist in regular intervals, but instead >>> immediately after a GC. It would be nice to have some event based model >>> (e.g. like in JVMTI), that allows to track the same data as the gc >>> logging, without using the historically motivated gclog file format. >>> >>> >> There's a trade-off. I don't like the pull method myself, given that it >> can skip events, give you inconsistent information, etc. But, to get >> consistent information you generally have to do a STW pause, and this is >> too much of an overhead for an application in production. This is why a >> lot of the monitoring has been implemented asynchronously. >> > > So there is a problem in getting a perfect solution. An approximation > could be: > > - provide a buffer with the information obtained after the last > Minor/Major GC (e.g. GC type, count, total and filled sizes of the > various memory regions, durations of the last run) > > - fire an asynchronous event (not STW) to allow agents to retrieve the > buffered data > > That's a hybrid, that would try to provide some benefits of the event > model, without risking long STW pauses. Of course one would have to > think about synchronizing read/write access to the buffer, but without > an actual agent running, there would be no contention, and with an agent > running there would be only noticable performance impact, if there were > lots of GCs and additionally the agent did expensive operations while > retrieving the buffers. > FWIW, we have actually considered doing something like that. However, improving GC logging is not, unfortunately, high on our priority list right now... Tony -- ---------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS BUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | ---------------------------------------------------------------------- e-mail client: Thunderbird (Solaris) From kirk.pepperdine at gmail.com Tue Oct 14 16:42:27 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Tue, 14 Oct 2008 18:42:27 +0200 Subject: gclog improvements In-Reply-To: <48F4B77E.1080806@kippdata.de> References: <48F1E31E.5090707@kippdata.de> <48F35B43.3030401@sun.com> <48F4B77E.1080806@kippdata.de> Message-ID: <48F4CBF3.7060505@gmail.com> Hi, IBM does log rollovers and IMHO it's a reasonable feature request. It makes it easier to leave verbose gc turned on in production. Regards, Kirk Rainer Jung wrote: > Tony Printezis schrieb: > >>> Unfortunately the gclog gets overwrittten each time the JVM starts due >>> to the way the file gets opened. So in order to keep the files people >>> need to add rotation commands to their start scripts. Often this doesn't >>> happen and especially when emergency restarts where needed, the old >>> gclog is gone. >>> >>> Any plans for changing this? Or maybe even adding log file rotation to >>> the gclog? >>> >>> >> We don't have any immediate plans for doing this. Regarding the log file >> getting overwritten, typically customers launch the JVM from a script >> and it's easy to create a unique GC log file name from a script (append >> the start time, pid, or something like that). So, that's an easy issue >> to solve... >> > > Yes, but I do now see a lot of customers running their midrange server > apps on Windows. Those are of course services started by Java service > wrappers, which are not themselves easily scriptable. Especially > automatic restarts triggered by built-in watchdogs do not have any > scripting mechanism. > > >>> Furthermore: Until now there is no event based model of monitoring the >>> GC and Memory data. All methods apart from logging are based on a pull >>> model, that retrieves information in regular intervals. The most >>> important information does not exist in regular intervals, but instead >>> immediately after a GC. It would be nice to have some event based model >>> (e.g. like in JVMTI), that allows to track the same data as the gc >>> logging, without using the historically motivated gclog file format. >>> >>> >> There's a trade-off. I don't like the pull method myself, given that it >> can skip events, give you inconsistent information, etc. But, to get >> consistent information you generally have to do a STW pause, and this is >> too much of an overhead for an application in production. This is why a >> lot of the monitoring has been implemented asynchronously. >> > > So there is a problem in getting a perfect solution. An approximation > could be: > > - provide a buffer with the information obtained after the last > Minor/Major GC (e.g. GC type, count, total and filled sizes of the > various memory regions, durations of the last run) > > - fire an asynchronous event (not STW) to allow agents to retrieve the > buffered data > > That's a hybrid, that would try to provide some benefits of the event > model, without risking long STW pauses. Of course one would have to > think about synchronizing read/write access to the buffer, but without > an actual agent running, there would be no contention, and with an agent > running there would be only noticable performance impact, if there were > lots of GCs and additionally the agent did expensive operations while > retrieving the buffers. > > Regards, > > Rainer > > From Jon.Masamitsu at Sun.COM Tue Oct 14 18:09:55 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Tue, 14 Oct 2008 11:09:55 -0700 Subject: gclog improvements In-Reply-To: <48F4CBF3.7060505@gmail.com> References: <48F1E31E.5090707@kippdata.de> <48F35B43.3030401@sun.com> <48F4B77E.1080806@kippdata.de> <48F4CBF3.7060505@gmail.com> Message-ID: <48F4E073.6090702@Sun.COM> On 10/14/08 09:42, kirk wrote: > Hi, > > IBM does log rollovers and IMHO it's a reasonable feature request. It > makes it easier to leave verbose gc turned on in production. It is a reasonable feature and it would probably fit into an overhaul of the logging infrastructure that is on the to-do list of the runtime guys. However, there is no one available to work on that logging overhaul so I would not be too hopeful. > > Regards, > Kirk > > Rainer Jung wrote: >> Tony Printezis schrieb: >> >>>> Unfortunately the gclog gets overwrittten each time the JVM starts due >>>> to the way the file gets opened. So in order to keep the files people >>>> need to add rotation commands to their start scripts. Often this >>>> doesn't >>>> happen and especially when emergency restarts where needed, the old >>>> gclog is gone. >>>> >>>> Any plans for changing this? Or maybe even adding log file rotation to >>>> the gclog? >>>> >>> We don't have any immediate plans for doing this. Regarding the log file >>> getting overwritten, typically customers launch the JVM from a script >>> and it's easy to create a unique GC log file name from a script (append >>> the start time, pid, or something like that). So, that's an easy issue >>> to solve... >>> >> >> Yes, but I do now see a lot of customers running their midrange server >> apps on Windows. Those are of course services started by Java service >> wrappers, which are not themselves easily scriptable. Especially >> automatic restarts triggered by built-in watchdogs do not have any >> scripting mechanism. >> >> >>>> Furthermore: Until now there is no event based model of monitoring the >>>> GC and Memory data. All methods apart from logging are based on a pull >>>> model, that retrieves information in regular intervals. The most >>>> important information does not exist in regular intervals, but instead >>>> immediately after a GC. It would be nice to have some event based model >>>> (e.g. like in JVMTI), that allows to track the same data as the gc >>>> logging, without using the historically motivated gclog file format. >>>> >>> There's a trade-off. I don't like the pull method myself, given that it >>> can skip events, give you inconsistent information, etc. But, to get >>> consistent information you generally have to do a STW pause, and this is >>> too much of an overhead for an application in production. This is why a >>> lot of the monitoring has been implemented asynchronously. >>> >> >> So there is a problem in getting a perfect solution. An approximation >> could be: >> >> - provide a buffer with the information obtained after the last >> Minor/Major GC (e.g. GC type, count, total and filled sizes of the >> various memory regions, durations of the last run) >> >> - fire an asynchronous event (not STW) to allow agents to retrieve the >> buffered data >> >> That's a hybrid, that would try to provide some benefits of the event >> model, without risking long STW pauses. Of course one would have to >> think about synchronizing read/write access to the buffer, but without >> an actual agent running, there would be no contention, and with an agent >> running there would be only noticable performance impact, if there were >> lots of GCs and additionally the agent did expensive operations while >> retrieving the buffers. >> >> Regards, >> >> Rainer >> >> > From kirk.pepperdine at gmail.com Tue Oct 14 18:48:10 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Tue, 14 Oct 2008 20:48:10 +0200 Subject: gclog improvements In-Reply-To: <48F4E073.6090702@Sun.COM> References: <48F1E31E.5090707@kippdata.de> <48F35B43.3030401@sun.com> <48F4B77E.1080806@kippdata.de> <48F4CBF3.7060505@gmail.com> <48F4E073.6090702@Sun.COM> Message-ID: <48F4E96A.3050404@gmail.com> Hi Jon, Ok, now I'm scared ;-) What do you mean by "work on that logging overhaul"? I've got a bit invested in the status quo and while I'm all for an overhaul, it would be nice to understand what is on the table. Regards, Kirk Jon Masamitsu wrote: > > > On 10/14/08 09:42, kirk wrote: >> Hi, >> >> IBM does log rollovers and IMHO it's a reasonable feature request. It >> makes it easier to leave verbose gc turned on in production. > > It is a reasonable feature and it would > probably fit into an overhaul of the logging > infrastructure that is on the to-do list > of the runtime guys. However, there is no one > available to work on that logging overhaul > so I would not be too hopeful. > >> >> Regards, >> Kirk >> >> Rainer Jung wrote: >>> Tony Printezis schrieb: >>> >>>>> Unfortunately the gclog gets overwrittten each time the JVM starts >>>>> due >>>>> to the way the file gets opened. So in order to keep the files people >>>>> need to add rotation commands to their start scripts. Often this >>>>> doesn't >>>>> happen and especially when emergency restarts where needed, the old >>>>> gclog is gone. >>>>> >>>>> Any plans for changing this? Or maybe even adding log file >>>>> rotation to >>>>> the gclog? >>>>> >>>> We don't have any immediate plans for doing this. Regarding the log >>>> file >>>> getting overwritten, typically customers launch the JVM from a script >>>> and it's easy to create a unique GC log file name from a script >>>> (append >>>> the start time, pid, or something like that). So, that's an easy issue >>>> to solve... >>>> >>> >>> Yes, but I do now see a lot of customers running their midrange server >>> apps on Windows. Those are of course services started by Java service >>> wrappers, which are not themselves easily scriptable. Especially >>> automatic restarts triggered by built-in watchdogs do not have any >>> scripting mechanism. >>> >>> >>>>> Furthermore: Until now there is no event based model of monitoring >>>>> the >>>>> GC and Memory data. All methods apart from logging are based on a >>>>> pull >>>>> model, that retrieves information in regular intervals. The most >>>>> important information does not exist in regular intervals, but >>>>> instead >>>>> immediately after a GC. It would be nice to have some event based >>>>> model >>>>> (e.g. like in JVMTI), that allows to track the same data as the gc >>>>> logging, without using the historically motivated gclog file format. >>>>> >>>> There's a trade-off. I don't like the pull method myself, given >>>> that it >>>> can skip events, give you inconsistent information, etc. But, to get >>>> consistent information you generally have to do a STW pause, and >>>> this is >>>> too much of an overhead for an application in production. This is >>>> why a >>>> lot of the monitoring has been implemented asynchronously. >>>> >>> >>> So there is a problem in getting a perfect solution. An approximation >>> could be: >>> >>> - provide a buffer with the information obtained after the last >>> Minor/Major GC (e.g. GC type, count, total and filled sizes of the >>> various memory regions, durations of the last run) >>> >>> - fire an asynchronous event (not STW) to allow agents to retrieve the >>> buffered data >>> >>> That's a hybrid, that would try to provide some benefits of the event >>> model, without risking long STW pauses. Of course one would have to >>> think about synchronizing read/write access to the buffer, but without >>> an actual agent running, there would be no contention, and with an >>> agent >>> running there would be only noticable performance impact, if there were >>> lots of GCs and additionally the agent did expensive operations while >>> retrieving the buffers. >>> >>> Regards, >>> >>> Rainer >>> >>> >> > > From Jon.Masamitsu at Sun.COM Tue Oct 14 20:19:08 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Tue, 14 Oct 2008 13:19:08 -0700 Subject: gclog improvements In-Reply-To: <48F4E96A.3050404@gmail.com> References: <48F1E31E.5090707@kippdata.de> <48F35B43.3030401@sun.com> <48F4B77E.1080806@kippdata.de> <48F4CBF3.7060505@gmail.com> <48F4E073.6090702@Sun.COM> <48F4E96A.3050404@gmail.com> Message-ID: <48F4FEBC.9050801@Sun.COM> There's a project to define a common standard for logging in J2SE and J2EE. If that happens then there is a second project to make the VM logging fit into that same infrastructure. One of the hopes was that an application could see logs from the VM through a well defined API. On 10/14/08 11:48, kirk wrote: > Hi Jon, > > Ok, now I'm scared ;-) What do you mean by "work on that logging > overhaul"? I've got a bit invested in the status quo and while I'm all > for an overhaul, it would be nice to understand what is on the table. > > Regards, > Kirk > > Jon Masamitsu wrote: >> >> >> On 10/14/08 09:42, kirk wrote: >>> Hi, >>> >>> IBM does log rollovers and IMHO it's a reasonable feature request. It >>> makes it easier to leave verbose gc turned on in production. >> >> It is a reasonable feature and it would >> probably fit into an overhaul of the logging >> infrastructure that is on the to-do list >> of the runtime guys. However, there is no one >> available to work on that logging overhaul >> so I would not be too hopeful. >> >>> >>> Regards, >>> Kirk >>> >>> Rainer Jung wrote: >>>> Tony Printezis schrieb: >>>> >>>>>> Unfortunately the gclog gets overwrittten each time the JVM starts >>>>>> due >>>>>> to the way the file gets opened. So in order to keep the files people >>>>>> need to add rotation commands to their start scripts. Often this >>>>>> doesn't >>>>>> happen and especially when emergency restarts where needed, the old >>>>>> gclog is gone. >>>>>> >>>>>> Any plans for changing this? Or maybe even adding log file >>>>>> rotation to >>>>>> the gclog? >>>>>> >>>>> We don't have any immediate plans for doing this. Regarding the log >>>>> file >>>>> getting overwritten, typically customers launch the JVM from a script >>>>> and it's easy to create a unique GC log file name from a script >>>>> (append >>>>> the start time, pid, or something like that). So, that's an easy issue >>>>> to solve... >>>>> >>>> >>>> Yes, but I do now see a lot of customers running their midrange server >>>> apps on Windows. Those are of course services started by Java service >>>> wrappers, which are not themselves easily scriptable. Especially >>>> automatic restarts triggered by built-in watchdogs do not have any >>>> scripting mechanism. >>>> >>>> >>>>>> Furthermore: Until now there is no event based model of monitoring >>>>>> the >>>>>> GC and Memory data. All methods apart from logging are based on a >>>>>> pull >>>>>> model, that retrieves information in regular intervals. The most >>>>>> important information does not exist in regular intervals, but >>>>>> instead >>>>>> immediately after a GC. It would be nice to have some event based >>>>>> model >>>>>> (e.g. like in JVMTI), that allows to track the same data as the gc >>>>>> logging, without using the historically motivated gclog file format. >>>>>> >>>>> There's a trade-off. I don't like the pull method myself, given >>>>> that it >>>>> can skip events, give you inconsistent information, etc. But, to get >>>>> consistent information you generally have to do a STW pause, and >>>>> this is >>>>> too much of an overhead for an application in production. This is >>>>> why a >>>>> lot of the monitoring has been implemented asynchronously. >>>>> >>>> >>>> So there is a problem in getting a perfect solution. An approximation >>>> could be: >>>> >>>> - provide a buffer with the information obtained after the last >>>> Minor/Major GC (e.g. GC type, count, total and filled sizes of the >>>> various memory regions, durations of the last run) >>>> >>>> - fire an asynchronous event (not STW) to allow agents to retrieve the >>>> buffered data >>>> >>>> That's a hybrid, that would try to provide some benefits of the event >>>> model, without risking long STW pauses. Of course one would have to >>>> think about synchronizing read/write access to the buffer, but without >>>> an actual agent running, there would be no contention, and with an >>>> agent >>>> running there would be only noticable performance impact, if there were >>>> lots of GCs and additionally the agent did expensive operations while >>>> retrieving the buffers. >>>> >>>> Regards, >>>> >>>> Rainer >>>> >>>> >>> >> >> > From rainer.jung at kippdata.de Tue Oct 14 21:22:04 2008 From: rainer.jung at kippdata.de (Rainer Jung) Date: Tue, 14 Oct 2008 23:22:04 +0200 Subject: gclog improvements In-Reply-To: <48F4BFAE.504@sun.com> References: <48F1E31E.5090707@kippdata.de> <48F35B43.3030401@sun.com><48F4B77E.1080806@kippdata.de> <48F4BFAE.504@sun.com> Message-ID: <48F50D7C.3010908@kippdata.de> Tony Printezis schrieb: > Rainer, > > Rainer Jung wrote: >> Tony Printezis schrieb: >>> We don't have any immediate plans for doing this. Regarding the log file >>> getting overwritten, typically customers launch the JVM from a script >>> and it's easy to create a unique GC log file name from a script (append >>> the start time, pid, or something like that). So, that's an easy issue >>> to solve... >>> >> >> Yes, but I do now see a lot of customers running their midrange server >> apps on Windows. > I'm _so_ sorry. :-) >> Those are of course services started by Java service >> wrappers, which are not themselves easily scriptable. Especially >> automatic restarts triggered by built-in watchdogs do not have any >> scripting mechanism. >> > I'm happy to say I don't know much about the intricacies of scripting > under Windows. You could make it work platform independant by supporting formatting characters for pid (at least). There is already code for it in src/share/vm/utilities/ostream.cpp: make_log_name() replaces the first star in a string with the pid. It could be easily included in ostream_init_log() in the same file. Of course people already using a '*' in their log file names would experience incompatible behaviour, but that character is not very common in file names - even on Windows ;) More future proof (in the sense of extensible) would be to use %X for some letter X. Regards, Rainer From Antonios.Printezis at sun.com Wed Oct 15 17:16:05 2008 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Wed, 15 Oct 2008 13:16:05 -0400 Subject: gclog improvements In-Reply-To: <48F50D7C.3010908@kippdata.de> References: <48F1E31E.5090707@kippdata.de> <48F35B43.3030401@sun.com> <48F4B77E.1080806@kippdata.de> <48F4BFAE.504@sun.com> <48F50D7C.3010908@kippdata.de> Message-ID: <48F62555.9050301@sun.com> Rainer Jung wrote: > You could make it work platform independant by supporting formatting > characters for pid (at least). There is already code for it in > src/share/vm/utilities/ostream.cpp: make_log_name() replaces the first > star in a string with the pid. It could be easily included in > ostream_init_log() in the same file. Of course people already using a > '*' in their log file names would experience incompatible behaviour, but > that character is not very common in file names - even on Windows ;) > > More future proof (in the sense of extensible) would be to use %X for > some letter X. > Sounds like a nice little project. If you get it working and we like it, we will consider putting in into the openjdk. :-) Tony -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux) From antonios.printezis at sun.com Thu Oct 23 22:40:39 2008 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Thu, 23 Oct 2008 22:40:39 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 20 new changesets Message-ID: <20081023224121.DB046D9BB@hg.openjdk.java.net> Changeset: 9ee9cf798b59 Author: xdono Date: 2008-10-02 19:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9ee9cf798b59 6754988: Update copyright year Summary: Update for files that have been modified starting July 2008 Reviewed-by: ohair, tbell ! agent/make/bugspot.bat ! agent/make/build.xml ! agent/make/hsdb.bat ! agent/make/hsdb.sh ! agent/make/saenv.bat ! agent/make/saenv.sh ! agent/make/saenv64.bat ! agent/make/saenv64.sh ! agent/src/share/classes/sun/jvm/hotspot/runtime/CompiledVFrame.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Defs_x86.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.hpp ! src/cpu/x86/vm/c1_LinearScan_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.hpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/dump_x86_32.cpp ! src/cpu/x86/vm/dump_x86_64.cpp ! src/cpu/x86/vm/icache_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/interpreterRT_x86_64.cpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/os/solaris/vm/osThread_solaris.cpp ! src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/gc_implementation/shared/spaceDecorator.cpp ! src/share/vm/gc_implementation/shared/spaceDecorator.hpp ! src/share/vm/includeDB_features ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/threadLocalStorage.cpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/utilities/macros.hpp Changeset: d9bc824aa078 Author: xdono Date: 2008-10-09 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d9bc824aa078 Added tag jdk7-b37 for changeset 9ee9cf798b59 ! .hgtags Changeset: eb28cf662f56 Author: trims Date: 2008-10-07 11:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/eb28cf662f56 Merge ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: 3dfb71f4a560 Author: trims Date: 2008-10-15 18:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3dfb71f4a560 Merge Changeset: bc1cf4d7cab3 Author: trims Date: 2008-10-15 18:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/bc1cf4d7cab3 Merge Changeset: 4d05b7cb7842 Author: mchung Date: 2008-10-14 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4d05b7cb7842 6306922: Dump dump created by +HeapDumpOnOutOfMemoryError should include stack traces for stack roots Summary: Include stack traces of all threads in the heap dump Reviewed-by: alanb ! src/share/vm/includeDB_features ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/threadService.hpp Changeset: 1bf7a2ce4895 Author: dcubed Date: 2008-10-16 11:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1bf7a2ce4895 Merge ! src/share/vm/includeDB_features Changeset: 443791f333a2 Author: coleenp Date: 2008-10-14 10:15 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/443791f333a2 6700107: java/lang/Class/forName/TooManyDimensions.java crashes with SIGSEGV in c2 compiler with fastdebug Summary: objArrayKlass::compute_modifier_flags was unnecessarily recursive Reviewed-by: kamg ! src/share/vm/oops/objArrayKlass.cpp Changeset: 7b51912bdf9a Author: xlu Date: 2008-10-17 15:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7b51912bdf9a Merge Changeset: cc80376deb0c Author: kvn Date: 2008-10-02 08:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/cc80376deb0c 6667595: Set probability FAIR for pre-, post- loops and ALWAYS for main loop Summary: Fix loop's probability. Add optimizations to avoid spilling. Change InlineSmallCode to product flag. Reviewed-by: never ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/runtime/globals.hpp Changeset: ee8f06bfb27c Author: never Date: 2008-10-03 13:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ee8f06bfb27c 6743188: incomplete fix for 6700047 C2 failed in idom_no_update Reviewed-by: rasbold, kvn ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! test/compiler/6700047/Test6700047.java Changeset: b4e0a161f551 Author: never Date: 2008-10-06 13:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b4e0a161f551 Merge ! src/share/vm/runtime/globals.hpp Changeset: b744678d4d71 Author: rasbold Date: 2008-10-10 09:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b744678d4d71 6752257: Use NOT instead of XOR -1 on x86 Summary: add match rule for xor -1 Reviewed-by: never, kvn ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad Changeset: 78c058bc5cdc Author: rasbold Date: 2008-10-14 06:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/78c058bc5cdc 6717150: improper constant folding of subnormal strictfp multiplications and divides Summary: suppress constant folding of double divides and multiplications on ia32 Reviewed-by: never ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/mulnode.cpp Changeset: 2649e5276dd7 Author: kvn Date: 2008-10-14 15:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2649e5276dd7 6532536: Optimize arraycopy stubs for Intel cpus Summary: Use SSE2 movdqu in arraycopy stubs on newest Intel's cpus Reviewed-by: rasbold ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86_32.cpp ! src/cpu/x86/vm/vm_version_x86_32.hpp ! src/cpu/x86/vm/vm_version_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86_64.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/globals.hpp Changeset: 67e8b4d06369 Author: never Date: 2008-10-21 11:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/67e8b4d06369 Merge ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/globals.hpp Changeset: ebfd4ae89bf6 Author: never Date: 2008-10-21 11:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ebfd4ae89bf6 6762004: 6532536 fix contains changes in os_solaris.cpp which were pushed by mistake Reviewed-by: kvn ! src/os/solaris/vm/os_solaris.cpp Changeset: 52e32c8b317e Author: acorn Date: 2008-10-22 14:48 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/52e32c8b317e 6761092: jvm crashes when CDS is enabled. Summary: CDS hardcoded max c++ virtual method table increased Reviewed-by: coleenp, xlu, jmasa ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/dump.cpp Changeset: 218f0fd3ca88 Author: acorn Date: 2008-10-22 15:07 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/218f0fd3ca88 Merge ! src/share/vm/memory/compactingPermGenGen.hpp Changeset: 8fb16f199266 Author: xlu Date: 2008-10-22 20:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/8fb16f199266 Merge From john.coomes at sun.com Fri Oct 24 05:11:29 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 24 Oct 2008 05:11:29 +0000 Subject: hg: jdk7/hotspot-gc: Added tag jdk7-b38 for changeset cc47a76899ed Message-ID: <20081024051130.15C23DA57@hg.openjdk.java.net> Changeset: ab523b49de1f Author: xdono Date: 2008-10-23 10:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/ab523b49de1f Added tag jdk7-b38 for changeset cc47a76899ed ! .hgtags From john.coomes at sun.com Fri Oct 24 05:12:56 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 24 Oct 2008 05:12:56 +0000 Subject: hg: jdk7/hotspot-gc/corba: 3 new changesets Message-ID: <20081024051259.AB7F7DA5C@hg.openjdk.java.net> Changeset: a067bf2329ef Author: tbell Date: 2008-10-15 21:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/a067bf2329ef 6759959: VS2008 errors compiling corba sources Summary: Update Makefiles to deal with newer Visual Studio releases Reviewed-by: ohair ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-msvc.gmk Changeset: 08be802754b0 Author: xdono Date: 2008-10-16 10:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/08be802754b0 Merge Changeset: 55078b6661e2 Author: xdono Date: 2008-10-23 10:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/55078b6661e2 Added tag jdk7-b38 for changeset 08be802754b0 ! .hgtags From john.coomes at sun.com Fri Oct 24 05:16:34 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 24 Oct 2008 05:16:34 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b38 for changeset e9f750f0a3a0 Message-ID: <20081024051637.26D51DA61@hg.openjdk.java.net> Changeset: 831b80be6cea Author: xdono Date: 2008-10-23 10:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/831b80be6cea Added tag jdk7-b38 for changeset e9f750f0a3a0 ! .hgtags From john.coomes at sun.com Fri Oct 24 05:18:04 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 24 Oct 2008 05:18:04 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b38 for changeset 9ce439969184 Message-ID: <20081024051806.85839DA66@hg.openjdk.java.net> Changeset: 077bc9b1b035 Author: xdono Date: 2008-10-23 10:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/077bc9b1b035 Added tag jdk7-b38 for changeset 9ce439969184 ! .hgtags From john.coomes at sun.com Fri Oct 24 05:21:57 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 24 Oct 2008 05:21:57 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 74 new changesets Message-ID: <20081024053821.BD3D8DA6B@hg.openjdk.java.net> Changeset: fa7147a26cd2 Author: malenkov Date: 2008-06-19 18:03 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/fa7147a26cd2 4114658: DOC: Unspecified behaviour for java.beans.PropertyEditorSupport Reviewed-by: peterz, loneid ! src/share/classes/java/beans/PropertyEditor.java ! src/share/classes/java/beans/PropertyEditorSupport.java Changeset: fc09152d5cf6 Author: idk Date: 2008-06-23 15:21 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/fc09152d5cf6 6623943: javax.swing.TimerQueue's thread occasionally fails to start Reviewed-by: alexp ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/TimerQueue.java Changeset: 282c86389114 Author: malenkov Date: 2008-06-26 15:11 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/282c86389114 6718964: Swing border tests should be open source Reviewed-by: peterz + test/javax/swing/border/Test4120351.java + test/javax/swing/border/Test4124729.java + test/javax/swing/border/Test4243289.html + test/javax/swing/border/Test4243289.java + test/javax/swing/border/Test4247606.html + test/javax/swing/border/Test4247606.java + test/javax/swing/border/Test4252164.html + test/javax/swing/border/Test4252164.java + test/javax/swing/border/Test6461042.java Changeset: 581440ba714a Author: malenkov Date: 2008-06-26 15:39 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/581440ba714a 6718965: Swing color chooser tests should be open source Reviewed-by: peterz + test/javax/swing/JColorChooser/Test4165217.java + test/javax/swing/JColorChooser/Test4177735.java + test/javax/swing/JColorChooser/Test4193384.java + test/javax/swing/JColorChooser/Test4234761.java + test/javax/swing/JColorChooser/Test4380468.html + test/javax/swing/JColorChooser/Test4380468.java + test/javax/swing/JColorChooser/Test4461329.java + test/javax/swing/JColorChooser/Test4711996.java + test/javax/swing/JColorChooser/Test4759306.html + test/javax/swing/JColorChooser/Test4759306.java + test/javax/swing/JColorChooser/Test4759934.html + test/javax/swing/JColorChooser/Test4759934.java + test/javax/swing/JColorChooser/Test4887836.html + test/javax/swing/JColorChooser/Test4887836.java Changeset: 13586ebcd761 Author: mlapshin Date: 2008-07-02 18:17 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/13586ebcd761 6618401: Input method cannot be selected from System menu Summary: lock.wait() added in sun.awt.im.InputMethodManager.showInputMethodMenuOnRequesterEDT() Reviewed-by: alexp ! src/share/classes/sun/awt/im/InputMethodManager.java Changeset: 99ea868a1d31 Author: mlapshin Date: 2008-07-07 16:56 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/99ea868a1d31 6647340: Minimized JInternalFrame icons appear in incorrect positions if the main frame is resized Summary: Now BasicInternalFrameUI and BasicDesktopIconUI both recalculate frame icon position Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java + src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java + test/javax/swing/JInternalFrame/6647340/bug6647340.java Changeset: 34b312e8344b Author: peterz Date: 2008-07-08 11:36 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/34b312e8344b 6635663: make/tools/AutoMulti/{AutoMulti,TestALFGenerator}.java still generate files with wrong legal notices Summary: Removed unused files Reviewed-by: ohair ! make/tools/Makefile - make/tools/auto_multi/Makefile - make/tools/src/build/tools/automulti/AutoMulti.java - make/tools/src/build/tools/automulti/README.txt - make/tools/src/build/tools/automulti/TestALFGenerator.java - make/tools/src/build/tools/automulti/TestALFLookAndFeel.java Changeset: d5e658be14f7 Author: malenkov Date: 2008-07-08 16:40 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d5e658be14f7 4916852: RFE: LTP: BorderLayout Persistence Delegate should use 1.5 API Reviewed-by: peterz, loneid ! src/share/classes/java/beans/MetaData.java + test/java/beans/XMLEncoder/java_awt_BorderLayout.java + test/java/beans/XMLEncoder/java_awt_Component.java Changeset: f98824b5fe08 Author: malenkov Date: 2008-07-09 15:25 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f98824b5fe08 6351692: catch(Throwable) in java.beans.MetaData preventing thread shutdown Reviewed-by: peterz, loneid ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventHandler.java Changeset: ccdfb79c9864 Author: malenkov Date: 2008-07-09 19:29 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ccdfb79c9864 4994637: LTP: java.beans.java_util_Map_PersistenceDelegate: ConcurrentModificationException Reviewed-by: peterz, loneid ! src/share/classes/java/beans/MetaData.java + test/java/beans/XMLEncoder/Test4994637.java ! test/java/beans/XMLEncoder/java_util_HashMap.java Changeset: f7585c3756ee Author: malenkov Date: 2008-07-18 18:26 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f7585c3756ee 6552812: Add HSL tab to JColorChooser Reviewed-by: peterz, avu ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/javax/swing/colorchooser/ColorChooserComponentFactory.java + src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java + src/share/classes/javax/swing/colorchooser/ColorModel.java + src/share/classes/javax/swing/colorchooser/ColorModelCMYK.java + src/share/classes/javax/swing/colorchooser/ColorModelHSL.java + src/share/classes/javax/swing/colorchooser/ColorModelHSV.java + src/share/classes/javax/swing/colorchooser/ColorPanel.java - src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java - src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java + src/share/classes/javax/swing/colorchooser/DiagramComponent.java + src/share/classes/javax/swing/colorchooser/SlidingSpinner.java - src/share/classes/javax/swing/colorchooser/SyntheticImage.java + src/share/classes/javax/swing/colorchooser/ValueFormatter.java ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java ! test/javax/swing/JColorChooser/Test6524757.java + test/javax/swing/JColorChooser/Test6559154.java Changeset: fdbc0517be43 Author: idk Date: 2008-07-21 10:21 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/fdbc0517be43 6668281: NullPointerException in DefaultTableCellHeaderRenderer.getColumnSortOrder() Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java Changeset: 8b59beb64ee9 Author: mlapshin Date: 2008-07-21 19:58 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8b59beb64ee9 6607130: REGRESSION: JComboBox cell editor isn't hidden if the same value is selected with keyboard Summary: JComboBox cell editor now hides if the same value is selected with keyboard Reviewed-by: peterz, alexp ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java + test/javax/swing/JComboBox/6607130/bug6607130.java Changeset: e4d87f3c8858 Author: mlapshin Date: 2008-07-24 14:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e4d87f3c8858 6725409: Unable to localize JInternalFrame system menu during run-time Summary: Use of the static final constants replaced by direct calls of UIManager.getString(). Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java + test/javax/swing/JInternalFrame/6725409/bug6725409.java Changeset: ef591cd4c463 Author: malenkov Date: 2008-07-24 14:51 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ef591cd4c463 4778988: CompoundBorder.isBorderOpaque() has incorrect documentation. Reviewed-by: peterz, rupashka ! src/share/classes/javax/swing/border/CompoundBorder.java Changeset: b334982cdefe Author: rupashka Date: 2008-07-24 16:43 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b334982cdefe 6722802: Code improvement and warnings removing from the javax.swing.text package Summary: Removed unnecessary castings and other warnings Reviewed-by: peterz Contributed-by: Florian Brunner ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/ComponentView.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/ElementIterator.java ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/LayoutQueue.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/SegmentCache.java ! src/share/classes/javax/swing/text/SimpleAttributeSet.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/TextAction.java ! src/share/classes/javax/swing/text/TextLayoutStrategy.java ! src/share/classes/javax/swing/text/ZoneView.java ! src/share/classes/javax/swing/text/html/AccessibleHTML.java ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/HTML.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/HTMLWriter.java ! src/share/classes/javax/swing/text/html/Map.java ! src/share/classes/javax/swing/text/html/MinimalHTMLWriter.java ! src/share/classes/javax/swing/text/html/OptionListModel.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/TableView.java ! src/share/classes/javax/swing/text/html/parser/AttributeList.java ! src/share/classes/javax/swing/text/html/parser/DTD.java ! src/share/classes/javax/swing/text/html/parser/Element.java ! src/share/classes/javax/swing/text/html/parser/Entity.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/text/html/parser/TagStack.java ! src/share/classes/javax/swing/text/rtf/MockAttributeSet.java ! src/share/classes/javax/swing/text/rtf/RTFAttributes.java ! src/share/classes/javax/swing/text/rtf/RTFGenerator.java ! src/share/classes/javax/swing/text/rtf/RTFParser.java ! src/share/classes/javax/swing/text/rtf/RTFReader.java Changeset: 91722ce41508 Author: malenkov Date: 2008-07-24 17:30 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/91722ce41508 6707406: BasicColorChooserUI tests throw NPE while getColorSelectionModel if isPropertyChanged() returns true Reviewed-by: peterz, rupashka ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java + test/javax/swing/JColorChooser/Test6707406.java Changeset: a2266940ae33 Author: mlapshin Date: 2008-07-25 14:14 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a2266940ae33 6727829: BasicLabelUI rendering fails if multiple AppContexts exist in same java JVM Summary: Several private static variables made local Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicLabelUI.java Changeset: 85f6a6d7d812 Author: rupashka Date: 2008-07-25 17:50 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/85f6a6d7d812 6727661: Code improvement and warnings removing from the swing/plaf packages Summary: Removed unnecessary castings and other warnings Reviewed-by: alexp Contributed-by: Florian Brunner ! src/share/classes/com/sun/java/swing/plaf/windows/DesktopProperty.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsScrollBarUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java ! src/share/classes/javax/swing/plaf/basic/BasicButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java ! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicRadioButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToggleButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/plaf/basic/DragRecognitionSupport.java ! src/share/classes/javax/swing/plaf/basic/LazyActionMap.java ! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/share/classes/javax/swing/plaf/metal/MetalBumps.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalIconFactory.java ! src/share/classes/javax/swing/plaf/metal/MetalInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalRadioButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/DefaultSynthStyleFactory.java ! src/share/classes/javax/swing/plaf/synth/ImagePainter.java ! src/share/classes/javax/swing/plaf/synth/Region.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthContext.java ! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthStyle.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: 86b43f44bcc4 Author: idk Date: 2008-07-25 11:32 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/86b43f44bcc4 6608456: need API to define RepaintManager per components hierarchy Reviewed-by: alexp ! make/javax/swing/Makefile + src/share/classes/com/sun/java/swing/SwingUtilities3.java ! src/share/classes/javax/swing/RepaintManager.java + test/javax/swing/RepaintManager/6608456/bug6608456.java Changeset: 1c4449ef03ce Author: malenkov Date: 2008-07-25 21:00 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1c4449ef03ce 6630275: The spec on VetoableChangeSupport.fireVetoableChange should be updated Reviewed-by: peterz, rupashka ! src/share/classes/java/beans/PropertyChangeSupport.java ! src/share/classes/java/beans/VetoableChangeSupport.java + test/java/beans/VetoableChangeSupport/Test6630275.java Changeset: 619874c5989f Author: idk Date: 2008-07-25 14:13 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/619874c5989f 6638195: need API for EventQueueDelegate Reviewed-by: bchristi ! src/share/classes/com/sun/java/swing/SwingUtilities3.java ! src/share/classes/java/awt/EventDispatchThread.java + src/share/classes/sun/awt/EventQueueDelegate.java + test/java/awt/EventQueue/6638195/bug6638195.java Changeset: 59940b984f90 Author: idk Date: 2008-07-25 14:26 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/59940b984f90 6699328: NullPointerException in EventQueue.dispatchEvent when applet is closed, only reprise/scenario applet Reviewed-by: bchristi ! src/share/classes/com/sun/java/swing/SwingUtilities3.java ! src/share/classes/sun/awt/EventQueueDelegate.java Changeset: 7d45141e5d30 Author: mlapshin Date: 2008-08-08 20:49 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7d45141e5d30 6584657: GTK Look and Feel: Bugs in menu item layout Reviewed-by: peterz, alexp ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/share/classes/javax/swing/plaf/basic/DefaultMenuLayout.java ! src/share/classes/javax/swing/plaf/synth/DefaultMenuLayout.java ! src/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java + src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java + src/share/classes/sun/swing/MenuItemLayoutHelper.java Changeset: 3f7b2ea2d611 Author: rupashka Date: 2008-08-11 16:39 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3f7b2ea2d611 6604281: NimbusL&F :Regression in Focus traversal in JFileChooser in pit build. Summary: Fixed calculation of preferred size in SynthButtonUI Reviewed-by: loneid, peterz ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java + test/javax/swing/JButton/6604281/bug6604281.java Changeset: 5504518c0d1d Author: mlapshin Date: 2008-08-11 16:49 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/5504518c0d1d 6579243: Windows, GTK: Internal frame title is drawn wrong if the frame has RTL orientation Summary: Added right-to-left code branches to WindowsInternalFrameTitlePane and Metacity classes Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java Changeset: b5b7ec629a50 Author: mlapshin Date: 2008-08-12 12:52 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b5b7ec629a50 6735918: test/closed/javax/swing/JMenuItem/6458123/bug6458123.java fails on Linux Summary: All the bearings-related code is removed from MenuItemLayoutHelper class Reviewed-by: alexp ! src/share/classes/sun/swing/MenuItemLayoutHelper.java Changeset: c9d407ab2309 Author: lana Date: 2008-08-12 17:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c9d407ab2309 Merge ! make/tools/Makefile - make/tools/auto_multi/Makefile - make/tools/src/build/tools/automulti/AutoMulti.java - make/tools/src/build/tools/automulti/README.txt - make/tools/src/build/tools/automulti/TestALFGenerator.java - make/tools/src/build/tools/automulti/TestALFLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java ! src/share/classes/java/beans/EventHandler.java - src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java - src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java - src/share/classes/javax/swing/colorchooser/SyntheticImage.java ! src/share/classes/javax/swing/plaf/basic/BasicButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java ! src/share/classes/javax/swing/plaf/metal/MetalIconFactory.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/html/AccessibleHTML.java ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/parser/AttributeList.java ! src/share/classes/javax/swing/text/html/parser/DTD.java ! src/share/classes/javax/swing/text/html/parser/Element.java ! src/share/classes/javax/swing/text/html/parser/Entity.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/text/rtf/RTFAttributes.java ! src/share/classes/javax/swing/text/rtf/RTFGenerator.java Changeset: e78c2f17a606 Author: mlapshin Date: 2008-08-26 12:16 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e78c2f17a606 6736649: test/closed/javax/swing/JMenuItem/6458123/ManualBug6458123.java fails on Linux Summary: Now text bearings are taken into account when labelRect width is calculated Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java ! src/share/classes/sun/swing/MenuItemLayoutHelper.java Changeset: 336877026f07 Author: rupashka Date: 2008-08-26 15:12 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/336877026f07 6727662: Code improvement and warnings removing from swing packages Summary: Removed unnecessary castings and other warnings Reviewed-by: malenkov ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/AbstractCellEditor.java ! src/share/classes/javax/swing/AbstractListModel.java ! src/share/classes/javax/swing/AbstractSpinnerModel.java ! src/share/classes/javax/swing/ActionMap.java ! src/share/classes/javax/swing/AncestorNotifier.java ! src/share/classes/javax/swing/ArrayTable.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/DebugGraphicsInfo.java ! src/share/classes/javax/swing/DefaultBoundedRangeModel.java ! src/share/classes/javax/swing/DefaultButtonModel.java ! src/share/classes/javax/swing/DefaultFocusManager.java ! src/share/classes/javax/swing/DefaultListSelectionModel.java ! src/share/classes/javax/swing/DefaultSingleSelectionModel.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/InputMap.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JProgressBar.java ! src/share/classes/javax/swing/JScrollBar.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/KeyboardManager.java ! src/share/classes/javax/swing/LayoutComparator.java ! src/share/classes/javax/swing/LayoutFocusTraversalPolicy.java ! src/share/classes/javax/swing/LegacyGlueFocusTraversalPolicy.java ! src/share/classes/javax/swing/MenuSelectionManager.java ! src/share/classes/javax/swing/MultiUIDefaults.java ! src/share/classes/javax/swing/PopupFactory.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/TimerQueue.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/filechooser/FileSystemView.java ! src/share/classes/javax/swing/table/AbstractTableModel.java ! src/share/classes/javax/swing/table/DefaultTableModel.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java ! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/javax/swing/undo/StateEdit.java ! src/share/classes/javax/swing/undo/UndoManager.java ! src/share/classes/javax/swing/undo/UndoableEditSupport.java ! src/share/classes/sun/swing/AccessibleMethod.java ! src/share/classes/sun/swing/FilePane.java ! src/share/classes/sun/swing/SwingLazyValue.java ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: 7a3fd5d65936 Author: rupashka Date: 2008-08-27 20:49 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7a3fd5d65936 6351074: JFileChooser removes leading space in filename Summary: Removed trimming of leading spaces in filename Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java Changeset: 85d71654a220 Author: rupashka Date: 2008-08-29 13:23 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/85d71654a220 6742490: JSlider tests are located in JFileChooser directory Summary: Tests were moved to appropriate folder Reviewed-by: peterz - test/javax/swing/JFileChooser/4252173/bug4252173.java - test/javax/swing/JFileChooser/6524424/bug6524424.html - test/javax/swing/JFileChooser/6524424/bug6524424.java + test/javax/swing/JSlider/4252173/bug4252173.java + test/javax/swing/JSlider/6524424/bug6524424.html + test/javax/swing/JSlider/6524424/bug6524424.java Changeset: 8c34b54ef09c Author: rupashka Date: 2008-08-29 18:58 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8c34b54ef09c 6742358: MetalSliderUI paint wrong vertical disabled filled JSlider for DefaultMetalTheme Summary: Corrected the method MetalSliderUI.paintTrack Reviewed-by: malenkov ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java + test/javax/swing/JSlider/6742358/bug6742358.html + test/javax/swing/JSlider/6742358/bug6742358.java Changeset: a4125097db18 Author: rupashka Date: 2008-08-30 17:29 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a4125097db18 6554743: JFileChooser dn't close after pressing escape key after changing the views Summary: Restore focus after changing the views in JFileChooser Reviewed-by: loneid ! src/share/classes/sun/swing/FilePane.java Changeset: 291feed36076 Author: peterz Date: 2008-09-01 15:21 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/291feed36076 5062055: JEditorPane HTML: HR-tag with attribute size=1px causes NumberFormatException Summary: Wrapped parseInt() with try/catch Reviewed-by: gsm ! src/share/classes/javax/swing/text/html/HRuleView.java + test/javax/swing/text/html/HRuleView/Test5062055.java Changeset: 71df74bef5ba Author: malenkov Date: 2008-09-01 17:36 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/71df74bef5ba 5026703: RFE: DOC: Are PropertyChangeSupport & VetoableChangeSupport Thread-Safe? --Docs Should Say Reviewed-by: peterz, rupashka ! src/share/classes/java/beans/PropertyChangeSupport.java ! src/share/classes/java/beans/VetoableChangeSupport.java Changeset: 9765266e5aea Author: malenkov Date: 2008-09-03 21:00 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9765266e5aea 6397609: DOC: De-register API required for PropertyEditorManager and/or doc change Reviewed-by: peterz, rupashka + src/share/classes/com/sun/beans/WeakCache.java ! src/share/classes/java/beans/PropertyEditorManager.java + test/java/beans/PropertyEditor/MemoryClassLoader.java + test/java/beans/PropertyEditor/Test6397609.java ! test/java/beans/PropertyEditor/TestEditor.java Changeset: 2055acc62a85 Author: rupashka Date: 2008-09-04 15:15 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2055acc62a85 6278700: JSlider created with BoundedRangeModel fires twice when changed Summary: Removed second registration of listener Reviewed-by: peterz ! src/share/classes/javax/swing/JSlider.java + test/javax/swing/JSlider/6278700/bug6278700.java Changeset: 77dc7ca7879f Author: peytoia Date: 2008-09-08 10:44 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/77dc7ca7879f 6665028: native code of method j*.text.Bidi.nativeBidiChars is using the contents of a primitive array direct Reviewed-by: okutsu ! src/share/native/sun/font/bidi/ubidi.c + test/java/text/Bidi/Bug6665028.java Changeset: 3d8640f597b2 Author: peytoia Date: 2008-09-08 11:49 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3d8640f597b2 6607310: InputContext may cause loading of swing classes even for non-Swing applets Reviewed-by: okutsu ! src/share/classes/sun/awt/im/CompositionArea.java ! src/share/classes/sun/awt/im/InputContext.java Changeset: 9b8e20a3c5f0 Author: peytoia Date: 2008-09-08 13:31 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9b8e20a3c5f0 6645292: [Fmt-Da] Timezone Western Summer Time (Australia) is parsed incorrectly Reviewed-by: okutsu ! src/share/classes/java/text/SimpleDateFormat.java + test/java/text/Format/DateFormat/Bug6645292.java Changeset: 1b0b3a777a6c Author: peytoia Date: 2008-09-08 14:31 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1b0b3a777a6c 4823811: [Fmt-Da] SimpleDateFormat patterns don't allow embedding of some literal punctuation Reviewed-by: okutsu ! src/share/classes/java/text/SimpleDateFormat.java + test/java/text/Format/DateFormat/Bug4823811.java Changeset: 21346d9b372a Author: peytoia Date: 2008-09-08 14:48 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/21346d9b372a 6650748: (tz) Java runtime doesn't detect VET time zone correctly on Windows Reviewed-by: okutsu ! src/windows/lib/tzmappings Changeset: 67c41d740e6d Author: peytoia Date: 2008-09-08 15:21 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/67c41d740e6d 6466476: (tz) Introduction of tzdata2005r can introduce incompatility issues with some JDK1.1 3-letter TZ Ids Reviewed-by: okutsu ! make/java/java/FILES_java.gmk + src/share/classes/sun/util/calendar/TzIDOldMapping.java ! src/share/classes/sun/util/calendar/ZoneInfo.java + test/java/util/TimeZone/OldIDMappingTest.java + test/java/util/TimeZone/OldIDMappingTest.sh Changeset: 66b0b1231530 Author: peytoia Date: 2008-09-08 17:35 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/66b0b1231530 6730743: (tz) Support tzdata2008e Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 32fb1f4f40b8 Author: rupashka Date: 2008-09-10 19:16 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/32fb1f4f40b8 6587742: filling half of a JSlider's track is no longer optional Summary: now OceanTheme uses the JSlider.isFilled property like other themes Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java + test/javax/swing/JSlider/6587742/bug6587742.html + test/javax/swing/JSlider/6587742/bug6587742.java Changeset: af375b98f9b3 Author: lana Date: 2008-09-24 08:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/af375b98f9b3 Merge ! make/java/java/FILES_java.gmk - make/tools/auto_multi/Makefile - make/tools/src/build/tools/automulti/AutoMulti.java - make/tools/src/build/tools/automulti/README.txt - make/tools/src/build/tools/automulti/TestALFGenerator.java - make/tools/src/build/tools/automulti/TestALFLookAndFeel.java - src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java - src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java - src/share/classes/javax/swing/colorchooser/SyntheticImage.java - test/javax/swing/JFileChooser/4252173/bug4252173.java - test/javax/swing/JFileChooser/6524424/bug6524424.html - test/javax/swing/JFileChooser/6524424/bug6524424.java Changeset: fac669fa0f24 Author: lana Date: 2008-10-13 17:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/fac669fa0f24 Merge ! make/java/java/FILES_java.gmk - make/tools/auto_multi/Makefile - make/tools/src/build/tools/automulti/AutoMulti.java - make/tools/src/build/tools/automulti/README.txt - make/tools/src/build/tools/automulti/TestALFGenerator.java - make/tools/src/build/tools/automulti/TestALFLookAndFeel.java - src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java - src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java - src/share/classes/javax/swing/colorchooser/SyntheticImage.java - test/javax/swing/JFileChooser/4252173/bug4252173.java - test/javax/swing/JFileChooser/6524424/bug6524424.html - test/javax/swing/JFileChooser/6524424/bug6524424.java Changeset: 025fdbd9090b Author: chegar Date: 2008-09-24 05:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/025fdbd9090b 6749308: java.io, java.lang, java.util exception classes don't specify serialVersionUID Reviewed-by: alanb ! src/share/classes/java/io/CharConversionException.java ! src/share/classes/java/io/EOFException.java ! src/share/classes/java/io/FileNotFoundException.java ! src/share/classes/java/io/InterruptedIOException.java ! src/share/classes/java/io/SyncFailedException.java ! src/share/classes/java/io/UTFDataFormatException.java ! src/share/classes/java/io/UnsupportedEncodingException.java ! src/share/classes/java/lang/AbstractMethodError.java ! src/share/classes/java/lang/ArithmeticException.java ! src/share/classes/java/lang/ArrayIndexOutOfBoundsException.java ! src/share/classes/java/lang/ArrayStoreException.java ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/lang/ClassCastException.java ! src/share/classes/java/lang/ClassCircularityError.java ! src/share/classes/java/lang/ClassFormatError.java ! src/share/classes/java/lang/CloneNotSupportedException.java ! src/share/classes/java/lang/EnumConstantNotPresentException.java ! src/share/classes/java/lang/IllegalAccessError.java ! src/share/classes/java/lang/IllegalAccessException.java ! src/share/classes/java/lang/IllegalMonitorStateException.java ! src/share/classes/java/lang/IllegalThreadStateException.java ! src/share/classes/java/lang/IncompatibleClassChangeError.java ! src/share/classes/java/lang/IndexOutOfBoundsException.java ! src/share/classes/java/lang/InstantiationError.java ! src/share/classes/java/lang/InstantiationException.java ! src/share/classes/java/lang/InternalError.java ! src/share/classes/java/lang/InterruptedException.java ! src/share/classes/java/lang/LinkageError.java ! src/share/classes/java/lang/NegativeArraySizeException.java ! src/share/classes/java/lang/NoClassDefFoundError.java ! src/share/classes/java/lang/NoSuchFieldError.java ! src/share/classes/java/lang/NoSuchFieldException.java ! src/share/classes/java/lang/NoSuchMethodError.java ! src/share/classes/java/lang/NoSuchMethodException.java ! src/share/classes/java/lang/NullPointerException.java ! src/share/classes/java/lang/OutOfMemoryError.java ! src/share/classes/java/lang/StackOverflowError.java ! src/share/classes/java/lang/StringIndexOutOfBoundsException.java ! src/share/classes/java/lang/ThreadDeath.java ! src/share/classes/java/lang/TypeNotPresentException.java ! src/share/classes/java/lang/UnknownError.java ! src/share/classes/java/lang/UnsatisfiedLinkError.java ! src/share/classes/java/lang/UnsupportedClassVersionError.java ! src/share/classes/java/lang/VerifyError.java ! src/share/classes/java/lang/annotation/AnnotationFormatError.java ! src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java ! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java ! src/share/classes/java/lang/instrument/IllegalClassFormatException.java ! src/share/classes/java/lang/instrument/UnmodifiableClassException.java ! src/share/classes/java/lang/management/ManagementPermission.java ! src/share/classes/java/lang/reflect/GenericSignatureFormatError.java ! src/share/classes/java/lang/reflect/MalformedParameterizedTypeException.java ! src/share/classes/java/util/ConcurrentModificationException.java ! src/share/classes/java/util/EmptyStackException.java ! src/share/classes/java/util/InputMismatchException.java ! src/share/classes/java/util/NoSuchElementException.java ! src/share/classes/java/util/TooManyListenersException.java ! src/share/classes/java/util/jar/JarException.java ! src/share/classes/java/util/regex/PatternSyntaxException.java ! src/share/classes/java/util/zip/DataFormatException.java ! src/share/classes/java/util/zip/ZipException.java Changeset: 76fc6d885969 Author: chegar Date: 2008-09-24 05:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/76fc6d885969 Merge Changeset: 48a790c67659 Author: emcmanus Date: 2008-09-24 15:19 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/48a790c67659 6750935: The expected NotCompliantMBeanException is not thrown for the custom MXBeanMappingFactory 6751872: MXBeanMappingFactory example says "implements" when it should be "extends" Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanSupport.java ! src/share/classes/javax/management/openmbean/MXBeanMappingFactory.java ! test/javax/management/mxbean/CustomTypeTest.java Changeset: e2c416af20bd Author: ksrini Date: 2008-09-24 15:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e2c416af20bd 6742159: (launcher) improve the java launching mechanism Summary: improves launching, also addresses 6694671 and 6749732 Reviewed-by: darcy, dholmes ! src/share/bin/emessages.h ! src/share/bin/java.c ! src/share/bin/java.h - src/share/classes/sun/launcher/LauncherHelp.java + src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/solaris/bin/java_md.c ! src/windows/bin/java_md.c ! test/tools/launcher/Arrrghs.java - test/tools/launcher/Arrrghs.sh + test/tools/launcher/TestHelper.java Changeset: b3234ba261fa Author: tbell Date: 2008-09-29 22:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b3234ba261fa Merge - src/share/classes/sun/launcher/LauncherHelp.java - test/tools/launcher/Arrrghs.sh Changeset: a16f1d0cbff3 Author: tbell Date: 2008-10-04 22:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a16f1d0cbff3 Merge Changeset: c272f261ad10 Author: jjh Date: 2008-10-02 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c272f261ad10 6751643: ThreadReference.ownedMonitors() can return null Summary: Make a local copy of the cache so it doesn't get modified by a racy resume Reviewed-by: dcubed, swamyv ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java + test/com/sun/jdi/SimulResumerTest.java Changeset: faa3673d7624 Author: mchung Date: 2008-10-02 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/faa3673d7624 6581243: Service Tag and Product Registration Support in JDK 7 Summary: Include service tag creation and product registration support in JDK Reviewed-by: ksrini ! make/com/sun/Makefile + make/com/sun/servicetag/Makefile + src/share/classes/com/sun/servicetag/BrowserSupport.java + src/share/classes/com/sun/servicetag/Installer.java + src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java + src/share/classes/com/sun/servicetag/RegistrationData.java + src/share/classes/com/sun/servicetag/RegistrationDocument.java + src/share/classes/com/sun/servicetag/Registry.java + src/share/classes/com/sun/servicetag/ServiceTag.java + src/share/classes/com/sun/servicetag/SolarisServiceTag.java + src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java + src/share/classes/com/sun/servicetag/SunConnection.java + src/share/classes/com/sun/servicetag/SystemEnvironment.java + src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java + src/share/classes/com/sun/servicetag/Util.java + src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java + src/share/classes/com/sun/servicetag/package.html + src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt + src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties + src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties + src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties + src/share/classes/com/sun/servicetag/resources/jdk_header.png + src/share/classes/com/sun/servicetag/resources/product_registration.xsd + src/share/classes/com/sun/servicetag/resources/register.html + src/share/classes/com/sun/servicetag/resources/register_ja.html + src/share/classes/com/sun/servicetag/resources/register_zh_CN.html + test/com/sun/servicetag/DeleteServiceTag.java + test/com/sun/servicetag/DuplicateNotFound.java + test/com/sun/servicetag/FindServiceTags.java + test/com/sun/servicetag/InstanceUrnCheck.java + test/com/sun/servicetag/InvalidRegistrationData.java + test/com/sun/servicetag/InvalidServiceTag.java + test/com/sun/servicetag/JavaServiceTagTest.java + test/com/sun/servicetag/JavaServiceTagTest1.java + test/com/sun/servicetag/NewRegistrationData.java + test/com/sun/servicetag/SvcTagClient.java + test/com/sun/servicetag/SystemRegistryTest.java + test/com/sun/servicetag/TestLoadFromXML.java + test/com/sun/servicetag/UpdateServiceTagTest.java + test/com/sun/servicetag/Util.java + test/com/sun/servicetag/ValidRegistrationData.java + test/com/sun/servicetag/environ.properties + test/com/sun/servicetag/missing-environ-field.xml + test/com/sun/servicetag/newer-registry-version.xml + test/com/sun/servicetag/registration.xml + test/com/sun/servicetag/servicetag1.properties + test/com/sun/servicetag/servicetag2.properties + test/com/sun/servicetag/servicetag3.properties + test/com/sun/servicetag/servicetag4.properties + test/com/sun/servicetag/servicetag5.properties Changeset: d74db4a9799a Author: mchung Date: 2008-10-03 09:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d74db4a9799a Merge Changeset: 906b5be0eca5 Author: ksrini Date: 2008-10-01 09:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/906b5be0eca5 4459600: java -jar fails to run Main-Class if classname followed by whitespace. Summary: Fixed whitespace trimming in the manifest as well as post review comments on CR: 6742159 Reviewed-by: darcy, dholmes ! src/share/classes/sun/launcher/LauncherHelper.java ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: 8e14a7bd6753 Author: tbell Date: 2008-10-04 22:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8e14a7bd6753 Merge ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java Changeset: e7f373751c6b Author: ksrini Date: 2008-10-05 18:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e7f373751c6b 6755847: (launcher) will trigger assertions in debug build Summary: Adds a temporary counter measure to to prevent assertions CR: 6755845 Reviewed-by: darcy, dholmes ! src/share/bin/java.h ! src/solaris/bin/java_md.c ! src/windows/bin/java_md.c Changeset: c7fae5013939 Author: michaelm Date: 2008-09-19 13:32 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c7fae5013939 6750364: Error in test for 6744329 Reviewed-by: chegar ! test/com/sun/net/httpserver/bugs/B6744329.java Changeset: e57447118235 Author: michaelm Date: 2008-09-19 14:03 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e57447118235 Merge Changeset: c54ce70a3668 Author: chegar Date: 2008-09-19 15:14 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c54ce70a3668 6746836: java.net exception classes don't specify serialVersionUID Reviewed-by: alanb, jccollet ! make/sun/net/spi/Makefile ! make/sun/net/spi/nameservice/Makefile ! make/sun/net/spi/nameservice/dns/Makefile ! src/share/classes/java/net/BindException.java ! src/share/classes/java/net/ConnectException.java ! src/share/classes/java/net/HttpRetryException.java ! src/share/classes/java/net/MalformedURLException.java ! src/share/classes/java/net/NoRouteToHostException.java ! src/share/classes/java/net/PortUnreachableException.java ! src/share/classes/java/net/ProtocolException.java ! src/share/classes/java/net/SocketException.java ! src/share/classes/java/net/SocketTimeoutException.java ! src/share/classes/java/net/URISyntaxException.java ! src/share/classes/java/net/UnknownHostException.java ! src/share/classes/java/net/UnknownServiceException.java ! src/share/classes/sun/net/ConnectionResetException.java ! src/share/classes/sun/net/ProgressEvent.java ! src/share/classes/sun/net/TelnetProtocolException.java ! src/share/classes/sun/net/ftp/FtpLoginException.java ! src/share/classes/sun/net/ftp/FtpProtocolException.java ! src/share/classes/sun/net/httpserver/HttpError.java ! src/share/classes/sun/net/httpserver/StreamClosedException.java ! src/share/classes/sun/net/smtp/SmtpProtocolException.java ! src/share/classes/sun/net/www/ApplicationLaunchException.java ! src/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java ! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: abf3e1aa8031 Author: michaelm Date: 2008-09-22 15:53 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/abf3e1aa8031 6739920: java 6u4~ use larger C heap if there are many threads Reviewed-by: chegar ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/solaris/native/java/net/PlainSocketImpl.c Changeset: 976c7eb88476 Author: michaelm Date: 2008-09-22 16:05 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/976c7eb88476 Merge Changeset: 74fc78477907 Author: mullan Date: 2008-09-22 10:43 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/74fc78477907 6469266: Integrate Apache XMLSec 1.4.2 into JDK 7 Reviewed-by: valeriep ! src/share/classes/com/sun/org/apache/xml/internal/security/Init.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/Algorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/JCEMapper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/MessageDigestAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithmSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java + src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizationException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/InvalidCanonicalizerException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/AttrCompare.java + src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java + src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_OmitComments.java + src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/NameSpaceSymbTable.java + src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/UtfHelpper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/ContentHandlerAlreadyRegisteredException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyInfoContent.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyName.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/MgmtData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/PGPData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/RetrievalMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/SPKIData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/X509Data.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/DSAKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/KeyValueContent.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/RSAKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509CRL.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509Certificate.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509DataContent.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509IssuerSerial.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SubjectName.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/InvalidKeyResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/DSAKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/EncryptedKeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RSAKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509CertificateResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509IssuerSerialResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509SKIResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509SubjectNameResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/KeyStoreResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/SingleCertificateResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.dtd ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.xml ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/schema/etsi.xsd ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/schema/xmldsig-core-schema.dtd ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/schema/xmldsig-core-schema.xsd ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_en.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/InvalidDigestValueException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/InvalidSignatureValueException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/MissingResourceFailureException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/NodeFilter.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/ObjectContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/ReferenceNotInitializedException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperties.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperty.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignedInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInputDebugger.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/InvalidTransformException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformParam.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformationException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transforms.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformBase64Decode.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N.java + src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N11.java + src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N11_WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NExclusive.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NExclusiveWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformEnvelopedSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPointer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXSLT.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPath2FilterContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPath2FilterContainer04.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPathFilterCHGPContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Constants.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/DigesterOutputStream.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementChecker.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementCheckerImpl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionConstants.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/HelperNodeList.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/I18n.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/SignatureElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/SignerOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncBufferedOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncByteArrayOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverAnonymous.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverFragment.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverLocalFilesystem.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverXPointer.java ! src/share/classes/org/jcp/xml/dsig/internal/DigesterOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/MacOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/SignerOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMBase64Transform.java + src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14N11Method.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java - src/share/classes/org/jcp/xml/dsig/internal/package.html ! test/javax/xml/crypto/dsig/GenerationTests.java Changeset: 81de7c8225c3 Author: mullan Date: 2008-09-22 11:26 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/81de7c8225c3 Merge - src/share/classes/org/jcp/xml/dsig/internal/package.html Changeset: de7864ec310c Author: chegar Date: 2008-09-24 17:10 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/de7864ec310c 6621697: Problem with file test/sun/net/www/http/ChunkedInputStream/test.txt Reviewed-by: michaelm ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingTest.java - test/sun/net/www/http/ChunkedInputStream/test.txt Changeset: 8b0be0bc4b14 Author: chegar Date: 2008-09-26 11:24 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8b0be0bc4b14 6752807: java.net test ADatagramSocket.sh is broken Summary: update bootclasspath set by test to simply prepend TESTCLASSES Reviewed-by: michaelm ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh Changeset: 2f38da01dcf4 Author: wetmore Date: 2008-10-06 09:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2f38da01dcf4 Merge ! make/sun/net/spi/nameservice/dns/Makefile - src/share/classes/org/jcp/xml/dsig/internal/package.html ! test/com/sun/net/httpserver/bugs/B6744329.java - test/sun/net/www/http/ChunkedInputStream/test.txt Changeset: bd208584e8af Author: tbell Date: 2008-10-10 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/bd208584e8af Merge Changeset: cfbc79081769 Author: ksrini Date: 2008-10-14 13:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/cfbc79081769 6758881: (launcher) needs to throw NoClassDefFoundError instead of JavaRuntimeException Summary: The launcher will throw the Error vs. Exception, also fixed some minor issues with the tests. Reviewed-by: darcy ! src/share/classes/sun/launcher/LauncherHelper.java ! test/tools/launcher/Arrrghs.java Changeset: cc5f810b5af8 Author: tbell Date: 2008-10-17 08:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/cc5f810b5af8 Merge - make/tools/auto_multi/Makefile - make/tools/src/build/tools/automulti/AutoMulti.java - make/tools/src/build/tools/automulti/README.txt - make/tools/src/build/tools/automulti/TestALFGenerator.java - make/tools/src/build/tools/automulti/TestALFLookAndFeel.java - src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java - src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java - src/share/classes/javax/swing/colorchooser/SyntheticImage.java - test/javax/swing/JFileChooser/4252173/bug4252173.java - test/javax/swing/JFileChooser/6524424/bug6524424.html - test/javax/swing/JFileChooser/6524424/bug6524424.java Changeset: dcd40f60ffd3 Author: xdono Date: 2008-10-23 10:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/dcd40f60ffd3 Added tag jdk7-b38 for changeset cc5f810b5af8 ! .hgtags From john.coomes at sun.com Fri Oct 24 05:50:32 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 24 Oct 2008 05:50:32 +0000 Subject: hg: jdk7/hotspot-gc/langtools: 13 new changesets Message-ID: <20081024055054.0056BDA70@hg.openjdk.java.net> Changeset: 1e83972f53fb Author: jjg Date: 2008-09-23 10:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/1e83972f53fb 6420151: need to improve byfile compile policy to eliminate footprint issues Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/comp/Todo.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javadoc/JavadocTodo.java ! src/share/classes/javax/tools/FileObject.java ! test/tools/javac/6734819/T6734819b.out - test/tools/javac/policy/A.java - test/tools/javac/policy/B.java - test/tools/javac/policy/C.java - test/tools/javac/policy/D.java - test/tools/javac/policy/Test.java - test/tools/javac/policy/byfile.ABD.out - test/tools/javac/policy/byfile.ACD.out - test/tools/javac/policy/bytodo.ABD.out - test/tools/javac/policy/bytodo.ACD.out - test/tools/javac/policy/simple.ABD.out - test/tools/javac/policy/simple.ACD.out + test/tools/javac/policy/test1/A.java + test/tools/javac/policy/test1/B.java + test/tools/javac/policy/test1/C.java + test/tools/javac/policy/test1/D.java + test/tools/javac/policy/test1/Test1a.java + test/tools/javac/policy/test1/Test1b.java + test/tools/javac/policy/test1/byfile.ABD.out + test/tools/javac/policy/test1/byfile.ACD.out + test/tools/javac/policy/test1/bytodo.ABD.out + test/tools/javac/policy/test1/bytodo.ACD.out + test/tools/javac/policy/test1/simple.ABD.out + test/tools/javac/policy/test1/simple.ACD.out + test/tools/javac/policy/test2/A.java + test/tools/javac/policy/test2/B.java + test/tools/javac/policy/test2/Test.java + test/tools/javac/policy/test2/byfile.AB.out + test/tools/javac/policy/test2/byfile.BA.out + test/tools/javac/policy/test2/bytodo.AB.out + test/tools/javac/policy/test2/bytodo.BA.out Changeset: ddd110646d21 Author: mcimadamore Date: 2008-09-29 11:34 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/ddd110646d21 6500343: compiler generates bad code when translating conditional expressions Summary: TransTypes needs to deal with intersection types coming from conditional expressions Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/conditional/6500343/T6500343a.java + test/tools/javac/conditional/6500343/T6500343b.java Changeset: 609fb59657b4 Author: mcimadamore Date: 2008-09-29 11:48 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/609fb59657b4 6735840: Need a type/symbol visitor printer Summary: Added type/symbol visitor printer with support for localization Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: 1a9276e7cb18 Author: mcimadamore Date: 2008-09-29 12:00 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/1a9276e7cb18 6747671: -Xlint:rawtypes Summary: add an Xlint option for detecting all raw types usages (ccc-approved) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6304921/T6304921.out + test/tools/javac/warnings/6747671/T6747671.java + test/tools/javac/warnings/6747671/T6747671.out ! test/tools/javac/warnings/Unchecked.lintAll.out Changeset: 0c4fa115f87d Author: mcimadamore Date: 2008-09-29 15:30 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/0c4fa115f87d 6753718: raw type warnings should be suprresed during a langtools build Summary: fixed build.properties in order to suppress raw type warnings Reviewed-by: jjg ! make/build.properties Changeset: b81a9aa785ba Author: martin Date: 2008-09-29 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/b81a9aa785ba 6739427: -Xlint:processing not recognized as an option Reviewed-by: darcy, jjg Contributed-by: lipeng at google.com ! src/share/classes/com/sun/tools/javac/code/Lint.java Changeset: 4ef127d365dd Author: tbell Date: 2008-09-29 22:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/4ef127d365dd Merge - test/tools/javac/policy/A.java - test/tools/javac/policy/B.java - test/tools/javac/policy/C.java - test/tools/javac/policy/D.java - test/tools/javac/policy/Test.java - test/tools/javac/policy/byfile.ABD.out - test/tools/javac/policy/byfile.ACD.out - test/tools/javac/policy/bytodo.ABD.out - test/tools/javac/policy/bytodo.ACD.out - test/tools/javac/policy/simple.ABD.out - test/tools/javac/policy/simple.ACD.out Changeset: 8e56394f54f5 Author: tbell Date: 2008-10-04 22:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/8e56394f54f5 Merge Changeset: d593587c5938 Author: jjg Date: 2008-10-01 16:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/d593587c5938 6748601: javadoc API should allow varargs use Reviewed-by: bpatel ! src/share/classes/com/sun/tools/javadoc/Main.java ! src/share/classes/com/sun/tools/javadoc/Start.java Changeset: 539eb80f2a1a Author: tbell Date: 2008-10-04 22:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/539eb80f2a1a Merge Changeset: 944790f83b57 Author: jjg Date: 2008-10-06 16:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/944790f83b57 6748546: javadoc API should be classloader-friendly Reviewed-by: bpatel ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/Main.java ! src/share/classes/com/sun/tools/javadoc/Start.java Changeset: 3fd42dfa6f27 Author: tbell Date: 2008-10-10 13:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/3fd42dfa6f27 Merge Changeset: c7315642fa1b Author: xdono Date: 2008-10-23 10:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/c7315642fa1b Added tag jdk7-b38 for changeset 3fd42dfa6f27 ! .hgtags From shane.cox at gmail.com Fri Oct 24 20:16:25 2008 From: shane.cox at gmail.com (Shane Cox) Date: Fri, 24 Oct 2008 16:16:25 -0400 Subject: does CMS collector ever compact? Message-ID: Periodically our application encounters promotion failures when running the CMS collector, presumably due to a fragmented Tenured space. Once the first failure occurs, we tend to see subsequent failures at lower occupancies of Tenured space. For example, the first promotion failure might occur when Tenured is 70% full, the next 68%, then 65%, ... you get the picture. So my question is whether a compaction will ever be performed to resolve the fragmentation? I'm not a programmer, but I see comments in concurrentMarkSweepGeneration.cpp that lead me to believe that a compact would happen if UseCMSCompactAtFullCollection is set to TRUE and the threshold set by CMSFullGCsBeforeCompaction has been exceeded. However, since the defaults are TRUE and 0 respectively, I would think that the first Full GC triggered by a promotion failure would perform a compact. Apparently I'm missing something. Commets from concurrentMarkSweepGeneration.cpp // Normally, we'll compact only if the UseCMSCompactAtFullCollection // flag is set, and we have either requested a System.gc() or // the number of full gc's since the last concurrent cycle // has exceeded the threshold set by CMSFullGCsBeforeCompaction, // or if an incremental collection has failed Any clarification in this matter would be appreciated. FYI, normally we are able to avoid promotion failures by setting CMSOccupancyFraction to an aggressive number such as 50, though this comes at the cost of a much larger heap and slower minor collections. Thanks, Shane -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Jon.Masamitsu at Sun.COM Fri Oct 24 20:43:55 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Fri, 24 Oct 2008 13:43:55 -0700 Subject: does CMS collector ever compact? In-Reply-To: References: Message-ID: <4902338B.3010602@sun.com> If a promotion failure occurs, the heap is compacted with the default settings for UseCMSCompactAtFullCollection and CMSFullGCsBeforeCompaction. What are all the command line flags that you use? Shane Cox wrote On 10/24/08 13:16,: > Periodically our application encounters promotion failures when > running the CMS collector, presumably due to a fragmented Tenured > space. Once the first failure occurs, we tend to see subsequent > failures at lower occupancies of Tenured space. For example, the > first promotion failure might occur when Tenured is 70% full, the next > 68%, then 65%, ... you get the picture. So my question is whether a > compaction will ever be performed to resolve the fragmentation? > > > I'm not a programmer, but I see comments in > concurrentMarkSweepGeneration.cpp that lead me to believe that a > compact would happen if UseCMSCompactAtFullCollection is set to TRUE > and the threshold set by CMSFullGCsBeforeCompaction has been > exceeded. However, since the defaults are TRUE and 0 respectively, I > would think that the first Full GC triggered by a promotion failure > would perform a compact. Apparently I'm missing something. > > Commets from concurrentMarkSweepGeneration.cpp > // Normally, we'll compact only if the UseCMSCompactAtFullCollection > // flag is set, and we have either requested a System.gc() or > // the number of full gc's since the last concurrent cycle > // has exceeded the threshold set by CMSFullGCsBeforeCompaction, > // or if an incremental collection has failed > > > Any clarification in this matter would be appreciated. > > FYI, normally we are able to avoid promotion failures by setting > CMSOccupancyFraction to an aggressive number such as 50, though this > comes at the cost of a much larger heap and slower minor collections. > > Thanks, > Shane > >------------------------------------------------------------------------ > >_______________________________________________ >hotspot-gc-use mailing list >hotspot-gc-use at openjdk.java.net >http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Y.S.Ramakrishna at Sun.COM Fri Oct 24 21:11:00 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Fri, 24 Oct 2008 14:11:00 -0700 Subject: does CMS collector ever compact? In-Reply-To: References: Message-ID: Hi Shane -- > Periodically our application encounters promotion failures when > running the > CMS collector, presumably due to a fragmented Tenured space. Once the > first > failure occurs, we tend to see subsequent failures at lower > occupancies of > Tenured space. For example, the first promotion failure might occur when > Tenured is 70% full, the next 68%, then 65%, ... you get the picture. > So my > question is whether a compaction will ever be performed to resolve the > fragmentation? It is interesting that the onset of each subsequent promotion failure happens at a lower occupancy than the previous. I do not believe I have seen that behaviour before, and do not have any conjectures as to why that could be happening. Indeed I would normally have expected it to be larger (higher occupancy) after the first and then to remain stable at that value thereafter. Perhaps you can share some gc logs showing this, if possible? (email the logs offline to one of us, if so.) Sometimes, looking at entire gc logs as a whole fires the right cerebral neurons. We are actively working on improving some of our heuristics related to controlling fragmentation (under CR 6631166); stay tuned for some improvements in that area soon. -- ramki > > > I'm not a programmer, but I see comments in > concurrentMarkSweepGeneration.cpp that lead me to believe that a compact > would happen if UseCMSCompactAtFullCollection is set to TRUE and the > threshold set by CMSFullGCsBeforeCompaction has been exceeded. However, > since the defaults are TRUE and 0 respectively, I would think that the > first > Full GC triggered by a promotion failure would perform a compact. > Apparently I'm missing something. > > Commets from concurrentMarkSweepGeneration.cpp > // Normally, we'll compact only if the UseCMSCompactAtFullCollection > // flag is set, and we have either requested a System.gc() or > // the number of full gc's since the last concurrent cycle > // has exceeded the threshold set by CMSFullGCsBeforeCompaction, > // or if an incremental collection has failed > > > Any clarification in this matter would be appreciated. > > FYI, normally we are able to avoid promotion failures by setting > CMSOccupancyFraction to an aggressive number such as 50, though this comes > at the cost of a much larger heap and slower minor collections. > > Thanks, > Shane > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From dragonken at gmail.com Mon Oct 27 15:49:21 2008 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Mon, 27 Oct 2008 08:49:21 -0700 (PDT) Subject: promotion failure Message-ID: <20190439.post@talk.nabble.com> Just for your information. My java app is running very well now. Thanks to all of you. Today I got a promotion failure at uptime = 10 days and triggered a 4 seconds full gc. It is not a big problem as I can restart my app weekly or manually trigger full gc (by jmap -histo -live at night). JDK Version: java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode) JVM options: -Djava.security.policy=./java.policy -Xms4G -Xmx4G -XX:NewSize=1G -XX:MaxNewSize=1G -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:MaxTenuringThreshold=1 -XX:SurvivorRatio=4 -XX:+HandlePromotionFailure -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintGCDetails -XX:+PrintGCTaskTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintReferenceGC -Xloggc:gc.log -Dcom.sun.management.jmxremote.port=18002 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false GC Log: http://www.nabble.com/file/p20190439/gc.log gc.log -- View this message in context: http://www.nabble.com/promotion-failure-tp20190439p20190439.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From Antonios.Printezis at sun.com Mon Oct 27 15:59:02 2008 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Mon, 27 Oct 2008 11:59:02 -0400 Subject: does CMS collector ever compact? In-Reply-To: References: Message-ID: <4905E546.5090800@sun.com> (this is a wild shot in the dark!) Does the application have an array-based data structure (ArrayList, HashMap, etc.) that keeps growing? Usually such data structures double the size of the associated array every time they need to grow it. The larger the array is, the earlier (maybe!) it will cause fragmentation. Tony Y Srinivas Ramakrishna wrote: > Hi Shane -- > > >> Periodically our application encounters promotion failures when >> running the >> CMS collector, presumably due to a fragmented Tenured space. Once the >> first >> failure occurs, we tend to see subsequent failures at lower >> occupancies of >> Tenured space. For example, the first promotion failure might occur when >> Tenured is 70% full, the next 68%, then 65%, ... you get the picture. >> So my >> question is whether a compaction will ever be performed to resolve the >> fragmentation? >> > > > > It is interesting that the onset of each subsequent promotion failure > happens at a lower occupancy than the previous. I do not believe I have > seen that behaviour before, and do not have any conjectures as to why > that could be happening. Indeed I would normally have expected it to > be larger (higher occupancy) after the first and then to remain stable > at that value thereafter. Perhaps you can share some gc logs showing this, > if possible? (email the logs offline to one of us, if so.) Sometimes, > looking at entire gc logs as a whole fires the right cerebral neurons. > > We are actively working on improving some of our heuristics > related to controlling fragmentation (under CR 6631166); stay tuned > for some improvements in that area soon. > > -- ramki > > >> I'm not a programmer, but I see comments in >> concurrentMarkSweepGeneration.cpp that lead me to believe that a compact >> would happen if UseCMSCompactAtFullCollection is set to TRUE and the >> threshold set by CMSFullGCsBeforeCompaction has been exceeded. However, >> since the defaults are TRUE and 0 respectively, I would think that the >> first >> Full GC triggered by a promotion failure would perform a compact. >> Apparently I'm missing something. >> >> Commets from concurrentMarkSweepGeneration.cpp >> // Normally, we'll compact only if the UseCMSCompactAtFullCollection >> // flag is set, and we have either requested a System.gc() or >> // the number of full gc's since the last concurrent cycle >> // has exceeded the threshold set by CMSFullGCsBeforeCompaction, >> // or if an incremental collection has failed >> >> >> Any clarification in this matter would be appreciated. >> >> FYI, normally we are able to avoid promotion failures by setting >> CMSOccupancyFraction to an aggressive number such as 50, though this comes >> at the cost of a much larger heap and slower minor collections. >> >> Thanks, >> Shane >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > -- ---------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS BUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | ---------------------------------------------------------------------- e-mail client: Thunderbird (Solaris) _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Y.S.Ramakrishna at Sun.COM Tue Oct 28 18:03:34 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Tue, 28 Oct 2008 11:03:34 -0700 Subject: ParallelGCThreads In-Reply-To: <19B27FD5AF2EAA49A66F787911CF51952E782D@CTSINCHNSXUU.cts.com> References: <19B27FD5AF2EAA49A66F787911CF51952E782D@CTSINCHNSXUU.cts.com> Message-ID: Hi Sujit -- > We have a distributed trading application. I have a processor set of > 16 CPU bound to process A and 8 CPU to process B. Please consider > following scenarios: > > Scenario1: ParallelGCThreads set to 16 for both Process A and B. 16 for Process B is definitely the wrong setting. You should use 8 or less for Process B, since it has only an 8 processor pset to run on. > > Scenario2: ParallelGCThreads set to 8 for both Process A and B. > > Now for scenario2, I see that threadstop time has increased (got > worse) for process A and reduced (improved) for process B. Is this an > expected behaviour? Also will this (# of ParallelGCThreads vs # of > CPUs) impact rate of minor collections? Yes, exactly as expected. In Scenario 2, you have more than 8 cpu's available for GC of A, so using more than 8 GC threads is paying off. If you exceed the # cpu's available, however, gc times will increase. That's what you saw in the case of B going from Scenario 2 to Scenario 1. #parallel gc threads does not affect the time between parallel collections, but only the duration of the collections. The time between gcs is affected (mainly) by the size of Eden and speed of the mutators. -- ramki > > Thanks and Regards, > Sujit > > > This e-mail and any files transmitted with it are for the sole use of > the intended recipient(s) and may contain confidential and privileged > information. > If you are not the intended recipient, please contact the sender by > reply e-mail and destroy all copies of the original message. > Any unauthorized review, use, disclosure, dissemination, forwarding, > printing or copying of this email or any action taken in reliance on > this e-mail is strictly prohibited and may be unlawful. > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Y.S.Ramakrishna at Sun.COM Tue Oct 28 18:15:58 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Tue, 28 Oct 2008 11:15:58 -0700 Subject: ParallelGCThreads In-Reply-To: References: <19B27FD5AF2EAA49A66F787911CF51952E782D@CTSINCHNSXUU.cts.com> Message-ID: By the way, i believe that the default #gc workers you would have gotten (with UseParallelGC) for process A would have been 16 and for process B eight, if you had launched them bound. (Re)Binding after launching does not readjust from the default, something we need to fix; so, in that case, you would need to explicitly set ParallelGCThreads. (With CMS, the numbers are similar, if linearly scaled down by a suitable factor.) -- ramki ----- Original Message ----- From: Y Srinivas Ramakrishna Date: Tuesday, October 28, 2008 11:06 am Subject: Re: ParallelGCThreads To: Sujit.Das at cognizant.com Cc: hotspot-gc-use at openjdk.java.net > Hi Sujit -- > > > We have a distributed trading application. I have a processor set of > > > 16 CPU bound to process A and 8 CPU to process B. Please consider > > following scenarios: > > > > Scenario1: ParallelGCThreads set to 16 for both Process A and B. > > 16 for Process B is definitely the wrong setting. You should use > 8 or less for Process B, since it has only an 8 processor pset to run > on. > > > > > Scenario2: ParallelGCThreads set to 8 for both Process A and B. > > > > Now for scenario2, I see that threadstop time has increased (got > > worse) for process A and reduced (improved) for process B. Is this > an > > expected behaviour? Also will this (# of ParallelGCThreads vs # of > > CPUs) impact rate of minor collections? > > Yes, exactly as expected. In Scenario 2, you have more than 8 cpu's > available for GC of A, so using more than 8 GC threads is paying off. > If you exceed the # cpu's available, however, gc times will increase. > That's what you saw in the case of B going from Scenario 2 to Scenario > 1. > > #parallel gc threads does not affect the time between parallel collections, > but only the duration of the collections. The time between gcs is affected > (mainly) by the size of Eden and speed of the mutators. > > -- ramki > > > > > Thanks and Regards, > > Sujit > > > > > > This e-mail and any files transmitted with it are for the sole use > of > > the intended recipient(s) and may contain confidential and > privileged > > information. > > If you are not the intended recipient, please contact the sender by > > > reply e-mail and destroy all copies of the original message. > > Any unauthorized review, use, disclosure, dissemination, forwarding, > > > printing or copying of this email or any action taken in reliance on > > > this e-mail is strictly prohibited and may be unlawful. > > _______________________________________________ > > hotspot-gc-use mailing list > > hotspot-gc-use at openjdk.java.net > > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From mirza2m at gmail.com Fri Oct 31 19:29:54 2008 From: mirza2m at gmail.com (mirza2m at gmail.com) Date: Fri, 31 Oct 2008 14:29:54 -0500 Subject: Modifying the JVM to have a more deterministic garbage collection model Message-ID: <9198d5d0810311229s38e61e42r4f7ec28e89540268@mail.gmail.com> Hi, For my class project I want to modify the JVM to have a more deterministic garbage collection model. I will take a reference counting approach to accomplish this. More specifically I will use a variation of the algorithm described here http://www.jucs.org/jucs_13_6/cyclic_reference_counting_with/jucs_13_6_0830_0838_lins.pdf In order to do this I need to store reference count or multiple reference counts for each object. I will also need to update these counts when a reference is added or removed. I need some help on figuring out what would be the best way to do this? Can this be done by tweaking or replacing some parts of the jvm or would I have to do an over haul of the whole jvm (I hope that is not the case :) ) I have looked at some of the source code at src/share/vm/{memory, gc-interface, gc-implementation} but seems like this only handles garbage collection it self, I also wanted to know where I would put hooks to update refrence counts and what would be the best place to store the reference counts, with in the object itself or somewhere else. Any suggestion on software engineering aspect of this project would also be very helpful. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: