From john.coomes at oracle.com Fri Jul 2 07:14:37 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Jul 2010 14:14:37 +0000 Subject: hg: jdk7/hotspot-rt: 4 new changesets Message-ID: <20100702141437.87A7A476F8@hg.openjdk.java.net> Changeset: dc900d5a8e2f Author: mikejwre Date: 2010-06-24 20:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/dc900d5a8e2f Added tag jdk7-b99 for changeset e7f18db469a3 ! .hgtags Changeset: 47f6b7db1882 Author: ohair Date: 2010-06-21 11:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/47f6b7db1882 6960853: Cleanup makefiles, remove unused vars etc. 6959596: Windows fastdebug build broken 6960335: Add top level 'make test' rule that uses test/Makefile, runs all test batches Reviewed-by: alanb ! Makefile ! make/Defs-internal.gmk ! make/jprt.gmk ! make/sanity-rules.gmk ! test/Makefile Changeset: 3b147bf5a0e9 Author: lana Date: 2010-06-21 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/3b147bf5a0e9 Merge Changeset: b218a53ec7d3 Author: lana Date: 2010-06-29 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/b218a53ec7d3 Merge From john.coomes at oracle.com Fri Jul 2 07:14:42 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Jul 2010 14:14:42 +0000 Subject: hg: jdk7/hotspot-rt/corba: 5 new changesets Message-ID: <20100702141447.E02B7476F9@hg.openjdk.java.net> Changeset: ad2aa1f66abf Author: mikejwre Date: 2010-06-24 20:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/ad2aa1f66abf Added tag jdk7-b99 for changeset 95db968660e7 ! .hgtags Changeset: 032585ad970d Author: jjg Date: 2010-06-14 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/032585ad970d 6960831: fix CORBA build warnings Reviewed-by: darcy ! src/share/classes/com/sun/corba/se/impl/orbutil/CorbaResourceUtil.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ObjectUtility.java ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/ExceptionHandlerImpl.java ! src/share/classes/org/omg/CORBA/ORB.java ! src/share/classes/sun/corba/Bridge.java Changeset: 8f0a1a30461d Author: lana Date: 2010-06-16 13:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/8f0a1a30461d Merge Changeset: 8eeca6e452de Author: lana Date: 2010-06-21 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/8eeca6e452de Merge Changeset: a56d734a1e97 Author: lana Date: 2010-06-29 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/a56d734a1e97 Merge From john.coomes at oracle.com Fri Jul 2 07:24:06 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Jul 2010 14:24:06 +0000 Subject: hg: jdk7/hotspot-rt/jaxp: 5 new changesets Message-ID: <20100702142406.99F9A476FA@hg.openjdk.java.net> Changeset: 69a11eec2789 Author: mikejwre Date: 2010-06-24 20:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/69a11eec2789 Added tag jdk7-b99 for changeset 7ef8469021fb ! .hgtags Changeset: 214f47923c24 Author: ohair Date: 2010-06-17 10:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/214f47923c24 6955301: Update names and references to rebranded drop bundles (jaxp, jaxws, jaf) Reviewed-by: darcy ! jaxp.properties Changeset: 961ad5ff3b19 Author: ohair Date: 2010-06-17 10:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/961ad5ff3b19 6955292: Workaround ant 1.7.1 package-info.java issue in ant scripts 6960333: Add make level ALLOW_DOWNLOADS=true option 6940241: Change jaxp/jaxws so that the http downloads are not done by default Reviewed-by: darcy ! build-defs.xml ! build-drop-template.xml ! build.properties ! build.xml ! make/Makefile Changeset: 478835e100cd Author: lana Date: 2010-06-21 22:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/478835e100cd Merge Changeset: d524be5ef62e Author: lana Date: 2010-06-29 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/d524be5ef62e Merge From john.coomes at oracle.com Fri Jul 2 07:24:10 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Jul 2010 14:24:10 +0000 Subject: hg: jdk7/hotspot-rt/jaxws: 5 new changesets Message-ID: <20100702142410.8814B476FB@hg.openjdk.java.net> Changeset: 5bca7bc114a0 Author: mikejwre Date: 2010-06-24 20:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/5bca7bc114a0 Added tag jdk7-b99 for changeset 818366ce23d8 ! .hgtags Changeset: 38fd32b8e990 Author: ohair Date: 2010-06-17 17:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/38fd32b8e990 6869741: Integrate JAX-WS 2.2 and JAXB 2.2 in JDK 7 Reviewed-by: darcy, ramap ! jaxws.properties Changeset: 48872561d4b1 Author: ohair Date: 2010-06-17 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/48872561d4b1 6955292: Workaround ant 1.7.1 package-info.java issue in ant scripts 6940241: Change jaxp/jaxws so that the http downloads are not done by default 6960333: Add make level ALLOW_DOWNLOADS=true option Reviewed-by: darcy, ramap ! build-defs.xml ! build-drop-template.xml ! build.properties ! build.xml ! make/Makefile Changeset: db63f482182d Author: lana Date: 2010-06-21 22:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/db63f482182d Merge Changeset: bd26d0ce0c3c Author: lana Date: 2010-06-29 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/bd26d0ce0c3c Merge From john.coomes at oracle.com Fri Jul 2 07:26:08 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Jul 2010 14:26:08 +0000 Subject: hg: jdk7/hotspot-rt/jdk: 76 new changesets Message-ID: <20100702143903.55B1B476FC@hg.openjdk.java.net> Changeset: 0cd764a1c809 Author: jrose Date: 2010-04-30 23:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0cd764a1c809 6939134: JSR 292 adjustments to method handle invocation Summary: split MethodHandle.invoke into invokeExact and invokeGeneric; also clean up JVM-to-Java interfaces Reviewed-by: twisti ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/JavaMethodHandle.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/dyn/NoAccessException.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/BoundMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FilterOneArgument.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/MemberName.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/MethodTypeImpl.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/package-info.java ! src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java ! test/java/dyn/MethodHandlesTest.java Changeset: 4a28a204b726 Author: jrose Date: 2010-05-03 23:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4a28a204b726 6939196: method handle signatures off the boot class path get linkage errors Summary: Remove workaround from MethodHandleImpl lookup code; add JUnit regression test to MethodHandlesTest. Reviewed-by: twisti ! src/share/classes/sun/dyn/MethodHandleImpl.java ! test/java/dyn/MethodHandlesTest.java Changeset: 3cf85945abef Author: jrose Date: 2010-05-13 20:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3cf85945abef Merge Changeset: d742045bd30b Author: jrose Date: 2010-06-18 15:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d742045bd30b Merge ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/JavaMethodHandle.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/dyn/NoAccessException.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/BoundMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FilterOneArgument.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/MemberName.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/MethodTypeImpl.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/package-info.java ! src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java ! test/java/dyn/MethodHandlesTest.java Changeset: 3d944ecfa470 Author: jrose Date: 2010-06-08 23:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3d944ecfa470 6939203: JSR 292 needs method handle constants Summary: Add new CP types CONSTANT_MethodHandle, CONSTANT_MethodType to verifier; put in runtime support upcall. Reviewed-by: twisti ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/javavm/export/classfile_constants.h ! src/share/native/common/check_code.c ! test/java/dyn/MethodHandlesTest.java Changeset: 2587c9f0b60d Author: jrose Date: 2010-06-19 01:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2587c9f0b60d Merge ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/javavm/export/classfile_constants.h ! src/share/native/common/check_code.c ! test/java/dyn/MethodHandlesTest.java Changeset: 3956cdee6712 Author: mikejwre Date: 2010-06-24 20:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3956cdee6712 Added tag jdk7-b99 for changeset 2587c9f0b60d ! .hgtags Changeset: 4d55419ce99e Author: andrew Date: 2010-06-08 17:52 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4d55419ce99e 6959123: Remove use of obsolete png_check_sig function in splashscreen_png.c Summary: Avoid use of deprecated libpng macro (removed in some 1.4.x releases) Reviewed-by: prr ! src/share/native/sun/awt/splashscreen/splashscreen_png.c Changeset: 2574d999704a Author: igor Date: 2010-06-10 15:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2574d999704a 6952043: Incorrect JNI calls in fontpath.c Reviewed-by: jgodinez, prr ! src/windows/native/sun/font/fontpath.c Changeset: ae887ea4c772 Author: lana Date: 2010-06-10 18:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ae887ea4c772 Merge - make/com/sun/inputmethods/Makefile - make/com/sun/inputmethods/indicim/Makefile - make/com/sun/inputmethods/thaiim/Makefile - src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariInputMethodDescriptor.java - src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariTables.java - src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethod.java - src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethodImpl.java - src/share/classes/com/sun/inputmethods/internal/indicim/java.awt.im.spi.InputMethodDescriptor - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_de.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_es.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_fr.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_it.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ja.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ko.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_sv.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_CN.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_TW.properties - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethod.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodDescriptor.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodImpl.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiRules.java - src/share/classes/com/sun/inputmethods/internal/thaiim/java.awt.im.spi.InputMethodDescriptor - src/share/classes/com/sun/inputmethods/internal/thaiim/resources/DisplayNames.properties - src/share/classes/javax/swing/text/html/parser/html32.bdtd - src/share/classes/sun/security/tools/PolicyTool.java Changeset: 8b55669c7b7a Author: neugens Date: 2010-06-16 20:46 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8b55669c7b7a 6961732: FontMetrics.getLeading() may be negative in freetype-based OpenJDK builds. Summary: Fix premature integer roundings to preserve correct height, width and descent values for fonts Reviewed-by: prr ! src/share/native/sun/font/freetypeScaler.c Changeset: 83c7768292d7 Author: prr Date: 2010-06-18 11:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/83c7768292d7 6961633: gui applications cause a jvm crash on windows Reviewed-by: ceisserer, bae ! make/sun/pisces/Makefile ! src/share/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine + src/solaris/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine Changeset: 31d25fccdf1c Author: lana Date: 2010-06-21 22:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/31d25fccdf1c Merge Changeset: c02096d7b70e Author: anthony Date: 2010-06-16 11:26 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c02096d7b70e 6959787: java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.html failed on 7b94 Summary: Add a delay to the test to make sure the filename filters are called. Reviewed-by: dcherepanov, art ! test/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.java Changeset: fa06ad055c43 Author: coffeys Date: 2010-06-16 16:15 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/fa06ad055c43 6860491: WRAP_TIME_MILLIS incorrectly set Summary: Alter WRAP_TIME_MILLIS to be unsigned Reviewed-by: yan ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 8722b75c9ccd Author: anthony Date: 2010-06-18 17:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8722b75c9ccd 6959165: JVM crash during execution FileDialogBufferOverflowTest.html Summary: Add proper synchronization Reviewed-by: art, dcherepanov ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c Changeset: 05eb107d6891 Author: anthony Date: 2010-06-18 17:13 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/05eb107d6891 6961754: JCK tests CvsEventTest0001 and CvsEventTest0002 fail under FF 3.5 on OEL 5 Summary: Check the return value of XlibUtil.translateCoordinates() for null Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: ae16c200341a Author: lana Date: 2010-06-21 22:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ae16c200341a Merge Changeset: ad5f65797249 Author: rupashka Date: 2010-06-02 11:59 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ad5f65797249 6857057: api/javax_swing/text/GlyphView/index.html#Methods test fails Reviewed-by: peterz ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/WrappedPlainView.java + test/javax/swing/text/WrappedPlainView/6857057/StubBranchElement.java + test/javax/swing/text/WrappedPlainView/6857057/StubLeafElement.java + test/javax/swing/text/WrappedPlainView/6857057/bug6857057.java Changeset: dc14ee238fe3 Author: rupashka Date: 2010-06-02 12:53 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/dc14ee238fe3 6636983: Japanese text does not display correctly in a JEditorPane Reviewed-by: peterz ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/text/DefaultStyledDocument/6636983/bug6636983.java Changeset: d1c875d94263 Author: lana Date: 2010-06-10 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d1c875d94263 Merge - src/share/classes/sun/security/tools/PolicyTool.java Changeset: 7a3d8fc0d2cd Author: malenkov Date: 2010-06-15 17:39 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7a3d8fc0d2cd 5066685: BorderFactory lacks SoftBevelBorder support Reviewed-by: alexp ! src/share/classes/javax/swing/BorderFactory.java Changeset: cf13f6389bdd Author: alexp Date: 2010-06-15 19:05 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/cf13f6389bdd 6788484: NPE in DefaultTableCellHeaderRenderer.getColumnSortOrder() with null table Reviewed-by: rupashka ! src/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java + test/javax/swing/JTable/6788484/bug6788484.java Changeset: 5e4969391538 Author: alexp Date: 2010-06-15 19:10 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5e4969391538 6735259: NPE at WindowsComboBoxUI$XPComboBoxButton.getState(WindowsComboBoxUI.java:408) Reviewed-by: rupashka ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java Changeset: cd565c554dc6 Author: alexp Date: 2010-06-15 21:28 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/cd565c554dc6 6771547: SynthParser throws StringIndexOutOfBoundsException parsing custom ColorTypes Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/synth/SynthParser.java + test/javax/swing/plaf/synth/6771547/SynthTest.java + test/javax/swing/plaf/synth/6771547/synthconfig.xml Changeset: 4d93c409ce87 Author: alexp Date: 2010-06-15 21:32 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4d93c409ce87 6739756: JToolBar leaves space for non-visible items under Nimbus L&F Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java + test/javax/swing/plaf/synth/SynthToolBarUI/6739756/bug6739756.java Changeset: aaa62c1f221e Author: lana Date: 2010-06-21 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/aaa62c1f221e Merge Changeset: 17870c6c1d4e Author: alanb Date: 2010-06-02 09:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/17870c6c1d4e 6950927: Testcase failure sun/management/jmxremote/bootstrap/JvmstatCountersTest.java Reviewed-by: dholmes, dcubed ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java ! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java Changeset: 6e57723b3519 Author: alanb Date: 2010-06-02 09:35 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6e57723b3519 Merge Changeset: 1db252f307b6 Author: martin Date: 2010-06-02 17:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1db252f307b6 6955840: ThreadLocalRandom bug - overriden setSeed(long) method is not invoked for java.util.Random(long) Summary: Allow setSeed only during construction Reviewed-by: dl, dholmes ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java Changeset: ea8c57ec8409 Author: weijun Date: 2010-06-04 19:28 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ea8c57ec8409 6951366: kerberos login failure on win2008 with AD set to win2000 compat mode Reviewed-by: valeriep, xuelei ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/W83.java Changeset: 489c1720757b Author: chegar Date: 2010-06-08 10:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/489c1720757b 6957375: java/net/ResponseCache getResponseCode and ResponseCacheTest fail after rebranding Reviewed-by: ohair, wetmore, alanb ! test/java/net/ResponseCache/file1.cache Changeset: a21e3a29ca9d Author: darcy Date: 2010-06-08 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a21e3a29ca9d 6935997: Please add a nested throwable constructor to AssertionError Reviewed-by: martin, forax, wetmore ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/security/Security.java Changeset: af68ad345389 Author: alanb Date: 2010-06-09 18:51 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/af68ad345389 6935563: (dc) Improve connection reset/port unreachable handling [win] Reviewed-by: chegar ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/Net.c + test/java/nio/channels/DatagramChannel/SelectWhenRefused.java Changeset: 1474dfa499e3 Author: mchung Date: 2010-06-10 14:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1474dfa499e3 6959965: jstat: Add new -classload option to print class loading statistics Summary: Add a new jstat -classload option Reviewed-by: alanb ! make/sun/tools/Makefile ! src/share/classes/sun/tools/jstat/Arguments.java ! src/share/classes/sun/tools/jstat/OptionFinder.java ! src/share/classes/sun/tools/jstat/OptionLister.java ! src/share/classes/sun/tools/jstat/resources/jstat_options + src/share/classes/sun/tools/jstat/resources/jstat_unsupported_options + test/sun/tools/jstat/classloadOutput1.awk + test/sun/tools/jstat/jstatClassloadOutput1.sh ! test/sun/tools/jstat/jstatOptions1.sh + test/sun/tools/jstat/options2.out Changeset: af827b7eb81d Author: mchung Date: 2010-06-10 14:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/af827b7eb81d Merge Changeset: f7a69b261b1d Author: martin Date: 2010-06-10 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f7a69b261b1d 6960394: Stop linking with -lnsl on Linux Summary: Define LIBNSL (like LIBSOCKET), non-empty only on Solaris Reviewed-by: ohair ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/java/hpi/hpi_common.gmk ! make/java/java/Makefile ! make/java/java_hprof_demo/Makefile ! make/java/net/Makefile ! make/jpda/transport/socket/Makefile ! make/mkdemo/jvmti/hprof/Makefile ! src/share/demo/jvmti/hprof/sample.makefile.txt Changeset: aa8effe6bb54 Author: martin Date: 2010-06-10 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/aa8effe6bb54 6959259: Minor improvements to static Random field caching Summary: Cache fields in locals; small javadoc clarifications Reviewed-by: emcmanus, dholmes, forax, dl ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/util/Collections.java Changeset: b1ec20722051 Author: weijun Date: 2010-06-11 11:38 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b1ec20722051 6958869: regression: PKIXValidator fails when multiple trust anchors have same dn Reviewed-by: xuelei, wetmore, mullan ! src/share/classes/sun/security/validator/PKIXValidator.java ! test/sun/security/validator/CertReplace.java ! test/sun/security/validator/certreplace.sh + test/sun/security/validator/samedn.sh Changeset: 06699a990ac7 Author: alanb Date: 2010-06-11 14:31 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/06699a990ac7 6934585: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Basic.java Reviewed-by: chegar ! test/ProblemList.txt ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java Changeset: 7079585d6e0e Author: alanb Date: 2010-06-11 14:47 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7079585d6e0e 6938230: (so) SocketAdaptor.close() does not translate IOException resulting in Error Reviewed-by: chegar ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java Changeset: c849dc20dc85 Author: andrew Date: 2010-06-12 01:32 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c849dc20dc85 6959197: When building with JAVAC_MAX_WARNINGS=true, the build fails in sun/nio/cs due to the use of -Werror Summary: Remove unneeded casts, add generic types and make better use of static data Reviewed-by: sherman ! make/sun/nio/cs/Makefile ! src/share/classes/sun/io/ByteToCharISO2022.java ! src/share/classes/sun/io/ByteToCharISO2022JP.java ! src/share/classes/sun/io/ByteToCharJISAutoDetect.java ! src/share/classes/sun/io/CharToBytePCK.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java ! src/share/classes/sun/nio/cs/ext/ISO2022.java ! src/share/classes/sun/nio/cs/ext/JISAutoDetect.java ! src/share/classes/sun/nio/cs/ext/PCK.java ! src/share/classes/sun/nio/cs/ext/SJIS.java ! src/solaris/classes/sun/nio/cs/ext/COMPOUND_TEXT_Encoder.java ! src/solaris/classes/sun/nio/cs/ext/CompoundTextSupport.java Changeset: 422531c98ba5 Author: martin Date: 2010-06-11 18:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/422531c98ba5 6944584: Improvements to subprocess handling on Unix Summary: use thread pool for reaper thread; move most I/O operations out of reaper thread Reviewed-by: michaelm, hiroshi ! src/share/classes/java/lang/ProcessBuilder.java ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! test/java/lang/ProcessBuilder/Basic.java Changeset: 5a61a4f65c9c Author: martin Date: 2010-06-13 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5a61a4f65c9c 6960898: Regression due to src/share/classes/java/lang/ProcessBuilder.java changes Summary: Use Null{In,Out}putStream.INSTANCE as with Linux code Reviewed-by: ohair ! src/solaris/classes/java/lang/UNIXProcess.java.solaris ! src/windows/classes/java/lang/ProcessImpl.java Changeset: 76a9c90e9019 Author: alanb Date: 2010-06-15 10:03 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/76a9c90e9019 6961062: (dc) Several DatagramChannel tests timeout or fail with "address already in use" Reviewed-by: chegar ! test/ProblemList.txt ! test/java/nio/channels/DatagramChannel/Connect.java ! test/java/nio/channels/DatagramChannel/EmptyBuffer.java ! test/java/nio/channels/DatagramChannel/NoSender.java ! test/java/nio/channels/DatagramChannel/SRTest.java ! test/java/nio/channels/DatagramChannel/Sender.java Changeset: fb2d88134382 Author: mchung Date: 2010-06-14 14:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/fb2d88134382 6960789: com.sun.servicetag API needs to be added in ct.sym Summary: Include com.sun.servicetag classes when generating ct.sym Reviewed-by: alanb, jjg ! make/common/Release.gmk ! test/ProblemList.txt Changeset: c1f7ff3447ba Author: mchung Date: 2010-06-15 09:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c1f7ff3447ba 6952161: Rebranding: Registration html for servicetag Summary: Rebrand register.html and jdk_header.png Reviewed-by: ohair, asaha, ogino, mfang ! src/share/classes/com/sun/servicetag/resources/jdk_header.png ! 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 Changeset: 915ca65d1db7 Author: mchung Date: 2010-06-15 09:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/915ca65d1db7 Merge ! test/ProblemList.txt Changeset: 8d7438dede10 Author: mchung Date: 2010-06-15 09:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8d7438dede10 6959641: testcase failing java/util/Locale/Bug4184873Test.java Summary: Revert the Bug4184873_{he,id,yi} files to revision 0 (before rebranding) Reviewed-by: naoto ! test/ProblemList.txt ! test/java/util/Locale/Bug4184873_he ! test/java/util/Locale/Bug4184873_id ! test/java/util/Locale/Bug4184873_yi Changeset: 72022d7d4578 Author: alanb Date: 2010-06-15 16:36 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/72022d7d4578 6932744: TEST_BUG: java/nio/channels/Selector/OpRead.java failing Reviewed-by: chegar ! test/ProblemList.txt ! test/java/nio/channels/Selector/OpRead.java Changeset: 91124d60b2ed Author: alanb Date: 2010-06-15 16:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/91124d60b2ed 6961358: TEST_BUG: java/nio/channels/SocketChannel/OpenLeak.java can't run in samevm mode Reviewed-by: chegar ! test/ProblemList.txt ! test/java/nio/channels/SocketChannel/OpenLeak.java Changeset: 125ec775c9d1 Author: alanb Date: 2010-06-15 21:43 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/125ec775c9d1 Merge ! test/ProblemList.txt Changeset: 1b7879ca3e74 Author: mchung Date: 2010-06-15 20:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1b7879ca3e74 6961518: TEST_BUG: add @run main/othervm in tests that call setSecurityManager Summary: Mark tests to run in othervm Reviewed-by: ohair ! test/ProblemList.txt ! test/java/beans/Beans/Test4080522.java ! test/java/beans/EventHandler/Test6277246.java ! test/java/beans/EventHandler/Test6277266.java ! test/java/beans/Introspector/Test6277246.java ! test/java/lang/ClassLoader/UninitializedParent.java ! test/java/lang/ClassLoader/findSystemClass/Loader.java ! test/java/lang/System/IgnoreNullSecurityManager.java ! test/java/lang/annotation/ParameterAnnotations.java ! test/java/util/ResourceBundle/Bug6359330.java ! test/java/util/ResourceBundle/Test4300693.java Changeset: 55e512967525 Author: mchung Date: 2010-06-15 20:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/55e512967525 6961506: TEST_BUG: ResourceBundle/Bug4168625Test.java and TestBug4179766.java fails in samevm mode Summary: Set the proper parent class loader of Loader and SimpleLoader Reviewed-by: naoto ! test/ProblemList.txt ! test/java/util/ResourceBundle/Bug4168625Test.java ! test/java/util/ResourceBundle/TestBug4179766.java Changeset: 8a4557c5dfa1 Author: alanb Date: 2010-06-16 14:24 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8a4557c5dfa1 6961630: TEST_BUG: Several SocketChannel and Selector tests can fail with "address already in use" Reviewed-by: chegar ! test/ProblemList.txt ! test/java/nio/channels/Selector/ByteServer.java ! test/java/nio/channels/Selector/CloseThenRegister.java ! test/java/nio/channels/Selector/ReadAfterConnect.java ! test/java/nio/channels/Selector/SelectAfterRead.java ! test/java/nio/channels/Selector/SelectWrite.java ! test/java/nio/channels/SocketChannel/BigReadWrite.java ! test/java/nio/channels/SocketChannel/VectorIO.java ! test/java/nio/channels/SocketChannel/Write.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/EchoTest.java Changeset: 8a286789de96 Author: ksrini Date: 2010-06-16 12:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8a286789de96 6575373: Error verifying signatures of pack200 files in some cases Reviewed-by: jrose, forax ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/java/util/jar/Pack200.java ! test/tools/pack200/Pack200Test.java + test/tools/pack200/SegmentLimit.java Changeset: 705777f990cf Author: mchung Date: 2010-06-16 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/705777f990cf 6961502: TEST_BUG: test/java/lang/ClassLoader/defineClass/DefineClassByteBuffer.java fails Summary: Fix the test to define TestClass by DummyClassLoader as it intends to do Reviewed-by: alanb ! test/ProblemList.txt ! test/java/lang/ClassLoader/defineClass/DefineClassByteBuffer.java Changeset: 94404fea2067 Author: lana Date: 2010-06-16 14:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/94404fea2067 Merge - make/com/sun/inputmethods/Makefile - make/com/sun/inputmethods/indicim/Makefile - make/com/sun/inputmethods/thaiim/Makefile ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Release.gmk - src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariInputMethodDescriptor.java - src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariTables.java - src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethod.java - src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethodImpl.java - src/share/classes/com/sun/inputmethods/internal/indicim/java.awt.im.spi.InputMethodDescriptor - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_de.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_es.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_fr.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_it.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ja.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ko.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_sv.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_CN.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_TW.properties - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethod.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodDescriptor.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodImpl.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiRules.java - src/share/classes/com/sun/inputmethods/internal/thaiim/java.awt.im.spi.InputMethodDescriptor - src/share/classes/com/sun/inputmethods/internal/thaiim/resources/DisplayNames.properties ! 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 - src/share/classes/javax/swing/text/html/parser/html32.bdtd ! test/java/util/ResourceBundle/Bug4168625Test.java Changeset: 3df25d0680f3 Author: weijun Date: 2010-06-17 13:46 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3df25d0680f3 6959292: regression: cannot login if session key and preauth does not use the same etype Reviewed-by: xuelei, valeriep ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/W83.java Changeset: c995607e7719 Author: mchung Date: 2010-06-16 23:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c995607e7719 6961408: test/java/util/logging/ParentLoggersTest.java fails in samevm mode Summary: Check against the list of loggers added since the test begins to run Reviewed-by: dcubed ! test/ProblemList.txt ! test/java/util/logging/ParentLoggersTest.java Changeset: 1281181df71b Author: alanb Date: 2010-06-17 17:49 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1281181df71b 6395224: (so) SocketChannel writer blocked on large buffer is not preempted by close method (vista) Reviewed-by: chegar ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! src/windows/native/sun/nio/ch/nio_util.h ! test/ProblemList.txt ! test/java/nio/channels/AsyncCloseAndInterrupt.java Changeset: 5e4547833379 Author: sherman Date: 2010-06-17 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5e4547833379 6962067: TEST_BUG: Tests in java/util/zip/ZipFile leave file open Summary: Close zipfile and io stream when done Reviewed-by: alanb ! test/ProblemList.txt ! test/java/util/zip/InfoZip.java ! test/java/util/zip/ZipFile/Comment.java ! test/java/util/zip/ZipFile/CorruptedZipFiles.java ! test/java/util/zip/ZipFile/ManyEntries.java Changeset: 006e852b692e Author: ohair Date: 2010-06-17 14:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/006e852b692e 6869741: Integrate JAX-WS 2.2 and JAXB 2.2 in JDK 7 Reviewed-by: ramap ! make/docs/CORE_PKGS.gmk Changeset: 6c188df7bfef Author: alanb Date: 2010-06-18 16:16 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6c188df7bfef 4981129: (dc) DatagramSocket created by DatagramChannel does not provide sender info Reviewed-by: chegar ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java Changeset: 7526d0b9aab0 Author: mchung Date: 2010-06-18 09:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7526d0b9aab0 6961894: TEST_BUG: jdk_lang tests fail in samevm mode Summary: Fixed jdk_lang tests to run in samevm mode or mark to run in othervm Reviewed-by: alanb ! test/ProblemList.txt ! test/java/lang/System/ExitFinalizersAndJIT.java ! test/java/lang/Thread/GenerifyStackTraces.java ! test/java/lang/Thread/StackTraces.java ! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java ! test/java/lang/management/ManagementFactory/MXBeanProxyTest.java ! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest.java ! test/java/lang/management/MemoryMXBean/MemoryManagement.java ! test/java/lang/management/MemoryMXBean/Pending.java ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java ! test/java/lang/management/MemoryPoolMXBean/ThresholdTest.java ! test/java/lang/management/RuntimeMXBean/UpTime.java ! test/java/lang/management/ThreadMXBean/AllThreadIds.java ! test/java/lang/management/ThreadMXBean/DisableTest.java ! test/java/lang/management/ThreadMXBean/EnableTest.java ! test/java/lang/management/ThreadMXBean/FindDeadlocks.java ! test/java/lang/management/ThreadMXBean/FindMonitorDeadlock.java ! test/java/lang/management/ThreadMXBean/Locks.java ! test/java/lang/reflect/Proxy/Boxing.java ! test/java/lang/reflect/Proxy/ClassRestrictions.java ! test/java/lang/reflect/Proxy/returnTypes/Test.java Changeset: ac93014a4d78 Author: alanb Date: 2010-06-18 20:59 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ac93014a4d78 6962045: TEST_BUG: Tests in test/java/io/Serializable leave files open Reviewed-by: mchung ! test/ProblemList.txt ! test/java/io/Serializable/ClassCastExceptionDetail/Read.java ! test/java/io/Serializable/auditStreamSubclass/AuditStreamSubclass.java ! test/java/io/Serializable/backRefCNFException/Read.java ! test/java/io/Serializable/checkModifiers/CheckModifiers.java ! test/java/io/Serializable/classDescFlagConflict/Read.java ! test/java/io/Serializable/classDescHooks/ClassDescHooks.java ! test/java/io/Serializable/duplicateSerialFields/Test.java ! test/java/io/Serializable/enum/badResolve/Read.java ! test/java/io/Serializable/enum/constantSubclasses/Read.java ! test/java/io/Serializable/enum/missingConstant/Read.java ! test/java/io/Serializable/fieldTypeString/Read.java ! test/java/io/Serializable/illegalHandle/Test.java ! test/java/io/Serializable/longString/LongString.java ! test/java/io/Serializable/oldTests/AnnotateClass.java ! test/java/io/Serializable/oldTests/ArrayFields.java ! test/java/io/Serializable/oldTests/ArraysOfArrays.java ! test/java/io/Serializable/oldTests/BinaryTree.java ! test/java/io/Serializable/oldTests/CircularList.java ! test/java/io/Serializable/oldTests/SimpleArrays.java ! test/java/io/Serializable/oldTests/WritePrimitive.java ! test/java/io/Serializable/packageAccess/Test.java ! test/java/io/Serializable/parents/EvolvedClass.java ! test/java/io/Serializable/parents/OriginalClass.java ! test/java/io/Serializable/proxy/Basic.java ! test/java/io/Serializable/proxy/skipMissing/Read.java ! test/java/io/Serializable/proxy/skipMissing/Write.java ! test/java/io/Serializable/readObjectNoData/Read.java ! test/java/io/Serializable/skipWriteObject/Read.java ! test/java/io/Serializable/skippedObjCNFException/Read.java ! test/java/io/Serializable/stopCustomDeserialization/Read.java ! test/java/io/Serializable/unresolvedClassDesc/Read.java ! test/java/io/Serializable/unshared/Read.java ! test/java/io/Serializable/wrongReturnTypes/Read.java Changeset: 5919f0c72c0b Author: alanb Date: 2010-06-19 15:17 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5919f0c72c0b 6962419: TEST_BUG: java_io tests fails in samevm mode Reviewed-by: ohair, sherman ! test/ProblemList.txt ! test/java/io/BufferedReader/BigMark.java ! test/java/io/BufferedReader/ReadLineSync.java ! test/java/io/DataInputStream/OpsAfterClose.java ! test/java/io/DataInputStream/ReadFully.java ! test/java/io/File/DeleteOnExit.java ! test/java/io/File/DeleteOnExitNPE.java ! test/java/io/File/IsHidden.java ! test/java/io/FileInputStream/LeadingSlash.java ! test/java/io/InputStream/OpsAfterClose.java ! test/java/io/InputStream/ReadParams.java ! test/java/io/InputStreamReader/GrowAfterEOF.java ! test/java/io/ObjectInputStream/ResolveProxyClass.java ! test/java/io/RandomAccessFile/EOF.java ! test/java/io/RandomAccessFile/ParameterCheck.java ! test/java/io/RandomAccessFile/ReadLine.java ! test/java/io/RandomAccessFile/Seek.java ! test/java/io/RandomAccessFile/WriteBytesChars.java ! test/java/io/RandomAccessFile/WriteUTF.java ! test/java/io/RandomAccessFile/skipBytes/SkipBytes.java ! test/java/io/Reader/Skip.java ! test/java/io/Reader/SkipNegative.java ! test/java/io/StreamTokenizer/Comment.java ! test/java/io/readBytes/ReadBytesBounds.java Changeset: 43dfa39686a1 Author: ksrini Date: 2010-06-19 17:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/43dfa39686a1 6712743: pack200: should default to 150.7 pack format for classfiles without any classes. Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/java/util/jar/Pack200.java + test/tools/pack200/PackageVersionTest.java Changeset: a086a3d98711 Author: ohair Date: 2010-06-20 14:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a086a3d98711 6960853: Cleanup makefiles, remove unused vars etc. Reviewed-by: alanb ! make/common/shared/Defs-control.gmk ! make/netbeans/README ! make/netbeans/world/README ! make/netbeans/world/build.xml Changeset: 840265545bc3 Author: ohair Date: 2010-06-20 14:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/840265545bc3 6962617: Testcase changes, cleanup of problem list for jdk_tools targets Reviewed-by: alanb ! test/Makefile ! test/ProblemList.txt ! test/com/sun/jdi/PopAndInvokeTest.java ! test/com/sun/servicetag/JavaServiceTagTest1.java ! test/com/sun/servicetag/SystemRegistryTest.java ! test/com/sun/tools/attach/BasicTests.sh ! test/com/sun/tracing/BasicFunctionality.java ! test/sun/jvmstat/testlibrary/utils.sh ! test/sun/tools/jps/jps-Vvml_2.sh ! test/sun/tools/jps/jps-m_2.sh ! test/sun/tools/jstatd/jstatdDefaults.sh ! test/sun/tools/jstatd/jstatdExternalRegistry.sh ! test/sun/tools/jstatd/jstatdPort.sh ! test/sun/tools/jstatd/jstatdServerName.sh ! test/tools/jar/UpdateManifest.java ! test/tools/jar/index/MetaInf.java Changeset: 2366c2a5624c Author: mchung Date: 2010-06-20 19:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2366c2a5624c 6962478: Privacy page referenced in register_ja.html is incorrect Summary: Fix the URL for the privacy page Reviewed-by: ogino ! src/share/classes/com/sun/servicetag/resources/register_ja.html Changeset: fe7271b4aeea Author: mchung Date: 2010-06-21 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/fe7271b4aeea 6962815: support enable and disable of the servicetag's system registry for testing purpose Summary: Allow the system registry to be disabled/enabled at runtime Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/Registry.java ! test/com/sun/servicetag/FindServiceTags.java ! test/com/sun/servicetag/JavaServiceTagTest1.java ! test/com/sun/servicetag/SystemRegistryTest.java ! test/com/sun/servicetag/Util.java Changeset: 5438223734aa Author: lana Date: 2010-06-21 22:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5438223734aa Merge Changeset: 10a6319c9c15 Author: lana Date: 2010-06-29 22:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/10a6319c9c15 Merge Changeset: 861213cb02c3 Author: prr Date: 2010-06-29 16:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/861213cb02c3 6964882: 32 bit JDK does not build on 64 bit Windows platforms Reviewed-by: ohair, valeriep ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile Changeset: 511ddf6938ea Author: mikejwre Date: 2010-06-30 18:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/511ddf6938ea Merge From john.coomes at oracle.com Fri Jul 2 07:49:33 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Jul 2010 14:49:33 +0000 Subject: hg: jdk7/hotspot-rt/langtools: 21 new changesets Message-ID: <20100702145010.9F2A8476FE@hg.openjdk.java.net> Changeset: f0e3ec1f9d9f Author: jrose Date: 2010-05-01 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/f0e3ec1f9d9f 6939134: JSR 292 adjustments to method handle invocation Summary: split MethodHandle.invoke into invokeExact and invokeGeneric Reviewed-by: twisti ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.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/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! test/tools/javac/meth/InvokeDyn.java ! test/tools/javac/meth/InvokeMH.java Changeset: 2a28dcbef3a7 Author: jrose Date: 2010-05-13 20:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/2a28dcbef3a7 Merge Changeset: 005bec70ca27 Author: jrose Date: 2010-06-18 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/005bec70ca27 Merge ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.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/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! test/tools/javac/meth/InvokeDyn.java ! test/tools/javac/meth/InvokeMH.java Changeset: 9d02c4ce4275 Author: mikejwre Date: 2010-06-24 20:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/9d02c4ce4275 Added tag jdk7-b99 for changeset 005bec70ca27 ! .hgtags Changeset: 9a7c998bf2fc Author: darcy Date: 2010-06-02 19:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/9a7c998bf2fc 6933147: Provided new utility visitors supporting SourceVersion.RELEASE_7 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.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/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/javax/lang/model/element/ElementVisitor.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java + src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java + src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java + src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor6.java + src/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! src/share/classes/javax/lang/model/util/ElementScanner6.java + src/share/classes/javax/lang/model/util/ElementScanner7.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor6.java + src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java + src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java + src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java + src/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/share/sample/javac/processing/src/CheckNamesProcessor.java ! test/tools/javac/6402516/CheckLocalElements.java ! test/tools/javac/api/TestOperators.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/processing/model/6194785/T6194785.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 559c9a37d9f6 Author: jjg Date: 2010-06-03 17:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/559c9a37d9f6 6955264: add option to suppress Abort in Check.completionError Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java Changeset: 852d8bb356bc Author: darcy Date: 2010-06-03 19:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/852d8bb356bc 6519115: MirroredTypeException thrown but should be MirroredTypesException Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/javax/lang/model/type/MirroredTypeException.java ! src/share/classes/javax/lang/model/type/MirroredTypesException.java + test/tools/javac/processing/model/type/MirroredTypeEx/Plurality.java Changeset: b7fc560217d3 Author: jjg Date: 2010-06-04 14:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/b7fc560217d3 6958391: add vizant support to langtools build Reviewed-by: mcimadamore ! make/build.properties ! make/build.xml Changeset: d33b91f360fc Author: jjg Date: 2010-06-04 17:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d33b91f360fc 6958802: cleanup and doc langtools build.xml file Reviewed-by: ohair ! make/build.properties ! make/build.xml Changeset: 46cf751559ae Author: mcimadamore Date: 2010-06-10 09:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/46cf751559ae 6945418: Project Coin: Simplified Varargs Method Invocation Summary: Add new mandatory warning for unsafe vararg method declaration. Warning can be suppressed as usual (@SuppressWarnings("varargs")/-Xlint:-varargs) Reviewed-by: jjg, darcy ! 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/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/List.java ! test/tools/javac/varargs/6730476/T6730476a.java ! test/tools/javac/varargs/6806876/T6806876.out + test/tools/javac/varargs/warning/Warn4.java Changeset: f2fdd52e4e87 Author: jjg Date: 2010-06-10 16:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/f2fdd52e4e87 6944312: Potential rebranding issues in openjdk/langtools repository sources Reviewed-by: darcy ! src/share/classes/com/sun/javadoc/package.html ! src/share/classes/com/sun/mirror/overview.html ! src/share/classes/com/sun/source/tree/DisjointTypeTree.java ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/main/CommandLine.java ! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/apt/util/Bark.java ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/classfile/Annotation.java ! src/share/classes/com/sun/tools/classfile/AnnotationDefault_attribute.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/AttributeException.java ! src/share/classes/com/sun/tools/classfile/Attributes.java ! src/share/classes/com/sun/tools/classfile/CharacterRangeTable_attribute.java ! src/share/classes/com/sun/tools/classfile/ClassFile.java ! src/share/classes/com/sun/tools/classfile/ClassReader.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/classfile/CompilationID_attribute.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/ConstantPoolException.java ! src/share/classes/com/sun/tools/classfile/ConstantValue_attribute.java ! src/share/classes/com/sun/tools/classfile/DefaultAttribute.java ! src/share/classes/com/sun/tools/classfile/Deprecated_attribute.java ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/classfile/DescriptorException.java ! src/share/classes/com/sun/tools/classfile/EnclosingMethod_attribute.java ! src/share/classes/com/sun/tools/classfile/Exceptions_attribute.java ! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java ! src/share/classes/com/sun/tools/classfile/Field.java ! src/share/classes/com/sun/tools/classfile/InnerClasses_attribute.java ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/classfile/LineNumberTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LocalVariableTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LocalVariableTypeTable_attribute.java ! src/share/classes/com/sun/tools/classfile/Method.java ! src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/classfile/RuntimeAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeInvisibleAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeInvisibleParameterAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeParameterAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeVisibleAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeVisibleParameterAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/Signature.java ! src/share/classes/com/sun/tools/classfile/Signature_attribute.java ! src/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java ! src/share/classes/com/sun/tools/classfile/SourceFile_attribute.java ! src/share/classes/com/sun/tools/classfile/SourceID_attribute.java ! src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/share/classes/com/sun/tools/classfile/StackMap_attribute.java ! src/share/classes/com/sun/tools/classfile/Synthetic_attribute.java ! src/share/classes/com/sun/tools/classfile/Type.java ! src/share/classes/com/sun/tools/javac/Launcher.java ! src/share/classes/com/sun/tools/javac/Server.java ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/Formattable.java ! src/share/classes/com/sun/tools/javac/api/JavacScope.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/api/Messages.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/BoundKind.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/Lint.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Source.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/TargetType.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/code/TypeTags.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/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/AttrContextEnv.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.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/comp/Infer.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/Todo.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/file/FSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/RelativePath.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ByteCodes.java ! src/share/classes/com/sun/tools/javac/jvm/CRTFlags.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.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/jvm/Items.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/jvm/UninitializedType.java ! src/share/classes/com/sun/tools/javac/main/CommandLine.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/JavacOption.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/OptionName.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.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/model/JavacSourcePosition.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/nio/PathFileManager.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.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/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/Parser.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/parser/Token.java ! src/share/classes/com/sun/tools/javac/processing/AnnotationProcessingError.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/JavacProcessingEnvironment.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/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/Abort.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/ByteBuffer.java ! src/share/classes/com/sun/tools/javac/util/ClientCodeException.java ! src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java ! src/share/classes/com/sun/tools/javac/util/Constants.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/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/FatalError.java ! src/share/classes/com/sun/tools/javac/util/ForwardingDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.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/Options.java ! src/share/classes/com/sun/tools/javac/util/Pair.java ! src/share/classes/com/sun/tools/javac/util/Position.java ! src/share/classes/com/sun/tools/javac/util/PropagatedException.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.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/javac/util/Warner.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javah/InternalError.java ! src/share/classes/com/sun/tools/javah/JNI.java ! src/share/classes/com/sun/tools/javah/JavahFileManager.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/JavahTool.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Main.java ! src/share/classes/com/sun/tools/javah/Mangle.java ! src/share/classes/com/sun/tools/javah/NativeHeaderTool.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/com/sun/tools/javah/Util.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/BasicWriter.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java ! src/share/classes/com/sun/tools/javap/Context.java ! src/share/classes/com/sun/tools/javap/DisassemblerTool.java ! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java ! src/share/classes/com/sun/tools/javap/InternalError.java ! src/share/classes/com/sun/tools/javap/JavapFileManager.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/LocalVariableTableWriter.java ! src/share/classes/com/sun/tools/javap/LocalVariableTypeTableWriter.java ! src/share/classes/com/sun/tools/javap/Main.java ! src/share/classes/com/sun/tools/javap/Messages.java ! src/share/classes/com/sun/tools/javap/Options.java ! src/share/classes/com/sun/tools/javap/SourceWriter.java ! src/share/classes/com/sun/tools/javap/StackMapWriter.java ! src/share/classes/com/sun/tools/javap/TryBlockWriter.java ! src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! src/share/classes/javax/lang/model/overview.html ! test/tools/apt/mirror/declaration/pkg1/pkg2/package.html ! test/tools/javac/6948381/T6948381.java ! test/tools/javac/6948381/npe/A.java ! test/tools/javac/6948381/npe/B.java ! test/tools/javac/api/evalexpr/ByteArrayClassLoader.java ! test/tools/javac/api/evalexpr/CompileFromString.java ! test/tools/javac/api/evalexpr/MemoryFileManager.java ! test/tools/javac/generics/diamond/T6951833.java ! test/tools/javac/generics/typevars/T6880344.java ! test/tools/javac/varargs/warning/Warn4.java Changeset: 366a7b9b5627 Author: jjg Date: 2010-06-10 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/366a7b9b5627 6960407: Potential rebranding issues in openjdk/langtools repository sources Reviewed-by: darcy ! make/Makefile ! make/Makefile-classic ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TaskListener.java ! src/share/classes/com/sun/tools/doclets/formats/html/package.html ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Symtab.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 ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/share/classes/javax/tools/JavaFileManager.java Changeset: 224533455888 Author: jjg Date: 2010-06-11 07:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/224533455888 6877961: langtools build should allow more options when running jtreg Reviewed-by: mcimadamore ! make/build.xml Changeset: d1ea43cb71c1 Author: jjg Date: 2010-06-11 17:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d1ea43cb71c1 6958836: javadoc should support -Xmaxerrs and -Xmaxwarns Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties + test/tools/javadoc/6958836/Test.java + test/tools/javadoc/6958836/errs/Errors.java + test/tools/javadoc/6958836/warns/Warnings.java Changeset: 0840dd65b9e2 Author: jjg Date: 2010-06-16 16:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/0840dd65b9e2 6956638: JavacTask.generate does not generate all required files Reviewed-by: darcy Contributed-by: joshuamaurice at gmail.com + test/tools/javac/T6956638.java Changeset: 93e1975eea7a Author: lana Date: 2010-06-16 14:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/93e1975eea7a Merge ! test/tools/apt/mirror/declaration/pkg1/pkg2/package.html Changeset: e2b845fdc437 Author: lana Date: 2010-06-16 17:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/e2b845fdc437 Merge Changeset: 0ba1f80b73a5 Author: jjg Date: 2010-06-18 16:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/0ba1f80b73a5 6962540: langtools Makefile sets DEV_NULL incorrectly Reviewed-by: ohair ! make/Makefile Changeset: 4177f5bdd189 Author: jjg Date: 2010-06-18 21:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/4177f5bdd189 6961178: Allow doclet.xml to contain XML attributes Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.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/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/XMLNode.java Changeset: 4cca8d7ce6c1 Author: lana Date: 2010-06-21 22:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/4cca8d7ce6c1 Merge Changeset: d1d7595fa824 Author: lana Date: 2010-06-29 22:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d1d7595fa824 Merge ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.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/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/Names.java From jeremymanson at google.com Fri Jul 2 10:56:44 2010 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 2 Jul 2010 10:56:44 -0700 Subject: Second Code Review for WeakReference leak in the Logging API (6942989) In-Reply-To: <4C2A1B0A.8020605@oracle.com> References: <4C1BC843.60403@oracle.com> <4C22A8FC.7070008@oracle.com> <4C2A1B0A.8020605@oracle.com> Message-ID: Hi Dan, I don't know what AnonLoggerWeakRefTest looks like, but I am fairly confident that if you create a few million loggers and then drop down to one or two, the backing array of the Hashtable will still be bigger than it should be. Still, no real harm done - that's a fairly unusual situation. Jeremy On Tue, Jun 29, 2010 at 9:10 AM, Daniel D. Daugherty wrote: > Jeremy, > > Closing the loop on this part of the thread. I don't think there are > any more leaks left after the fix is applied. Here are the entries > I added the "public comments" section of the bug. For some reason > that bug is _still_ not showing up on the OpenJDK site. > >> === *Public Comments* >> ======================================================== >> I ran the AnonLoggerWeakRefLeak test with the following env variables: >> >> >> TESTJAVA=c:/work/shared/mirrors/jdks-win32/jdk/1.7.0/latest/binaries/windows-i586 >> TESTCLASSES=C:/cygwin/home/dcubed/Projects/6942989/XXX >> TESTVMOPTS=-showversion -client -Xmx32m >> TESTSRC=C:/cygwin/home/dcubed/Projects/6942989/XXX >> >> along with a 30 minute duration (1800 seconds) using JDK7-B99 bits >> (which does NOT have the fix). >> >> Here's the last 15 lines of the log files: >> >> $ tail -15 AnonLogger.jdk7-B99_30min.log >> INFO: instance_cnt = 1032505 >> INFO: instance_cnt = 1038305 >> INFO: instance_cnt = 1044005 >> INFO: instance_cnt = 1049705 >> INFO: jmap exited with exit code = 1 >> INFO: The likely reason is that AnonLoggerWeakRefLeak has finished >> running. >> INFO: increasing_cnt = 181 >> INFO: decreasing_cnt = 0 >> INFO: The instance count of java.lang.ref.WeakReference objects >> INFO: is always increasing. >> FAIL: This indicates that there is a memory leak. >> >> real ? ?18m10.296s >> user ? ?0m41.570s >> sys ? ? 0m46.442s >> >> $ tail -15 AnonLoggerWeakRefLeak.jdk7-B99_30min.log >> INFO: call count = 1044000 >> INFO: call count = 1045000 >> INFO: call count = 1046000 >> INFO: call count = 1047000 >> INFO: call count = 1048000 >> INFO: call count = 1049000 >> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space >> ? ? ? ?at java.util.Arrays.copyOf(Arrays.java:2239) >> ? ? ? ?at java.util.Arrays.copyOf(Arrays.java:2213) >> ? ? ? ?at java.util.ArrayList.grow(ArrayList.java:208) >> ? ? ? ?at java.util.ArrayList.ensureCapacity(ArrayList.java:182) >> ? ? ? ?at java.util.ArrayList.add(ArrayList.java:406) >> ? ? ? ?at java.util.logging.Logger.doSetParent(Logger.java:1401) >> ? ? ? ?at java.util.logging.Logger.getAnonymousLogger(Logger.java:374) >> ? ? ? ?at AnonLoggerWeakRefLeak.main(AnonLoggerWeakRefLeak.java:60) >> >> >> So it took a little over 18 minutes for a Client VM with a 32MB >> max heap size to throw an OOME with AnonLoggerWeakRefLeak. >> >> >> I ran the LoggerWeakRefLeak test with the same environment variables >> along with a 30 minute duration (1800 seconds) using JDK7-B99 bits >> (which does NOT have the fix). >> >> Here's the last 15 lines of the log files: >> >> $ tail -15 Logger.jdk7-B99_30min.log >> INFO: instance_cnt = 935705 >> INFO: instance_cnt = 938605 >> INFO: instance_cnt = 941205 >> INFO: instance_cnt = 943205 >> INFO: jmap exited with exit code = 1 >> INFO: The likely reason is that LoggerWeakRefLeak has finished running. >> INFO: increasing_cnt = 160 >> INFO: decreasing_cnt = 0 >> INFO: The instance count of java.lang.ref.WeakReference objects >> INFO: is always increasing. >> FAIL: This indicates that there is a memory leak. >> >> real ? ?16m47.690s >> user ? ?0m37.910s >> sys ? ? 0m40.002s >> >> $ tail -15 LoggerWeakRefLeak.jdk7-B99_30min.log >> INFO: call count = 881000 >> INFO: call count = 882000 >> INFO: call count = 883000 >> INFO: call count = 884000 >> INFO: call count = 885000 >> INFO: call count = 886000 >> INFO: call count = 887000 >> INFO: call count = 888000 >> INFO: call count = 889000 >> INFO: call count = 890000 >> INFO: call count = 891000 >> INFO: call count = 892000 >> INFO: call count = 893000 >> INFO: call count = 894000 >> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space >> >> >> So it took a little less than 17 minutes for a Client VM with a 32MB >> max heap size to throw an OOME with LoggerWeakRefLeak. >> >> *** (#1 of 3): 2010-06-28 22:45:03 GMT+00:00 daniel.daugherty at oracle.com >> *** Last Edit: 2010-06-28 22:57:39 GMT+00:00 daniel.daugherty at oracle.com >> >> I ran the AnonLoggerWeakRefLeak test with the same environment >> variables for a 60 minute duration using the fixed bits from >> JPRT. Here are the last 15 lines of each log (much less >> interesting info): >> >> $ tail -15 AnonLogger.jdk7-B100+_60min.log >> INFO: instance_cnt = 5801 >> INFO: instance_cnt = 5901 >> INFO: instance_cnt = 5701 >> INFO: instance_cnt = 5601 >> INFO: jmap exited with exit code = 1 >> INFO: The likely reason is that AnonLoggerWeakRefLeak has finished >> running. >> INFO: increasing_cnt = 227 >> INFO: decreasing_cnt = 383 >> INFO: The instance count of java.lang.ref.WeakReference objects >> INFO: is both increasing and decreasing. >> PASS: This indicates that there is not a memory leak. >> >> real ? ?60m5.099s >> user ? ?2m18.882s >> sys ? ? 2m31.127s >> >> $ tail -15 AnonLoggerWeakRefLeak.jdk7-B100+_60min.log >> INFO: call count = 3484000 >> INFO: call count = 3485000 >> INFO: call count = 3486000 >> INFO: call count = 3487000 >> INFO: call count = 3488000 >> INFO: call count = 3489000 >> INFO: call count = 3490000 >> INFO: call count = 3491000 >> INFO: call count = 3492000 >> INFO: call count = 3493000 >> INFO: call count = 3494000 >> INFO: call count = 3495000 >> INFO: call count = 3496000 >> INFO: call count = 3497000 >> INFO: final loop count = 3497200 >> >> >> I ran the LoggerWeakRefLeak test with the same environment >> variables for a 60 minute duration using the fixed bits from >> JPRT. Here are the last 15 lines of each log (much less >> interesting info): >> >> $ tail -15 Logger.jdk7-B100+_60min.log >> INFO: instance_cnt = 1813 >> INFO: instance_cnt = 1638 >> INFO: instance_cnt = 1514 >> INFO: instance_cnt = 1511 >> INFO: jmap exited with exit code = 1 >> INFO: The likely reason is that LoggerWeakRefLeak has finished running. >> INFO: increasing_cnt = 293 >> INFO: decreasing_cnt = 318 >> INFO: The instance count of java.lang.ref.WeakReference objects >> INFO: is both increasing and decreasing. >> PASS: This indicates that there is not a memory leak. >> >> real ? ?60m6.783s >> user ? ?2m20.592s >> sys ? ? 2m31.997s >> >> $ tail -15 LoggerWeakRefLeak.jdk7-B100+_60min.log >> INFO: call count = 3502000 >> INFO: call count = 3503000 >> INFO: call count = 3504000 >> INFO: call count = 3505000 >> INFO: call count = 3506000 >> INFO: call count = 3507000 >> INFO: call count = 3508000 >> INFO: call count = 3509000 >> INFO: call count = 3510000 >> INFO: call count = 3511000 >> INFO: call count = 3512000 >> INFO: call count = 3513000 >> INFO: call count = 3514000 >> INFO: call count = 3515000 >> INFO: final loop count = 3515800 >> >> *** (#2 of 3): 2010-06-29 01:46:49 GMT+00:00 daniel.daugherty at oracle.com >> >> I ran the AnonLoggerWeakRefLeak test with the same environment >> variables for a 12 hour duration using the fixed bits from JPRT. >> For this run I saved the "Total" line from the jmap output from >> every 10th sample: >> >> $ diff ../AnonLoggerWeakRefLeak.sh AnonLoggerWeakRefLeak.sh >> 161a162 >> >>>> >>>> > > "$TEST_NAME.totals" >>>> >> >> 225a227,233 >> >>> >>> > > set +e >>> > mod=`expr "$loop_cnt" % 10` >>> > set -e >>> > if [ "$mod" = 0 ]; then >>> > tail -1 "$TEST_NAME.jmap" >> "$TEST_NAME.totals" >>> > fi >>> >> >> Here is an analysis of the .totals data: >> >> $ sh analyze_totals < AnonLoggerWeakRefLeak.totals >> ? ? ? ? ?#objs ? ? ?#bytes >> first: ? ?30537 ? ? 2243648 >> lo: ? ? ? 30537 ? ? 2243648 >> hi: ? ? ? 57072 ? ? 3197904 >> last: ? ? 35676 ? ? 2882488 >> avg: ? ? ?36853 ? ? 2929982 >> # samples: 647 >> >> The first sample is also the lowest set of values which isn't >> a surprise given that the first sample is taken shortly after >> the target program has started running. The hi value occurred >> in sample #269 of 647 and the last sample was below the average. >> This data indicates that the values are both rising and falling >> over time which does not indicate any more memory leaks. >> >> >> >> I also ran the LoggerWeakRefLeak test with the same environment >> variables for a 12 hour duration using the fixed bits from JPRT. >> For this run I saved the "Total" line from the jmap output from >> every 10th sample: >> >> $ diff ../LoggerWeakRefLeak.sh LoggerWeakRefLeak.sh >> 161a162 >> >>>> >>>> > > "$TEST_NAME.totals" >>>> >> >> 225a227,233 >> >>> >>> > > set +e >>> > mod=`expr "$loop_cnt" % 10` >>> > set -e >>> > if [ "$mod" = 0 ]; then >>> > tail -1 "$TEST_NAME.jmap" >> "$TEST_NAME.totals" >>> > fi >>> >> >> Here is an analysis of the .totals data: >> >> $ sh analyze_totals < LoggerWeakRefLeak.totals >> ? ? ? ? ?#objs ? ? ?#bytes >> first: ? ?48957 ? ? 2832648 >> lo: ? ? ? 48957 ? ? 2832648 >> hi: ? ? ?148299 ? ? 6299016 >> last: ? ?133173 ? ? 5451032 >> avg: ? ? 137578 ? ? 5608654 >> # samples: 647 >> >> The first sample is also the lowest set of values which isn't >> a surprise given that the first sample is taken shortly after >> the target program has started running. The hi value occurred >> in sample #76 of 647 and the last sample was below the average. >> This data indicates that the values are both rising and falling >> over time which does not indicate any more memory leaks. >> >> *** (#3 of 3): 2010-06-29 15:59:39 GMT+00:00 daniel.daugherty at oracle.com > > > Please let me know if the fix is not working for you in your > environment at Google. > > Dan > > > On 6/23/2010 6:38 PM, Daniel D. Daugherty wrote: >> >> On 6/23/2010 12:38 PM, Jeremy Manson wrote: >>> >>> Hi Daniel, >>> >>> I'm sorry I missed this (I heavily filter these lists, and check rarely). >>> >> >> This time I specifically left you on the "To" list rather than >> editing down to just the list aliases. >> >> >>> My main feeling is that you are missing a good bet by not >>> reconstructing the Hashtable in LogManager and the ArrayList in Logger >>> every so often when you remove the loggers. ?In a test case where >>> there are a LOT of short-lived loggers, the backing array for the >>> Hashtable can get very big. ?It is permanent, and doesn't go anywhere. >>> ?You can end up with a lot of extra memory lying around that way. >>> >> >> It's possible that is a good bet. However, that wasn't mentioned >> as one of the issues in either bug report (I think) so I didn't >> write a test for that. >> >> >>> Specifically, when I didn't reconstruct those data structures, the >>> test case listed in the bug (where it just creates lots and lots of >>> anonymous loggers) killed the Java instance with an OOM, even if I >>> *did* clean up the weakreferences to the loggers. >>> >> >> I'll create a variant of the anon logger test that I put in the >> changeset and checkout if I can kill the Java instance with an OOM. >> I'll keep you posted. >> >> >>> I'm assuming you have a customer waiting for this - if that is similar >>> to their usage pattern, this fix may not fix their problem. >>> >> >> Thanks for the heads up. The JDK6 version of the fix hasn't been tested >> by the customer yet so you might be right. >> >> >>> You obviously don't want to rebuild those structures every time, >>> though. ?What I did in my change was to reconstruct the backing data >>> structures every time ~as many loggers were collected as were present >>> in the data structure. >>> >> >> Yup. I caught that part of the rebuild algorithm. It's just that the >> reason for doing the rebuild didn't jump out at me. >> >> Dan >> >> >>> Jeremy >>> >>> On Fri, Jun 18, 2010 at 12:25 PM, Daniel D. Daugherty >>> wrote: >>> >>>> >>>> Greetings, >>>> >>>> I have a new version of my fix for the WeakReference leak in the >>>> Logging API done. This version uses ReferenceQueues; thanks to Eamonn >>>> McManus, Jeremy Manson and Tony Printezis for their insights on using >>>> ReferenceQueues. Here's a pointer to Tony's paper for background info: >>>> >>>> ? http://java.sun.com/developer/technicalArticles/javase/finalization/ >>>> >>>> This version also has limits on the number of dead Loggers that are >>>> cleaned up per call; thanks to Alan Bateman for politely pushing me in >>>> that direction. >>>> >>>> The webrev is again relative to OpenJDK7, but the bug is escalated so >>>> the fix will be backported to the JDK6-Update train. So again, I'll >>>> need a minimum of two code reviewers. >>>> >>>> Here is the URL for the webrev: >>>> >>>> ? http://cr.openjdk.java.net/~dcubed/6942989-webrev/1/ >>>> >>>> Thanks, in advance, for any reviews. >>>> >>>> Dan >>>> >>>> >>>> >> > From daniel.daugherty at oracle.com Fri Jul 2 12:55:25 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 02 Jul 2010 13:55:25 -0600 Subject: Second Code Review for WeakReference leak in the Logging API (6942989) In-Reply-To: References: <4C1BC843.60403@oracle.com> <4C22A8FC.7070008@oracle.com> <4C2A1B0A.8020605@oracle.com> Message-ID: <4C2E442D.2040509@oracle.com> On 7/2/2010 11:56 AM, Jeremy Manson wrote: > Hi Dan, > > I don't know what AnonLoggerWeakRefTest looks like, Check out the webrevs in the review requests. I included the tests in the those reviews. > but I am fairly > confident that if you create a few million loggers and then drop down > to one or two, the backing array of the Hashtable will still be bigger > than it should be. > Possibly. I just wanted to confirm that we weren't leaking and I think I've confirmed that. > Still, no real harm done - that's a fairly unusual situation. > Agreed. Dan > Jeremy > > On Tue, Jun 29, 2010 at 9:10 AM, Daniel D. Daugherty > wrote: > >> Jeremy, >> >> Closing the loop on this part of the thread. I don't think there are >> any more leaks left after the fix is applied. Here are the entries >> I added the "public comments" section of the bug. For some reason >> that bug is _still_ not showing up on the OpenJDK site. >> >> >>> === *Public Comments* >>> ======================================================== >>> I ran the AnonLoggerWeakRefLeak test with the following env variables: >>> >>> >>> TESTJAVA=c:/work/shared/mirrors/jdks-win32/jdk/1.7.0/latest/binaries/windows-i586 >>> TESTCLASSES=C:/cygwin/home/dcubed/Projects/6942989/XXX >>> TESTVMOPTS=-showversion -client -Xmx32m >>> TESTSRC=C:/cygwin/home/dcubed/Projects/6942989/XXX >>> >>> along with a 30 minute duration (1800 seconds) using JDK7-B99 bits >>> (which does NOT have the fix). >>> >>> Here's the last 15 lines of the log files: >>> >>> $ tail -15 AnonLogger.jdk7-B99_30min.log >>> INFO: instance_cnt = 1032505 >>> INFO: instance_cnt = 1038305 >>> INFO: instance_cnt = 1044005 >>> INFO: instance_cnt = 1049705 >>> INFO: jmap exited with exit code = 1 >>> INFO: The likely reason is that AnonLoggerWeakRefLeak has finished >>> running. >>> INFO: increasing_cnt = 181 >>> INFO: decreasing_cnt = 0 >>> INFO: The instance count of java.lang.ref.WeakReference objects >>> INFO: is always increasing. >>> FAIL: This indicates that there is a memory leak. >>> >>> real 18m10.296s >>> user 0m41.570s >>> sys 0m46.442s >>> >>> $ tail -15 AnonLoggerWeakRefLeak.jdk7-B99_30min.log >>> INFO: call count = 1044000 >>> INFO: call count = 1045000 >>> INFO: call count = 1046000 >>> INFO: call count = 1047000 >>> INFO: call count = 1048000 >>> INFO: call count = 1049000 >>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space >>> at java.util.Arrays.copyOf(Arrays.java:2239) >>> at java.util.Arrays.copyOf(Arrays.java:2213) >>> at java.util.ArrayList.grow(ArrayList.java:208) >>> at java.util.ArrayList.ensureCapacity(ArrayList.java:182) >>> at java.util.ArrayList.add(ArrayList.java:406) >>> at java.util.logging.Logger.doSetParent(Logger.java:1401) >>> at java.util.logging.Logger.getAnonymousLogger(Logger.java:374) >>> at AnonLoggerWeakRefLeak.main(AnonLoggerWeakRefLeak.java:60) >>> >>> >>> So it took a little over 18 minutes for a Client VM with a 32MB >>> max heap size to throw an OOME with AnonLoggerWeakRefLeak. >>> >>> >>> I ran the LoggerWeakRefLeak test with the same environment variables >>> along with a 30 minute duration (1800 seconds) using JDK7-B99 bits >>> (which does NOT have the fix). >>> >>> Here's the last 15 lines of the log files: >>> >>> $ tail -15 Logger.jdk7-B99_30min.log >>> INFO: instance_cnt = 935705 >>> INFO: instance_cnt = 938605 >>> INFO: instance_cnt = 941205 >>> INFO: instance_cnt = 943205 >>> INFO: jmap exited with exit code = 1 >>> INFO: The likely reason is that LoggerWeakRefLeak has finished running. >>> INFO: increasing_cnt = 160 >>> INFO: decreasing_cnt = 0 >>> INFO: The instance count of java.lang.ref.WeakReference objects >>> INFO: is always increasing. >>> FAIL: This indicates that there is a memory leak. >>> >>> real 16m47.690s >>> user 0m37.910s >>> sys 0m40.002s >>> >>> $ tail -15 LoggerWeakRefLeak.jdk7-B99_30min.log >>> INFO: call count = 881000 >>> INFO: call count = 882000 >>> INFO: call count = 883000 >>> INFO: call count = 884000 >>> INFO: call count = 885000 >>> INFO: call count = 886000 >>> INFO: call count = 887000 >>> INFO: call count = 888000 >>> INFO: call count = 889000 >>> INFO: call count = 890000 >>> INFO: call count = 891000 >>> INFO: call count = 892000 >>> INFO: call count = 893000 >>> INFO: call count = 894000 >>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space >>> >>> >>> So it took a little less than 17 minutes for a Client VM with a 32MB >>> max heap size to throw an OOME with LoggerWeakRefLeak. >>> >>> *** (#1 of 3): 2010-06-28 22:45:03 GMT+00:00 daniel.daugherty at oracle.com >>> *** Last Edit: 2010-06-28 22:57:39 GMT+00:00 daniel.daugherty at oracle.com >>> >>> I ran the AnonLoggerWeakRefLeak test with the same environment >>> variables for a 60 minute duration using the fixed bits from >>> JPRT. Here are the last 15 lines of each log (much less >>> interesting info): >>> >>> $ tail -15 AnonLogger.jdk7-B100+_60min.log >>> INFO: instance_cnt = 5801 >>> INFO: instance_cnt = 5901 >>> INFO: instance_cnt = 5701 >>> INFO: instance_cnt = 5601 >>> INFO: jmap exited with exit code = 1 >>> INFO: The likely reason is that AnonLoggerWeakRefLeak has finished >>> running. >>> INFO: increasing_cnt = 227 >>> INFO: decreasing_cnt = 383 >>> INFO: The instance count of java.lang.ref.WeakReference objects >>> INFO: is both increasing and decreasing. >>> PASS: This indicates that there is not a memory leak. >>> >>> real 60m5.099s >>> user 2m18.882s >>> sys 2m31.127s >>> >>> $ tail -15 AnonLoggerWeakRefLeak.jdk7-B100+_60min.log >>> INFO: call count = 3484000 >>> INFO: call count = 3485000 >>> INFO: call count = 3486000 >>> INFO: call count = 3487000 >>> INFO: call count = 3488000 >>> INFO: call count = 3489000 >>> INFO: call count = 3490000 >>> INFO: call count = 3491000 >>> INFO: call count = 3492000 >>> INFO: call count = 3493000 >>> INFO: call count = 3494000 >>> INFO: call count = 3495000 >>> INFO: call count = 3496000 >>> INFO: call count = 3497000 >>> INFO: final loop count = 3497200 >>> >>> >>> I ran the LoggerWeakRefLeak test with the same environment >>> variables for a 60 minute duration using the fixed bits from >>> JPRT. Here are the last 15 lines of each log (much less >>> interesting info): >>> >>> $ tail -15 Logger.jdk7-B100+_60min.log >>> INFO: instance_cnt = 1813 >>> INFO: instance_cnt = 1638 >>> INFO: instance_cnt = 1514 >>> INFO: instance_cnt = 1511 >>> INFO: jmap exited with exit code = 1 >>> INFO: The likely reason is that LoggerWeakRefLeak has finished running. >>> INFO: increasing_cnt = 293 >>> INFO: decreasing_cnt = 318 >>> INFO: The instance count of java.lang.ref.WeakReference objects >>> INFO: is both increasing and decreasing. >>> PASS: This indicates that there is not a memory leak. >>> >>> real 60m6.783s >>> user 2m20.592s >>> sys 2m31.997s >>> >>> $ tail -15 LoggerWeakRefLeak.jdk7-B100+_60min.log >>> INFO: call count = 3502000 >>> INFO: call count = 3503000 >>> INFO: call count = 3504000 >>> INFO: call count = 3505000 >>> INFO: call count = 3506000 >>> INFO: call count = 3507000 >>> INFO: call count = 3508000 >>> INFO: call count = 3509000 >>> INFO: call count = 3510000 >>> INFO: call count = 3511000 >>> INFO: call count = 3512000 >>> INFO: call count = 3513000 >>> INFO: call count = 3514000 >>> INFO: call count = 3515000 >>> INFO: final loop count = 3515800 >>> >>> *** (#2 of 3): 2010-06-29 01:46:49 GMT+00:00 daniel.daugherty at oracle.com >>> >>> I ran the AnonLoggerWeakRefLeak test with the same environment >>> variables for a 12 hour duration using the fixed bits from JPRT. >>> For this run I saved the "Total" line from the jmap output from >>> every 10th sample: >>> >>> $ diff ../AnonLoggerWeakRefLeak.sh AnonLoggerWeakRefLeak.sh >>> 161a162 >>> >>> >>>>>>> "$TEST_NAME.totals" >>>>>>> >>> 225a227,233 >>> >>> >>>>>> set +e >>>>>> >>>>> mod=`expr "$loop_cnt" % 10` >>>>> set -e >>>>> if [ "$mod" = 0 ]; then >>>>> tail -1 "$TEST_NAME.jmap" >> "$TEST_NAME.totals" >>>>> fi >>>>> >>> Here is an analysis of the .totals data: >>> >>> $ sh analyze_totals < AnonLoggerWeakRefLeak.totals >>> #objs #bytes >>> first: 30537 2243648 >>> lo: 30537 2243648 >>> hi: 57072 3197904 >>> last: 35676 2882488 >>> avg: 36853 2929982 >>> # samples: 647 >>> >>> The first sample is also the lowest set of values which isn't >>> a surprise given that the first sample is taken shortly after >>> the target program has started running. The hi value occurred >>> in sample #269 of 647 and the last sample was below the average. >>> This data indicates that the values are both rising and falling >>> over time which does not indicate any more memory leaks. >>> >>> >>> >>> I also ran the LoggerWeakRefLeak test with the same environment >>> variables for a 12 hour duration using the fixed bits from JPRT. >>> For this run I saved the "Total" line from the jmap output from >>> every 10th sample: >>> >>> $ diff ../LoggerWeakRefLeak.sh LoggerWeakRefLeak.sh >>> 161a162 >>> >>> >>>>>>> "$TEST_NAME.totals" >>>>>>> >>> 225a227,233 >>> >>> >>>>>> set +e >>>>>> >>>>> mod=`expr "$loop_cnt" % 10` >>>>> set -e >>>>> if [ "$mod" = 0 ]; then >>>>> tail -1 "$TEST_NAME.jmap" >> "$TEST_NAME.totals" >>>>> fi >>>>> >>> Here is an analysis of the .totals data: >>> >>> $ sh analyze_totals < LoggerWeakRefLeak.totals >>> #objs #bytes >>> first: 48957 2832648 >>> lo: 48957 2832648 >>> hi: 148299 6299016 >>> last: 133173 5451032 >>> avg: 137578 5608654 >>> # samples: 647 >>> >>> The first sample is also the lowest set of values which isn't >>> a surprise given that the first sample is taken shortly after >>> the target program has started running. The hi value occurred >>> in sample #76 of 647 and the last sample was below the average. >>> This data indicates that the values are both rising and falling >>> over time which does not indicate any more memory leaks. >>> >>> *** (#3 of 3): 2010-06-29 15:59:39 GMT+00:00 daniel.daugherty at oracle.com >>> >> Please let me know if the fix is not working for you in your >> environment at Google. >> >> Dan >> >> >> On 6/23/2010 6:38 PM, Daniel D. Daugherty wrote: >> >>> On 6/23/2010 12:38 PM, Jeremy Manson wrote: >>> >>>> Hi Daniel, >>>> >>>> I'm sorry I missed this (I heavily filter these lists, and check rarely). >>>> >>>> >>> This time I specifically left you on the "To" list rather than >>> editing down to just the list aliases. >>> >>> >>> >>>> My main feeling is that you are missing a good bet by not >>>> reconstructing the Hashtable in LogManager and the ArrayList in Logger >>>> every so often when you remove the loggers. In a test case where >>>> there are a LOT of short-lived loggers, the backing array for the >>>> Hashtable can get very big. It is permanent, and doesn't go anywhere. >>>> You can end up with a lot of extra memory lying around that way. >>>> >>>> >>> It's possible that is a good bet. However, that wasn't mentioned >>> as one of the issues in either bug report (I think) so I didn't >>> write a test for that. >>> >>> >>> >>>> Specifically, when I didn't reconstruct those data structures, the >>>> test case listed in the bug (where it just creates lots and lots of >>>> anonymous loggers) killed the Java instance with an OOM, even if I >>>> *did* clean up the weakreferences to the loggers. >>>> >>>> >>> I'll create a variant of the anon logger test that I put in the >>> changeset and checkout if I can kill the Java instance with an OOM. >>> I'll keep you posted. >>> >>> >>> >>>> I'm assuming you have a customer waiting for this - if that is similar >>>> to their usage pattern, this fix may not fix their problem. >>>> >>>> >>> Thanks for the heads up. The JDK6 version of the fix hasn't been tested >>> by the customer yet so you might be right. >>> >>> >>> >>>> You obviously don't want to rebuild those structures every time, >>>> though. What I did in my change was to reconstruct the backing data >>>> structures every time ~as many loggers were collected as were present >>>> in the data structure. >>>> >>>> >>> Yup. I caught that part of the rebuild algorithm. It's just that the >>> reason for doing the rebuild didn't jump out at me. >>> >>> Dan >>> >>> >>> >>>> Jeremy >>>> >>>> On Fri, Jun 18, 2010 at 12:25 PM, Daniel D. Daugherty >>>> wrote: >>>> >>>> >>>>> Greetings, >>>>> >>>>> I have a new version of my fix for the WeakReference leak in the >>>>> Logging API done. This version uses ReferenceQueues; thanks to Eamonn >>>>> McManus, Jeremy Manson and Tony Printezis for their insights on using >>>>> ReferenceQueues. Here's a pointer to Tony's paper for background info: >>>>> >>>>> http://java.sun.com/developer/technicalArticles/javase/finalization/ >>>>> >>>>> This version also has limits on the number of dead Loggers that are >>>>> cleaned up per call; thanks to Alan Bateman for politely pushing me in >>>>> that direction. >>>>> >>>>> The webrev is again relative to OpenJDK7, but the bug is escalated so >>>>> the fix will be backported to the JDK6-Update train. So again, I'll >>>>> need a minimum of two code reviewers. >>>>> >>>>> Here is the URL for the webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/6942989-webrev/1/ >>>>> >>>>> Thanks, in advance, for any reviews. >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> From andrei.pangin at sun.com Sat Jul 3 08:58:47 2010 From: andrei.pangin at sun.com (andrei.pangin at sun.com) Date: Sat, 03 Jul 2010 15:58:47 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 5 new changesets Message-ID: <20100703155903.A81F147733@hg.openjdk.java.net> Changeset: d678e3277048 Author: kvn Date: 2010-06-28 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d678e3277048 6964479: widen normalization of small int and long values should be symmetric Summary: normalize widen value in xmeet() and xdual() methods for types Int and Long so the type meet will be symmetric. Reviewed-by: jrose ! src/share/vm/opto/type.cpp Changeset: 6027dddc26c6 Author: kvn Date: 2010-06-28 14:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6027dddc26c6 6677629: PhaseIterGVN::subsume_node() should call hash_delete() and add_users_to_worklist() Summary: Use replace_node() method instead of subsume_node(). Reviewed-by: jrose, never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/ifnode.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/macro.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/superword.cpp Changeset: 76efbe666d6c Author: kvn Date: 2010-06-29 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/76efbe666d6c 6964774: Adjust optimization flags setting Summary: Adjust performance flags settings. Reviewed-by: never, phh ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/runtime/arguments.cpp Changeset: fcbb92a1ab3b Author: jrose Date: 2010-06-29 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/fcbb92a1ab3b Merge ! src/share/vm/runtime/arguments.cpp Changeset: a00567c82f02 Author: coleenp Date: 2010-06-30 11:52 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a00567c82f02 Merge ! src/share/vm/runtime/arguments.cpp From karen.kinnear at sun.com Wed Jul 7 13:39:25 2010 From: karen.kinnear at sun.com (karen.kinnear at sun.com) Date: Wed, 07 Jul 2010 20:39:25 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20100707203930.8D56A4780D@hg.openjdk.java.net> Changeset: bfc89697cccb Author: acorn Date: 2010-07-02 17:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/bfc89697cccb 6964164: MonitorInUseLists leak of contended objects Summary: fix MonitorInUseLists memory leak and MonitorBound now works Reviewed-by: chrisphi, dice ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/thread.hpp Changeset: 5087ecc10458 Author: acorn Date: 2010-07-07 14:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5087ecc10458 Merge From David.Holmes at oracle.com Wed Jul 7 20:55:52 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 08 Jul 2010 13:55:52 +1000 Subject: bug 6693236 fix In-Reply-To: <4C27560A.3020505@univ-mlv.fr> References: <4C27560A.3020505@univ-mlv.fr> Message-ID: <4C354C48.9040808@oracle.com> Hi Remi, As noone has commented on this let me :) As the bug report describes: According to 4.11.1 paragraph of JVMS3 "A class file whose version number is greater than to 50.0 must be verified using the typechecker rules" So strictly speaking 1.6 was not compliant with the spec for practical reasons, but this non-compliance has been removed for Java 7. David Holmes R?mi Forax said the following on 06/27/10 23:45: > Hello all, > 1.7bb99 contains a patch for bug 6693236. > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/e40a3601bc1f > > This change has a big impact for all projects that does bytecode > instrumentation > because it requires to generate stackmap information for classfile 51.0. > > During 1.6 time frame, the command line flag FailOverToOldVerifier was added > to ease the transition. (see https://jdk.dev.java.net/verifier.html ) > Later it was decided to enable that flag by default for 1.6. > > The patch deactivates type inference for classfile 51.0, > I have no problem with that, > but it also deactivates FailOverToOldVerifier flag for classfile 51.0. > > I want to know if there a reason to deactivate the command line flag > or if it's just a side-effect of the fix. > > R?mi > > > > From David.Holmes at oracle.com Wed Jul 7 21:03:30 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 08 Jul 2010 14:03:30 +1000 Subject: JVM hangs beyond recovery In-Reply-To: References: <4BC8EE42.9070404@oracle.com> <4BC8F8D4.5020707@oracle.com> <4BCD0019.2020601@oracle.com> <4C0EC6B9.5020901@oracle.com> <4C0F5B21.8030707@oracle.com> <4C0F5CDA.7010500@oracle.com> <4C0F9051.7080203@oracle.com> <4C15E065.1000101@oracle.com> <4C1C1B1A.1020203@oracle.com> <4C1DA58C.2060700@oracle.com> Message-ID: <4C354E12.3080703@oracle.com> Stas Oskin said the following on 06/30/10 00:58: > > The main issue is that the stack trace always contains "??", which > make it impossible to find out what caused the deadlock. > > Just wanted to update that I tried kill -QUIT (or kill -3) and there > wasn't any thread dump as a result. > It seems the deadlock appears so deeply, that it basically hangs even > the basic routines. When the VM hangs during a safepoint there is no functionality available to you. The signal can't trigger the start of the thread to perform the dump because that thread must wait for the safepoint to end. > Again, if there any way to convert these ?? symbols in GDB dump to > actual function names, it would greatly help discovering the culprit. Some of the ??? may be coming from JIT compiled frames - these have no name but aren't responsible for the problem anyway. Other ??? may be coming from libraries with no symbol information and I'm afraid that trying to correlate addresses with names is an OS/loader issue not a Java/JVM one. > Will appreciate any idea on subject. Is there any LD debugging/tracing that might help? David Holmes > Thanks. From mailing at nmichael.de Thu Jul 8 00:21:27 2010 From: mailing at nmichael.de (Nicolas Michael) Date: Thu, 8 Jul 2010 07:21:27 GMT Subject: Safepointing & Locking issue Message-ID: Hi all, I have yesterday been investigating a performance problem with one of our applications where I observed some "strange" JVM behavior (which might be as expected, but I'm not sure...). It's a heavily multi-threaded Java application with about 300 threads, running on a 4 CPU Solaris x86 box using a 32bit HotSpot Client VM build 16.3-b01 (JDK 1.6.0_20-b02). It seems to make extensive use of synchronization and suffers badly from lock contention. Thread #10 (the VM Thread) eats close to one CPU, mostly doing lock deflations during safepoints in stacks like this: libjvm.so`__1cNObjectMonitorHis_busy6kM_i_+0x26 libjvm.so`__1cSObjectSynchronizerVdeflate_idle_monitors6F_v_+0x210 libjvm.so`__1cUSafepointSynchronizeQdo_cleanup_tasks6F_v_+0x19 libjvm.so`__1cUSafepointSynchronizeFbegin6F_v_+0x3d0 libjvm.so`__1cIVMThreadEloop6M_v_+0x26c libjvm.so`__1cIVMThreadDrun6M_v_+0x88 libjvm.so`java_start+0xf9 libc.so.1`_thr_setup+0x4e libc.so.1`_lwp_start 287 >From safepointing point-of-view, the process isn't doing much useful work -- it only got short periods of work interrupted by safepoints that take longer than the actual application runtime -- at a rate of 1709 safepoints per second (see below): Application time: 0.0000450 seconds Total time for which application threads were stopped: 0.0002397 seconds Application time: 0.0001607 seconds Total time for which application threads were stopped: 0.0002603 seconds Application time: 0.0000469 seconds Total time for which application threads were stopped: 0.0011530 seconds .. >From the perfdata statistics, I see sun.rt._sync_ContendedLockAttempts increasing by 12 / sec sun.rt._sync_Deflations increasing by 477 / sec sun.rt._sync_Inflations increasing by 477 / sec sun.rt._sync_Notifications increasing by 791 / sec sun.rt._sync_Parks increasing by 795 / sec sun.rt.safepoints increasing by 1709 / sec sun.rt.safepointTime is 0.82s and sun.rt.safepointSyncTime 0.15s per second. I guess we're using too much synchronization, Object.wait(ms) and notify() (or even notifyAll()) ... ;-) but I'm wondering whether it was "normal" to have that many safepoints and lock inflations/deflations because of that? My understanding was that safepoints are mainly caused by GC (not the case here) or deoptimization (should be visible with +LogCompilation, right? but nothing there either). Or bias revocation. Indeed, we do have some bias revocations (like this, see below), but this is at a much lower rate (only ~ 3.4 times per second): Revoking bias with potentially per-thread safepoint: Revoking bias of object 0x6df887d0 , mark 0x08ee3805 , type org.jacorb.poa.RequestQueue , prototype header 0x00000005 , allow rebias 0 , requesting thread 0x09065800 Revoked bias of currently-unlocked object Revoking bias by walking my own stack: Revoking bias of object 0x6df887c8 , mark 0x09065805 , type java.lang.Object , prototype header 0x00000005 , allow rebias 0 , requesting thread 0x09065800 Revoked bias of currently-locked object Inflating object 0x6df887c8 , mark 0x0906042a , type java.lang.Object Also, disabling biased locking has no effect on the magnitude of safepointing, so I concluded that safepointing must then be caused by lock inflation/deflation (which seems to be supported by the stack above). Afaik a lock is being inflated when the leight-weight locking algorithm can't acquire the lock immediately ("contention"). It will then fall back to heavy-weight locking (OS mutex?) and notify (wake up) all waiting threads (?). We have about 40 lock inflations per contended lock attempt (see the perfdata statistics above), does that mean there were (on average) 40 threads waiting on that contended lock? Since we have the same amount of deflations as we have inflations, I would assume that each heavy-weight lock is shortly after being "contended" reverted to a leight-weight lock again (during a safepoint in deflate_idle_monitors() as in the stack above??). But why? Couldn't it stay as a heavy-weight lock, instead of being deflated, only to be inflated shortly after again? In the example below, lock 0x96568a60 is being inflated, deflated, inflated again and then deflated again: Inflating object 0x96568a60 , mark 0x08677ffe , type org.jacorb.poa.RequestProcessor Deflating object 0x96568a60 , mark 0x08677ffe , type org.jacorb.poa.RequestProcessor Inflating object 0x96568a60 , mark 0x0918f4fe , type org.jacorb.poa.RequestProcessor Inflating object 0x79bceee8 , mark 0x08c0b662 , type java.lang.Object Inflating object 0x79bceeb0 , mark 0x0914e9ee , type org.jacorb.orb.ReplyReceiver Deflating object 0x79bceee8 , mark 0x08c0b662 , type java.lang.Object Deflating object 0x79bceeb0 , mark 0x0914e9ee , type org.jacorb.orb.ReplyReceiver Deflating object 0x96568a60 , mark 0x0918f4fe , type org.jacorb.poa.RequestProcessor I was just curious whether this is the intended behavior in case of lock contention, or whether we're seing some pathological strange thing happen here. Btw, I've also ran the workload with Hotspot 19.0-b03 from the latest JDK 7 build with the same results. Any comments appreciated! Thanks, Nick. From David.Holmes at oracle.com Thu Jul 8 00:51:00 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 08 Jul 2010 17:51:00 +1000 Subject: Safepointing & Locking issue In-Reply-To: References: Message-ID: <4C358364.7010600@oracle.com> Hi Nick, By default monitor deflation only occurs as a side-effect of a safepoint, so if a lot of safepoints are ocurring there is an underlying reason for that. It may be that using the latest VM and -XX:+PrintSafepointStatistics will shed some light on that. As to the inflate-deflate-inflate cycle you may indeed be seeing a pathological case, or it may be that too eager a cleanup of the inflated monitor leads to the re-inflation. Cheers, David Holmes Nicolas Michael said the following on 07/08/10 17:21: > Hi all, > > I have yesterday been investigating a performance problem with one of our > applications where I observed some "strange" JVM behavior (which might be as > expected, but I'm not sure...). > > It's a heavily multi-threaded Java application with about 300 threads, running > on a 4 CPU Solaris x86 box using a 32bit HotSpot Client VM build 16.3-b01 (JDK > 1.6.0_20-b02). It seems to make extensive use of synchronization and suffers > badly from lock contention. Thread #10 (the VM Thread) eats close to one CPU, > mostly doing lock deflations during safepoints in stacks like this: > > libjvm.so`__1cNObjectMonitorHis_busy6kM_i_+0x26 > libjvm.so`__1cSObjectSynchronizerVdeflate_idle_monitors6F_v_+0x210 > libjvm.so`__1cUSafepointSynchronizeQdo_cleanup_tasks6F_v_+0x19 > libjvm.so`__1cUSafepointSynchronizeFbegin6F_v_+0x3d0 > libjvm.so`__1cIVMThreadEloop6M_v_+0x26c > libjvm.so`__1cIVMThreadDrun6M_v_+0x88 > libjvm.so`java_start+0xf9 > libc.so.1`_thr_setup+0x4e > libc.so.1`_lwp_start > 287 > >>From safepointing point-of-view, the process isn't doing much useful work -- it > only got short periods of work interrupted by safepoints that take longer than > the actual application runtime -- at a rate of 1709 safepoints per second (see > below): > > Application time: 0.0000450 seconds > Total time for which application threads were stopped: 0.0002397 seconds > Application time: 0.0001607 seconds > Total time for which application threads were stopped: 0.0002603 seconds > Application time: 0.0000469 seconds > Total time for which application threads were stopped: 0.0011530 seconds > .. > >>From the perfdata statistics, I see > sun.rt._sync_ContendedLockAttempts increasing by 12 / sec > sun.rt._sync_Deflations increasing by 477 / sec > sun.rt._sync_Inflations increasing by 477 / sec > sun.rt._sync_Notifications increasing by 791 / sec > sun.rt._sync_Parks increasing by 795 / sec > sun.rt.safepoints increasing by 1709 / sec > sun.rt.safepointTime is 0.82s and sun.rt.safepointSyncTime 0.15s per second. > > I guess we're using too much synchronization, Object.wait(ms) and notify() (or > even notifyAll()) ... ;-) but I'm wondering whether it was "normal" to have that > many safepoints and lock inflations/deflations because of that? > > My understanding was that safepoints are mainly caused by GC (not the case here) > or deoptimization (should be visible with +LogCompilation, right? but nothing > there either). Or bias revocation. Indeed, we do have some bias revocations > (like this, see below), but this is at a much lower rate (only ~ 3.4 times per > second): > > > Revoking bias with potentially per-thread safepoint: > Revoking bias of object 0x6df887d0 , mark 0x08ee3805 , type > org.jacorb.poa.RequestQueue , prototype header 0x00000005 , allow rebias 0 , > requesting thread 0x09065800 > Revoked bias of currently-unlocked object > > Revoking bias by walking my own stack: > Revoking bias of object 0x6df887c8 , mark 0x09065805 , type java.lang.Object , > prototype header 0x00000005 , allow rebias 0 , requesting thread 0x09065800 > Revoked bias of currently-locked object > Inflating object 0x6df887c8 , mark 0x0906042a , type java.lang.Object > > Also, disabling biased locking has no effect on the magnitude of safepointing, > so I concluded that safepointing must then be caused by lock inflation/deflation > (which seems to be supported by the stack above). > > Afaik a lock is being inflated when the leight-weight locking algorithm can't > acquire the lock immediately ("contention"). It will then fall back to > heavy-weight locking (OS mutex?) and notify (wake up) all waiting threads (?). > We have about 40 lock inflations per contended lock attempt (see the perfdata > statistics above), does that mean there were (on average) 40 threads waiting on > that contended lock? > > Since we have the same amount of deflations as we have inflations, I would > assume that each heavy-weight lock is shortly after being "contended" reverted > to a leight-weight lock again (during a safepoint in deflate_idle_monitors() as > in the stack above??). But why? Couldn't it stay as a heavy-weight lock, instead > of being deflated, only to be inflated shortly after again? > > In the example below, lock 0x96568a60 is being inflated, deflated, inflated > again and then deflated again: > > > Inflating object 0x96568a60 , mark 0x08677ffe , type org.jacorb.poa.RequestProcessor > > Deflating object 0x96568a60 , mark 0x08677ffe , type org.jacorb.poa.RequestProcessor > > Inflating object 0x96568a60 , mark 0x0918f4fe , type org.jacorb.poa.RequestProcessor > > Inflating object 0x79bceee8 , mark 0x08c0b662 , type java.lang.Object > > Inflating object 0x79bceeb0 , mark 0x0914e9ee , type org.jacorb.orb.ReplyReceiver > > Deflating object 0x79bceee8 , mark 0x08c0b662 , type java.lang.Object > Deflating object 0x79bceeb0 , mark 0x0914e9ee , type org.jacorb.orb.ReplyReceiver > Deflating object 0x96568a60 , mark 0x0918f4fe , type org.jacorb.poa.RequestProcessor > > I was just curious whether this is the intended behavior in case of lock > contention, or whether we're seing some pathological strange thing happen here. > > Btw, I've also ran the workload with Hotspot 19.0-b03 from the latest JDK 7 > build with the same results. > > Any comments appreciated! > > Thanks, > Nick. > From forax at univ-mlv.fr Thu Jul 8 02:55:35 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 08 Jul 2010 11:55:35 +0200 Subject: bug 6693236 fix In-Reply-To: <4C354C48.9040808@oracle.com> References: <4C27560A.3020505@univ-mlv.fr> <4C354C48.9040808@oracle.com> Message-ID: <4C35A097.7060605@univ-mlv.fr> Hi David, I've no problem with the fact that the default configuration of jdk7 mandate to use of the split verifier. But the patch for bug 6693236 also make FailOverOldVerifier command line flag useless. I think it's an error. FailOverOldVerifier should "fail over the old verifier" and not be silently ignored. R?mi Le 08/07/2010 05:55, David Holmes a ?crit : > Hi Remi, > > As noone has commented on this let me :) > > As the bug report describes: > > According to 4.11.1 paragraph of JVMS3 > "A class file whose version number is greater than to 50.0 > must be verified using the typechecker rules" > > So strictly speaking 1.6 was not compliant with the spec for practical > reasons, but this non-compliance has been removed for Java 7. > > David Holmes > > R?mi Forax said the following on 06/27/10 23:45: >> Hello all, >> 1.7bb99 contains a patch for bug 6693236. >> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/e40a3601bc1f >> >> This change has a big impact for all projects that does bytecode >> instrumentation >> because it requires to generate stackmap information for classfile 51.0. >> >> During 1.6 time frame, the command line flag FailOverToOldVerifier >> was added >> to ease the transition. (see https://jdk.dev.java.net/verifier.html ) >> Later it was decided to enable that flag by default for 1.6. >> >> The patch deactivates type inference for classfile 51.0, >> I have no problem with that, >> but it also deactivates FailOverToOldVerifier flag for classfile 51.0. >> >> I want to know if there a reason to deactivate the command line flag >> or if it's just a side-effect of the fix. >> >> R?mi >> >> >> >> From David.Holmes at oracle.com Thu Jul 8 03:13:44 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 08 Jul 2010 20:13:44 +1000 Subject: bug 6693236 fix In-Reply-To: <4C35A097.7060605@univ-mlv.fr> References: <4C27560A.3020505@univ-mlv.fr> <4C354C48.9040808@oracle.com> <4C35A097.7060605@univ-mlv.fr> Message-ID: <4C35A4D8.8000307@oracle.com> R?mi Forax said the following on 07/08/10 19:55: > Hi David, > I've no problem with the fact that the default configuration of jdk7 > mandate to use of the split verifier. > But the patch for bug 6693236 also make FailOverOldVerifier command line > flag useless. > > I think it's an error. FailOverOldVerifier should "fail over the old > verifier" and not be silently ignored. For Java 7 you're not permitted to failover to the old verifier so the choices are to: a) silently ignore it b) ignore it but issue a warning c) refuse to start the VM I presume you would prefer (b) or (c)? David > > R?mi > > > Le 08/07/2010 05:55, David Holmes a ?crit : >> Hi Remi, >> >> As noone has commented on this let me :) >> >> As the bug report describes: >> >> According to 4.11.1 paragraph of JVMS3 >> "A class file whose version number is greater than to 50.0 >> must be verified using the typechecker rules" >> >> So strictly speaking 1.6 was not compliant with the spec for practical >> reasons, but this non-compliance has been removed for Java 7. >> >> David Holmes >> >> R?mi Forax said the following on 06/27/10 23:45: >>> Hello all, >>> 1.7bb99 contains a patch for bug 6693236. >>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/e40a3601bc1f >>> >>> This change has a big impact for all projects that does bytecode >>> instrumentation >>> because it requires to generate stackmap information for classfile 51.0. >>> >>> During 1.6 time frame, the command line flag FailOverToOldVerifier >>> was added >>> to ease the transition. (see https://jdk.dev.java.net/verifier.html ) >>> Later it was decided to enable that flag by default for 1.6. >>> >>> The patch deactivates type inference for classfile 51.0, >>> I have no problem with that, >>> but it also deactivates FailOverToOldVerifier flag for classfile 51.0. >>> >>> I want to know if there a reason to deactivate the command line flag >>> or if it's just a side-effect of the fix. >>> >>> R?mi >>> >>> >>> >>> > From forax at univ-mlv.fr Thu Jul 8 04:03:50 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 08 Jul 2010 13:03:50 +0200 Subject: bug 6693236 fix In-Reply-To: <4C35A4D8.8000307@oracle.com> References: <4C27560A.3020505@univ-mlv.fr> <4C354C48.9040808@oracle.com> <4C35A097.7060605@univ-mlv.fr> <4C35A4D8.8000307@oracle.com> Message-ID: <4C35B096.8070008@univ-mlv.fr> Le 08/07/2010 12:13, David Holmes a ?crit : > R?mi Forax said the following on 07/08/10 19:55: >> Hi David, >> I've no problem with the fact that the default configuration of jdk7 >> mandate to use of the split verifier. >> But the patch for bug 6693236 also make FailOverOldVerifier command >> line flag useless. >> >> I think it's an error. FailOverOldVerifier should "fail over the old >> verifier" and not be silently ignored. > > For Java 7 you're not permitted to failover to the old verifier so the > choices are to: > > a) silently ignore it > b) ignore it but issue a warning > c) refuse to start the VM > > I presume you would prefer (b) or (c)? > > David Hotspot has already some flags that modify the behavoir of the VM in a way that is not fully compatible with the Java spec. I believe that RelaxAccessControlCheck is one of those. FailOverOldVerifier is a flag that already exists and being able to fail over the old verifier will ease the transition (and debugging) for all developers that generate bytecode at runtime until they modify their code to generate stack map frames. R?mi > >> >> R?mi >> >> >> Le 08/07/2010 05:55, David Holmes a ?crit : >>> Hi Remi, >>> >>> As noone has commented on this let me :) >>> >>> As the bug report describes: >>> >>> According to 4.11.1 paragraph of JVMS3 >>> "A class file whose version number is greater than to 50.0 >>> must be verified using the typechecker rules" >>> >>> So strictly speaking 1.6 was not compliant with the spec for >>> practical reasons, but this non-compliance has been removed for Java 7. >>> >>> David Holmes >>> >>> R?mi Forax said the following on 06/27/10 23:45: >>>> Hello all, >>>> 1.7bb99 contains a patch for bug 6693236. >>>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/e40a3601bc1f >>>> >>>> This change has a big impact for all projects that does bytecode >>>> instrumentation >>>> because it requires to generate stackmap information for classfile >>>> 51.0. >>>> >>>> During 1.6 time frame, the command line flag FailOverToOldVerifier >>>> was added >>>> to ease the transition. (see https://jdk.dev.java.net/verifier.html ) >>>> Later it was decided to enable that flag by default for 1.6. >>>> >>>> The patch deactivates type inference for classfile 51.0, >>>> I have no problem with that, >>>> but it also deactivates FailOverToOldVerifier flag for classfile 51.0. >>>> >>>> I want to know if there a reason to deactivate the command line flag >>>> or if it's just a side-effect of the fix. >>>> >>>> R?mi >>>> >>>> >>>> >>>> >> From David.Holmes at oracle.com Thu Jul 8 04:21:42 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 08 Jul 2010 21:21:42 +1000 Subject: bug 6693236 fix In-Reply-To: <4C35B096.8070008@univ-mlv.fr> References: <4C27560A.3020505@univ-mlv.fr> <4C354C48.9040808@oracle.com> <4C35A097.7060605@univ-mlv.fr> <4C35A4D8.8000307@oracle.com> <4C35B096.8070008@univ-mlv.fr> Message-ID: <4C35B4C6.3010308@oracle.com> R?mi Forax said the following on 07/08/10 21:03: > Hotspot has already some flags that modify the behavoir of the VM > in a way that is not fully compatible with the Java spec. > I believe that RelaxAccessControlCheck is one of those. > > FailOverOldVerifier is a flag that already exists and > being able to fail over the old verifier will ease the transition > (and debugging) for all developers that generate bytecode at runtime > until they modify their code to generate stack map frames. My personal view is that they have had all of the Java 6 lifetime to make such changes and that Java 7 is saying time is up. But disabling the fail-over by default may not be unreasonable. Others may want to comment here. David From keith.mcguigan at oracle.com Thu Jul 8 05:07:25 2010 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Thu, 08 Jul 2010 08:07:25 -0400 Subject: bug 6693236 fix In-Reply-To: <4C35A4D8.8000307@oracle.com> References: <4C27560A.3020505@univ-mlv.fr> <4C354C48.9040808@oracle.com> <4C35A097.7060605@univ-mlv.fr> <4C35A4D8.8000307@oracle.com> Message-ID: <4C35BF7D.7000702@oracle.com> David Holmes wrote: > R?mi Forax said the following on 07/08/10 19:55: >> Hi David, >> I've no problem with the fact that the default configuration of jdk7 >> mandate to use of the split verifier. >> But the patch for bug 6693236 also make FailOverOldVerifier command >> line flag useless. >> >> I think it's an error. FailOverOldVerifier should "fail over the old >> verifier" and not be silently ignored. > > For Java 7 you're not permitted to failover to the old verifier so the > choices are to: > > a) silently ignore it > b) ignore it but issue a warning > c) refuse to start the VM > > I presume you would prefer (b) or (c)? At startup time, the JVM doesn't know what kind of classfiles it's going to load. It doesn't get fed a steady diet of same-versioned classfiles. Failover is still an option for classfiles with classfile version 50. So it's really not being ignored, it still enables failover for old classfile versions. Just not the new ones. -- - Keith From forax at univ-mlv.fr Thu Jul 8 06:13:30 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 08 Jul 2010 15:13:30 +0200 Subject: bug 6693236 fix In-Reply-To: <4C35BF7D.7000702@oracle.com> References: <4C27560A.3020505@univ-mlv.fr> <4C354C48.9040808@oracle.com> <4C35A097.7060605@univ-mlv.fr> <4C35A4D8.8000307@oracle.com> <4C35BF7D.7000702@oracle.com> Message-ID: <4C35CEFA.9060901@univ-mlv.fr> Le 08/07/2010 14:07, Keith McGuigan a ?crit : > David Holmes wrote: >> R?mi Forax said the following on 07/08/10 19:55: >>> Hi David, >>> I've no problem with the fact that the default configuration of jdk7 >>> mandate to use of the split verifier. >>> But the patch for bug 6693236 also make FailOverOldVerifier command >>> line flag useless. >>> >>> I think it's an error. FailOverOldVerifier should "fail over the old >>> verifier" and not be silently ignored. >> >> For Java 7 you're not permitted to failover to the old verifier so >> the choices are to: >> >> a) silently ignore it >> b) ignore it but issue a warning >> c) refuse to start the VM >> >> I presume you would prefer (b) or (c)? > > At startup time, the JVM doesn't know what kind of classfiles it's > going to load. It doesn't get fed a steady diet of same-versioned > classfiles. Failover is still an option for classfiles with classfile > version 50. > > So it's really not being ignored, it still enables failover for old > classfile versions. Just not the new ones. > > -- > - Keith Hi Keith, The problem is that bytecode transformations at runtime is a common trick, especially since the VM has an agent API (java.lanf.instrumentation). Such agents modify the bytecode at runtime by rewritting it. During the rewrite, the stackmap information are often discarded, because the agent was written before the release of 1.6 or because generating stackmap frames takes more time than using the old verifier. With this fix, these agent libraries will stop working with 1.7 classfiles and there is no workaround until the agent code is updated. R?mi From mailing at nmichael.de Thu Jul 8 06:12:51 2010 From: mailing at nmichael.de (Nicolas Michael) Date: Thu, 8 Jul 2010 13:12:51 GMT Subject: Safepointing & Locking issue Message-ID: Hi David and Dave, thanks a lot for your hints and background details on this issue. Adding -XX:+PrintSafepointStatistics to the options as suggested by David gives about 1200+ DeoptimizeFrame's per second in the LogFile: vmop [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count .. 168.976: DeoptimizeFrame [ 217 0 0 ] [ 0 0 0 0 0 ] 0 168.976: DeoptimizeFrame [ 217 0 0 ] [ 0 0 0 0 0 ] 0 168.978: DeoptimizeFrame [ 217 0 0 ] [ 0 0 0 0 0 ] 0 168.978: DeoptimizeFrame [ 217 0 0 ] [ 0 0 0 0 0 ] 0 168.978: DeoptimizeFrame [ 217 0 0 ] [ 0 0 0 0 0 ] 0 .. The output from the various switches (as also -XX:+LogCompilation) are a bit interleaved, but at this point in time (second 168ff) there are no other compilation related outputs around. So is there any way to further find out why a frame is being deoptimized? This would then lead so a safepoint, right? Oh, and yes, this JVM does have a JVMTI agent attached to it. But as far as I could find out until now, it should only register for GC start/end events (which are very rare in this process). With DTrace I just saw -- thanks to the really cool hotspot probes (some of them seem to be new, it's the first time I see that great level of detail!) -- that there are about 1000 Exceptions occurring per second ("ExceptionOccurred-entry") (but less than one "ThrowNew-entry" per second). I'm not sure how ThrowNew relates to ExceptionOccurred and what they are actually counting, and whether 1000+ of ExceptionOccurred is "a lot" (it seems quite high ;-) ). Could exceptions also cause deoptimization? Unfortunately we don't have a stand-alone easy to reproduce testcase for this. These are all the _sync_* that I get: sun.rt._sync_ContendedLockAttempts = 1625 sun.rt._sync_Deflations = 66821 sun.rt._sync_EmptyNotifications = 0 sun.rt._sync_FailedSpins = 0 sun.rt._sync_FutileWakeups = 56 sun.rt._sync_Inflations = 66870 sun.rt._sync_MonExtant = 6784 sun.rt._sync_MonInCirculation = 0 sun.rt._sync_MonScavenged = 0 sun.rt._sync_Notifications = 116109 sun.rt._sync_Parks = 117295 sun.rt._sync_PrivateA = 0 sun.rt._sync_PrivateB = 0 sun.rt._sync_SlowEnter = 0 sun.rt._sync_SlowExit = 0 sun.rt._sync_SlowNotify = 0 sun.rt._sync_SlowNotifyAll = 0 sun.rt._sync_SuccessfulSpins = 0 Thanks for pointing me to synchronizer.cpp, this sounds worth reading your comments there! Thanks, Nick. > -----Original Message----- > From: ext Dave Dice [mailto:dave.dice at oracle.com] > Sent: Donnerstag, 8. Juli 2010 13:57 > To: Nicolas Michael > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: Safepointing & Locking issue > > > On 2010-7-8, at 3:21 AM, Nicolas Michael wrote: > > > Hi all, > > > > I have yesterday been investigating a performance problem > with one of our > > applications where I observed some "strange" JVM behavior > (which might be as > > expected, but I'm not sure...). > > > > It's a heavily multi-threaded Java application with about > 300 threads, running > > on a 4 CPU Solaris x86 box using a 32bit HotSpot Client VM > build 16.3-b01 (JDK > > 1.6.0_20-b02). It seems to make extensive use of > synchronization and suffers > > badly from lock contention. Thread #10 (the VM Thread) eats > close to one CPU, > > mostly doing lock deflations during safepoints in stacks like this: > > > > libjvm.so`__1cNObjectMonitorHis_busy6kM_i_+0x26 > > > libjvm.so`__1cSObjectSynchronizerVdeflate_idle_monitors6F_v_+0x210 > > > libjvm.so`__1cUSafepointSynchronizeQdo_cleanup_tasks6F_v_+0x19 > > libjvm.so`__1cUSafepointSynchronizeFbegin6F_v_+0x3d0 > > libjvm.so`__1cIVMThreadEloop6M_v_+0x26c > > libjvm.so`__1cIVMThreadDrun6M_v_+0x88 > > libjvm.so`java_start+0xf9 > > libc.so.1`_thr_setup+0x4e > > libc.so.1`_lwp_start > > 287 > > > >> From safepointing point-of-view, the process isn't doing > much useful work -- it > > only got short periods of work interrupted by safepoints > that take longer than > > the actual application runtime -- at a rate of 1709 > safepoints per second (see > > below): > > > > Application time: 0.0000450 seconds > > Total time for which application threads were stopped: > 0.0002397 seconds > > Application time: 0.0001607 seconds > > Total time for which application threads were stopped: > 0.0002603 seconds > > Application time: 0.0000469 seconds > > Total time for which application threads were stopped: > 0.0011530 seconds > > .. > > > >> From the perfdata statistics, I see > > sun.rt._sync_ContendedLockAttempts increasing by 12 / sec > > sun.rt._sync_Deflations increasing by 477 / sec > > sun.rt._sync_Inflations increasing by 477 / sec > > sun.rt._sync_Notifications increasing by 791 / sec > > sun.rt._sync_Parks increasing by 795 / sec > > sun.rt.safepoints increasing by 1709 / sec > > sun.rt.safepointTime is 0.82s and sun.rt.safepointSyncTime > 0.15s per second. > > > > I guess we're using too much synchronization, > Object.wait(ms) and notify() (or > > even notifyAll()) ... ;-) but I'm wondering whether it was > "normal" to have that > > many safepoints and lock inflations/deflations because of that? > > > > My understanding was that safepoints are mainly caused by > GC (not the case here) > > or deoptimization (should be visible with +LogCompilation, > right? but nothing > > there either). Or bias revocation. Indeed, we do have some > bias revocations > > (like this, see below), but this is at a much lower rate > (only ~ 3.4 times per > > second): > > Hi Nick, > > Do you have test case that's easily packaged up? > > Inflation can be induced by a number of behaviors, such as > wait(), contention, deoptimization, bias revocation, JNI > monitor access, some hashCode actions, etc. By default, > however, we don't trigger stop-the-world safepoints to > deflate. Absent safepoints, the ultimate bound on the > number of objectmonitors in play is just the number of live > and dead objects in the heap. That is, there's no natural > back-pressure on the number of monitors. If the number of > monitors becomes too large the JVM can spend inordinate > amounts of time in deflate_idle_monitors() scanning, trying > to scavenge and deflate monitors, so there's both a time > problem and space problem (arguably the space problem drives > the time problem, but they manifest differently for customers). > > There's a day-one assumption in various pieces of code that > the object:monitor relationship is stable except over > potential safepoints. That simplifies many operations but > is the source of the issue you're seeing. Ultimately, it's > probably better to deflate on the fly and decouple safepoints > from deflation. (The old ExactVM implementation did just > that). It's relatively straight-forward, but touches a good > deal of code. If you're curious I've left more detailed > comments in synchronizer.cpp. > > In the mean time there are some palliative approaches under > consideration to (a) induce STW safepoints to bound the > number of extant monitors and in turn bound the cost of > deflate_idle_monitors, and (b) partition the monitors so we > only need scan those that were possibly inflated in the last > STW epoch. We also have code percolating through the > system that might cut down on some of the cases of inflation, > which is why a test case would be of interest -- to see if > the specific case you're running into might already be addressed. > > I vaguely recall adding a perfdata counter that reflects the > number of objectmonitors in the system. Where there any > other rt._sync_* variables visible in perfdata? > > Regards > Dave > > > > > > > > > Revoking bias with potentially per-thread safepoint: > > Revoking bias of object 0x6df887d0 , mark 0x08ee3805 , type > > org.jacorb.poa.RequestQueue , prototype header 0x00000005 , > allow rebias 0 , > > requesting thread 0x09065800 > > Revoked bias of currently-unlocked object > > > > Revoking bias by walking my own stack: > > Revoking bias of object 0x6df887c8 , mark 0x09065805 , type > java.lang.Object , > > prototype header 0x00000005 , allow rebias 0 , requesting > thread 0x09065800 > > Revoked bias of currently-locked object > > Inflating object 0x6df887c8 , mark 0x0906042a , type > java.lang.Object > > > > Also, disabling biased locking has no effect on the > magnitude of safepointing, > > so I concluded that safepointing must then be caused by > lock inflation/deflation > > (which seems to be supported by the stack above). > > > > Afaik a lock is being inflated when the leight-weight > locking algorithm can't > > acquire the lock immediately ("contention"). It will then > fall back to > > heavy-weight locking (OS mutex?) and notify (wake up) all > waiting threads (?). > > We have about 40 lock inflations per contended lock attempt > (see the perfdata > > statistics above), does that mean there were (on average) > 40 threads waiting on > > that contended lock? > > > > Since we have the same amount of deflations as we have > inflations, I would > > assume that each heavy-weight lock is shortly after being > "contended" reverted > > to a leight-weight lock again (during a safepoint in > deflate_idle_monitors() as > > in the stack above??). But why? Couldn't it stay as a > heavy-weight lock, instead > > of being deflated, only to be inflated shortly after again? > > > > In the example below, lock 0x96568a60 is being inflated, > deflated, inflated > > again and then deflated again: > > > > > > Inflating object 0x96568a60 , mark 0x08677ffe , type > org.jacorb.poa.RequestProcessor > > > > Deflating object 0x96568a60 , mark 0x08677ffe , type > org.jacorb.poa.RequestProcessor > > > > Inflating object 0x96568a60 , mark 0x0918f4fe , type > org.jacorb.poa.RequestProcessor > > > > Inflating object 0x79bceee8 , mark 0x08c0b662 , type > java.lang.Object > > > > Inflating object 0x79bceeb0 , mark 0x0914e9ee , type > org.jacorb.orb.ReplyReceiver > > > > Deflating object 0x79bceee8 , mark 0x08c0b662 , type > java.lang.Object > > Deflating object 0x79bceeb0 , mark 0x0914e9ee , type > org.jacorb.orb.ReplyReceiver > > Deflating object 0x96568a60 , mark 0x0918f4fe , type > org.jacorb.poa.RequestProcessor > > > > I was just curious whether this is the intended behavior in > case of lock > > contention, or whether we're seing some pathological > strange thing happen here. > > > > Btw, I've also ran the workload with Hotspot 19.0-b03 from > the latest JDK 7 > > build with the same results. > > > > Any comments appreciated! > > > > Thanks, > > Nick. > > > > From dave.dice at oracle.com Thu Jul 8 04:56:34 2010 From: dave.dice at oracle.com (Dave Dice) Date: Thu, 8 Jul 2010 07:56:34 -0400 Subject: Safepointing & Locking issue In-Reply-To: References: Message-ID: <2E6CDDE5-8A26-4C64-A625-2DBB4A7255E9@oracle.com> On 2010-7-8, at 3:21 AM, Nicolas Michael wrote: > Hi all, > > I have yesterday been investigating a performance problem with one of our > applications where I observed some "strange" JVM behavior (which might be as > expected, but I'm not sure...). > > It's a heavily multi-threaded Java application with about 300 threads, running > on a 4 CPU Solaris x86 box using a 32bit HotSpot Client VM build 16.3-b01 (JDK > 1.6.0_20-b02). It seems to make extensive use of synchronization and suffers > badly from lock contention. Thread #10 (the VM Thread) eats close to one CPU, > mostly doing lock deflations during safepoints in stacks like this: > > libjvm.so`__1cNObjectMonitorHis_busy6kM_i_+0x26 > libjvm.so`__1cSObjectSynchronizerVdeflate_idle_monitors6F_v_+0x210 > libjvm.so`__1cUSafepointSynchronizeQdo_cleanup_tasks6F_v_+0x19 > libjvm.so`__1cUSafepointSynchronizeFbegin6F_v_+0x3d0 > libjvm.so`__1cIVMThreadEloop6M_v_+0x26c > libjvm.so`__1cIVMThreadDrun6M_v_+0x88 > libjvm.so`java_start+0xf9 > libc.so.1`_thr_setup+0x4e > libc.so.1`_lwp_start > 287 > >> From safepointing point-of-view, the process isn't doing much useful work -- it > only got short periods of work interrupted by safepoints that take longer than > the actual application runtime -- at a rate of 1709 safepoints per second (see > below): > > Application time: 0.0000450 seconds > Total time for which application threads were stopped: 0.0002397 seconds > Application time: 0.0001607 seconds > Total time for which application threads were stopped: 0.0002603 seconds > Application time: 0.0000469 seconds > Total time for which application threads were stopped: 0.0011530 seconds > .. > >> From the perfdata statistics, I see > sun.rt._sync_ContendedLockAttempts increasing by 12 / sec > sun.rt._sync_Deflations increasing by 477 / sec > sun.rt._sync_Inflations increasing by 477 / sec > sun.rt._sync_Notifications increasing by 791 / sec > sun.rt._sync_Parks increasing by 795 / sec > sun.rt.safepoints increasing by 1709 / sec > sun.rt.safepointTime is 0.82s and sun.rt.safepointSyncTime 0.15s per second. > > I guess we're using too much synchronization, Object.wait(ms) and notify() (or > even notifyAll()) ... ;-) but I'm wondering whether it was "normal" to have that > many safepoints and lock inflations/deflations because of that? > > My understanding was that safepoints are mainly caused by GC (not the case here) > or deoptimization (should be visible with +LogCompilation, right? but nothing > there either). Or bias revocation. Indeed, we do have some bias revocations > (like this, see below), but this is at a much lower rate (only ~ 3.4 times per > second): Hi Nick, Do you have test case that's easily packaged up? Inflation can be induced by a number of behaviors, such as wait(), contention, deoptimization, bias revocation, JNI monitor access, some hashCode actions, etc. By default, however, we don't trigger stop-the-world safepoints to deflate. Absent safepoints, the ultimate bound on the number of objectmonitors in play is just the number of live and dead objects in the heap. That is, there's no natural back-pressure on the number of monitors. If the number of monitors becomes too large the JVM can spend inordinate amounts of time in deflate_idle_monitors() scanning, trying to scavenge and deflate monitors, so there's both a time problem and space problem (arguably the space problem drives the time problem, but they manifest differently for customers). There's a day-one assumption in various pieces of code that the object:monitor relationship is stable except over potential safepoints. That simplifies many operations but is the source of the issue you're seeing. Ultimately, it's probably better to deflate on the fly and decouple safepoints from deflation. (The old ExactVM implementation did just that). It's relatively straight-forward, but touches a good deal of code. If you're curious I've left more detailed comments in synchronizer.cpp. In the mean time there are some palliative approaches under consideration to (a) induce STW safepoints to bound the number of extant monitors and in turn bound the cost of deflate_idle_monitors, and (b) partition the monitors so we only need scan those that were possibly inflated in the last STW epoch. We also have code percolating through the system that might cut down on some of the cases of inflation, which is why a test case would be of interest -- to see if the specific case you're running into might already be addressed. I vaguely recall adding a perfdata counter that reflects the number of objectmonitors in the system. Where there any other rt._sync_* variables visible in perfdata? Regards Dave > > > Revoking bias with potentially per-thread safepoint: > Revoking bias of object 0x6df887d0 , mark 0x08ee3805 , type > org.jacorb.poa.RequestQueue , prototype header 0x00000005 , allow rebias 0 , > requesting thread 0x09065800 > Revoked bias of currently-unlocked object > > Revoking bias by walking my own stack: > Revoking bias of object 0x6df887c8 , mark 0x09065805 , type java.lang.Object , > prototype header 0x00000005 , allow rebias 0 , requesting thread 0x09065800 > Revoked bias of currently-locked object > Inflating object 0x6df887c8 , mark 0x0906042a , type java.lang.Object > > Also, disabling biased locking has no effect on the magnitude of safepointing, > so I concluded that safepointing must then be caused by lock inflation/deflation > (which seems to be supported by the stack above). > > Afaik a lock is being inflated when the leight-weight locking algorithm can't > acquire the lock immediately ("contention"). It will then fall back to > heavy-weight locking (OS mutex?) and notify (wake up) all waiting threads (?). > We have about 40 lock inflations per contended lock attempt (see the perfdata > statistics above), does that mean there were (on average) 40 threads waiting on > that contended lock? > > Since we have the same amount of deflations as we have inflations, I would > assume that each heavy-weight lock is shortly after being "contended" reverted > to a leight-weight lock again (during a safepoint in deflate_idle_monitors() as > in the stack above??). But why? Couldn't it stay as a heavy-weight lock, instead > of being deflated, only to be inflated shortly after again? > > In the example below, lock 0x96568a60 is being inflated, deflated, inflated > again and then deflated again: > > > Inflating object 0x96568a60 , mark 0x08677ffe , type org.jacorb.poa.RequestProcessor > > Deflating object 0x96568a60 , mark 0x08677ffe , type org.jacorb.poa.RequestProcessor > > Inflating object 0x96568a60 , mark 0x0918f4fe , type org.jacorb.poa.RequestProcessor > > Inflating object 0x79bceee8 , mark 0x08c0b662 , type java.lang.Object > > Inflating object 0x79bceeb0 , mark 0x0914e9ee , type org.jacorb.orb.ReplyReceiver > > Deflating object 0x79bceee8 , mark 0x08c0b662 , type java.lang.Object > Deflating object 0x79bceeb0 , mark 0x0914e9ee , type org.jacorb.orb.ReplyReceiver > Deflating object 0x96568a60 , mark 0x0918f4fe , type org.jacorb.poa.RequestProcessor > > I was just curious whether this is the intended behavior in case of lock > contention, or whether we're seing some pathological strange thing happen here. > > Btw, I've also ran the workload with Hotspot 19.0-b03 from the latest JDK 7 > build with the same results. > > Any comments appreciated! > > Thanks, > Nick. > From keith.mcguigan at oracle.com Thu Jul 8 06:52:05 2010 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Thu, 08 Jul 2010 09:52:05 -0400 Subject: bug 6693236 fix In-Reply-To: <4C35CEFA.9060901@univ-mlv.fr> References: <4C27560A.3020505@univ-mlv.fr> <4C354C48.9040808@oracle.com> <4C35A097.7060605@univ-mlv.fr> <4C35A4D8.8000307@oracle.com> <4C35BF7D.7000702@oracle.com> <4C35CEFA.9060901@univ-mlv.fr> Message-ID: <4C35D805.9070403@oracle.com> R?mi Forax wrote: > Hi Keith, > The problem is that bytecode transformations at runtime is a common trick, > especially since the VM has an agent API (java.lanf.instrumentation). > Such agents modify the bytecode at runtime by rewritting it. > During the rewrite, the stackmap information are often discarded, > because the agent was written before the release of 1.6 or > because generating stackmap frames takes more time than using > the old verifier. > > With this fix, these agent libraries will stop working with 1.7 classfiles > and there is no workaround until the agent code is updated. Hi R?mi, I understand the issues. The failover flag has been in place for years as a stopgap measure to let tools "catch up" to the new classfile format. The specification is quite clear that stackmaps are needed, so discarding them for convenience reasons isn't really an option (as far as the spec/JVM is concerned). In order to process classfiles with version >= 51, the tools must be updated to emit the correct stackmaps. Otherwise they're not generating valid classfiles. Tools that can't generate stackmaps for whatever reasons shouldn't modify classfiles with version 51, then, I would think. There is a workaround, though, if one does not care that modified classes are verifiable, and that is to disable verification with -Xverify:none. You can use that instead of the failover option but keep in mind that you're treading on dangerous territory. From https://jdk.dev.java.net/verifier.html: If you develop or use tools that manipulate Java byte code, such as profilers, loggers, and class file rewriters, your tools may not work correctly with the new StackMapTable attribute. The fall-back behavior allows the existing tools to still work for version 50 class files. However, the tools need to migrate to the new format eventually because the fall-back behavior may not be feasible to support in the future. Besides, you cannot take advantage of the improved verifier until your class files pass the type checking verifier. This is especially important if your applications are performance sensitive. -- - Keith -- - Keith From keith.mcguigan at oracle.com Thu Jul 8 06:58:07 2010 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Thu, 08 Jul 2010 09:58:07 -0400 Subject: Safepointing & Locking issue In-Reply-To: References: Message-ID: <4C35D96F.2030306@oracle.com> Nicolas Michael wrote: > With DTrace I just saw -- thanks to the really cool hotspot probes (some of them > seem to be new, it's the first time I see that great level of detail!) -- that > there are about 1000 Exceptions occurring per second ("ExceptionOccurred-entry") > (but less than one "ThrowNew-entry" per second). I'm not sure how ThrowNew > relates to ExceptionOccurred and what they are actually counting, and whether > 1000+ of ExceptionOccurred is "a lot" (it seems quite high ;-) ). Could > exceptions also cause deoptimization? The 'ExceptionOccurred-entry' and 'ThrowNew-entry' probes trace the corresponding JNI calls (from native code). ExceptionOccurred is used to query whether an exception occurred or not, so seeing it called 1000 times a second doesn't mean that there are 1000s of exceptions occurring. Such frequent queries are probably not great for performance either, but that's a different story. ThrowNew is called to actually throw an exception from native code, but that's not the only place where exceptions are thrown -- it's only when exceptions are thrown from native code using JNI. And in any case I don't think throwing exceptions necessarily leads to deoptimization and/or safepoints. -- - Keith From dave.dice at oracle.com Thu Jul 8 07:59:09 2010 From: dave.dice at oracle.com (Dave Dice) Date: Thu, 8 Jul 2010 10:59:09 -0400 Subject: Safepointing & Locking issue In-Reply-To: References: Message-ID: <64A4118A-8440-48B6-93D7-E388F68E14DC@oracle.com> Hi Nick, On 2010-7-8, at 9:12 AM, Nicolas Michael wrote: > Hi David and Dave, > > thanks a lot for your hints and background details on this issue. > > Adding -XX:+PrintSafepointStatistics to the options as suggested by David gives > about 1200+ DeoptimizeFrame's per second in the LogFile: > > vmop [threads: total initially_running > wait_to_block] [time: spin block sync cleanup vmop] page_trap_count > .. > 168.976: DeoptimizeFrame [ 217 0 0 > ] [ 0 0 0 0 0 ] 0 > 168.976: DeoptimizeFrame [ 217 0 0 > ] [ 0 0 0 0 0 ] 0 > 168.978: DeoptimizeFrame [ 217 0 0 > ] [ 0 0 0 0 0 ] 0 > 168.978: DeoptimizeFrame [ 217 0 0 > ] [ 0 0 0 0 0 ] 0 > 168.978: DeoptimizeFrame [ 217 0 0 > ] [ 0 0 0 0 0 ] 0 > .. I'll let our JIT friends lurking on the list comment, but incessant deopt, if that's actually the case, would be of interest. ... > > The output from the various switches (as also -XX:+LogCompilation) are a bit > interleaved, but at this point in time (second 168ff) there are no other > compilation related outputs around. So is there any way to further find out why > a frame is being deoptimized? This would then lead so a safepoint, right? > > Oh, and yes, this JVM does have a JVMTI agent attached to it. But as far as I > could find out until now, it should only register for GC start/end events (which > are very rare in this process). > > With DTrace I just saw -- thanks to the really cool hotspot probes (some of them > seem to be new, it's the first time I see that great level of detail!) -- that > there are about 1000 Exceptions occurring per second ("ExceptionOccurred-entry") > (but less than one "ThrowNew-entry" per second). I'm not sure how ThrowNew > relates to ExceptionOccurred and what they are actually counting, and whether > 1000+ of ExceptionOccurred is "a lot" (it seems quite high ;-) ). Could > exceptions also cause deoptimization? > > Unfortunately we don't have a stand-alone easy to reproduce testcase for this. > > These are all the _sync_* that I get: > > sun.rt._sync_ContendedLockAttempts = 1625 > sun.rt._sync_Deflations = 66821 > sun.rt._sync_EmptyNotifications = 0 > sun.rt._sync_FailedSpins = 0 > sun.rt._sync_FutileWakeups = 56 > sun.rt._sync_Inflations = 66870 > sun.rt._sync_MonExtant = 6784 > sun.rt._sync_MonInCirculation = 0 > sun.rt._sync_MonScavenged = 0 > sun.rt._sync_Notifications = 116109 > sun.rt._sync_Parks = 117295 > sun.rt._sync_PrivateA = 0 > sun.rt._sync_PrivateB = 0 > sun.rt._sync_SlowEnter = 0 > sun.rt._sync_SlowExit = 0 > sun.rt._sync_SlowNotify = 0 > sun.rt._sync_SlowNotifyAll = 0 > sun.rt._sync_SuccessfulSpins = 0 You've only got 6784 extant monitors, which is quite reasonable. (We over-provision somewhat to allow per-thread free lists of readily usable monitors -- this reduces contention on the central free list -- so the actually number of monitors in-use at any one time will have been much less than 6874). The monitor scan/scavenge costs should be dominated by and only a small fraction of the overhead to rendezvous for the safepoint. At the last safepoint you had 49 monitors actually in-use, which probably means you had about 49 threads blocked on wait() or contended monitor entry. Does that agree with what you know of the application? The inflation and deflation counts relative to the # of extant monitors suggests that monitors are circulating properly. So I don't see anything particular amiss in the data above. ... > > Thanks for pointing me to synchronizer.cpp, this sounds worth reading your > comments there! By all means feel free to ask questions. Regards Dave > > Thanks, > Nick. > > > >> -----Original Message----- >> From: ext Dave Dice [mailto:dave.dice at oracle.com] >> Sent: Donnerstag, 8. Juli 2010 13:57 >> To: Nicolas Michael >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: Safepointing & Locking issue >> >> >> On 2010-7-8, at 3:21 AM, Nicolas Michael wrote: >> >>> Hi all, >>> >>> I have yesterday been investigating a performance problem >> with one of our >>> applications where I observed some "strange" JVM behavior >> (which might be as >>> expected, but I'm not sure...). >>> >>> It's a heavily multi-threaded Java application with about >> 300 threads, running >>> on a 4 CPU Solaris x86 box using a 32bit HotSpot Client VM >> build 16.3-b01 (JDK >>> 1.6.0_20-b02). It seems to make extensive use of >> synchronization and suffers >>> badly from lock contention. Thread #10 (the VM Thread) eats >> close to one CPU, >>> mostly doing lock deflations during safepoints in stacks like this: >>> >>> libjvm.so`__1cNObjectMonitorHis_busy6kM_i_+0x26 >>> >> libjvm.so`__1cSObjectSynchronizerVdeflate_idle_monitors6F_v_+0x210 >>> >> libjvm.so`__1cUSafepointSynchronizeQdo_cleanup_tasks6F_v_+0x19 >>> libjvm.so`__1cUSafepointSynchronizeFbegin6F_v_+0x3d0 >>> libjvm.so`__1cIVMThreadEloop6M_v_+0x26c >>> libjvm.so`__1cIVMThreadDrun6M_v_+0x88 >>> libjvm.so`java_start+0xf9 >>> libc.so.1`_thr_setup+0x4e >>> libc.so.1`_lwp_start >>> 287 >>> >>>> From safepointing point-of-view, the process isn't doing >> much useful work -- it >>> only got short periods of work interrupted by safepoints >> that take longer than >>> the actual application runtime -- at a rate of 1709 >> safepoints per second (see >>> below): >>> >>> Application time: 0.0000450 seconds >>> Total time for which application threads were stopped: >> 0.0002397 seconds >>> Application time: 0.0001607 seconds >>> Total time for which application threads were stopped: >> 0.0002603 seconds >>> Application time: 0.0000469 seconds >>> Total time for which application threads were stopped: >> 0.0011530 seconds >>> .. >>> >>>> From the perfdata statistics, I see >>> sun.rt._sync_ContendedLockAttempts increasing by 12 / sec >>> sun.rt._sync_Deflations increasing by 477 / sec >>> sun.rt._sync_Inflations increasing by 477 / sec >>> sun.rt._sync_Notifications increasing by 791 / sec >>> sun.rt._sync_Parks increasing by 795 / sec >>> sun.rt.safepoints increasing by 1709 / sec >>> sun.rt.safepointTime is 0.82s and sun.rt.safepointSyncTime >> 0.15s per second. >>> >>> I guess we're using too much synchronization, >> Object.wait(ms) and notify() (or >>> even notifyAll()) ... ;-) but I'm wondering whether it was >> "normal" to have that >>> many safepoints and lock inflations/deflations because of that? >>> >>> My understanding was that safepoints are mainly caused by >> GC (not the case here) >>> or deoptimization (should be visible with +LogCompilation, >> right? but nothing >>> there either). Or bias revocation. Indeed, we do have some >> bias revocations >>> (like this, see below), but this is at a much lower rate >> (only ~ 3.4 times per >>> second): >> >> Hi Nick, >> >> Do you have test case that's easily packaged up? >> >> Inflation can be induced by a number of behaviors, such as >> wait(), contention, deoptimization, bias revocation, JNI >> monitor access, some hashCode actions, etc. By default, >> however, we don't trigger stop-the-world safepoints to >> deflate. Absent safepoints, the ultimate bound on the >> number of objectmonitors in play is just the number of live >> and dead objects in the heap. That is, there's no natural >> back-pressure on the number of monitors. If the number of >> monitors becomes too large the JVM can spend inordinate >> amounts of time in deflate_idle_monitors() scanning, trying >> to scavenge and deflate monitors, so there's both a time >> problem and space problem (arguably the space problem drives >> the time problem, but they manifest differently for customers). >> >> There's a day-one assumption in various pieces of code that >> the object:monitor relationship is stable except over >> potential safepoints. That simplifies many operations but >> is the source of the issue you're seeing. Ultimately, it's >> probably better to deflate on the fly and decouple safepoints >> from deflation. (The old ExactVM implementation did just >> that). It's relatively straight-forward, but touches a good >> deal of code. If you're curious I've left more detailed >> comments in synchronizer.cpp. >> >> In the mean time there are some palliative approaches under >> consideration to (a) induce STW safepoints to bound the >> number of extant monitors and in turn bound the cost of >> deflate_idle_monitors, and (b) partition the monitors so we >> only need scan those that were possibly inflated in the last >> STW epoch. We also have code percolating through the >> system that might cut down on some of the cases of inflation, >> which is why a test case would be of interest -- to see if >> the specific case you're running into might already be addressed. >> >> I vaguely recall adding a perfdata counter that reflects the >> number of objectmonitors in the system. Where there any >> other rt._sync_* variables visible in perfdata? >> >> Regards >> Dave >> >> >> >>> >>> >>> Revoking bias with potentially per-thread safepoint: >>> Revoking bias of object 0x6df887d0 , mark 0x08ee3805 , type >>> org.jacorb.poa.RequestQueue , prototype header 0x00000005 , >> allow rebias 0 , >>> requesting thread 0x09065800 >>> Revoked bias of currently-unlocked object >>> >>> Revoking bias by walking my own stack: >>> Revoking bias of object 0x6df887c8 , mark 0x09065805 , type >> java.lang.Object , >>> prototype header 0x00000005 , allow rebias 0 , requesting >> thread 0x09065800 >>> Revoked bias of currently-locked object >>> Inflating object 0x6df887c8 , mark 0x0906042a , type >> java.lang.Object >>> >>> Also, disabling biased locking has no effect on the >> magnitude of safepointing, >>> so I concluded that safepointing must then be caused by >> lock inflation/deflation >>> (which seems to be supported by the stack above). >>> >>> Afaik a lock is being inflated when the leight-weight >> locking algorithm can't >>> acquire the lock immediately ("contention"). It will then >> fall back to >>> heavy-weight locking (OS mutex?) and notify (wake up) all >> waiting threads (?). >>> We have about 40 lock inflations per contended lock attempt >> (see the perfdata >>> statistics above), does that mean there were (on average) >> 40 threads waiting on >>> that contended lock? >>> >>> Since we have the same amount of deflations as we have >> inflations, I would >>> assume that each heavy-weight lock is shortly after being >> "contended" reverted >>> to a leight-weight lock again (during a safepoint in >> deflate_idle_monitors() as >>> in the stack above??). But why? Couldn't it stay as a >> heavy-weight lock, instead >>> of being deflated, only to be inflated shortly after again? >>> >>> In the example below, lock 0x96568a60 is being inflated, >> deflated, inflated >>> again and then deflated again: >>> >>> >>> Inflating object 0x96568a60 , mark 0x08677ffe , type >> org.jacorb.poa.RequestProcessor >>> >>> Deflating object 0x96568a60 , mark 0x08677ffe , type >> org.jacorb.poa.RequestProcessor >>> >>> Inflating object 0x96568a60 , mark 0x0918f4fe , type >> org.jacorb.poa.RequestProcessor >>> >>> Inflating object 0x79bceee8 , mark 0x08c0b662 , type >> java.lang.Object >>> >>> Inflating object 0x79bceeb0 , mark 0x0914e9ee , type >> org.jacorb.orb.ReplyReceiver >>> >>> Deflating object 0x79bceee8 , mark 0x08c0b662 , type >> java.lang.Object >>> Deflating object 0x79bceeb0 , mark 0x0914e9ee , type >> org.jacorb.orb.ReplyReceiver >>> Deflating object 0x96568a60 , mark 0x0918f4fe , type >> org.jacorb.poa.RequestProcessor >>> >>> I was just curious whether this is the intended behavior in >> case of lock >>> contention, or whether we're seing some pathological >> strange thing happen here. >>> >>> Btw, I've also ran the workload with Hotspot 19.0-b03 from >> the latest JDK 7 >>> build with the same results. >>> >>> Any comments appreciated! >>> >>> Thanks, >>> Nick. >>> >> >> > > From kelly.ohair at oracle.com Thu Jul 8 09:11:13 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 8 Jul 2010 09:11:13 -0700 Subject: bug 6693236 fix In-Reply-To: <4C35CEFA.9060901@univ-mlv.fr> References: <4C27560A.3020505@univ-mlv.fr> <4C354C48.9040808@oracle.com> <4C35A097.7060605@univ-mlv.fr> <4C35A4D8.8000307@oracle.com> <4C35BF7D.7000702@oracle.com> <4C35CEFA.9060901@univ-mlv.fr> Message-ID: <859FDBE0-81FB-49AD-83BE-3BD6458C75D6@oracle.com> On Jul 8, 2010, at 6:13 AM, R?mi Forax wrote: > Le 08/07/2010 14:07, Keith McGuigan a ?crit : >> David Holmes wrote: >>> R?mi Forax said the following on 07/08/10 19:55: >>>> Hi David, >>>> I've no problem with the fact that the default configuration of >>>> jdk7 >>>> mandate to use of the split verifier. >>>> But the patch for bug 6693236 also make FailOverOldVerifier >>>> command line flag useless. >>>> >>>> I think it's an error. FailOverOldVerifier should "fail over the >>>> old verifier" and not be silently ignored. >>> >>> For Java 7 you're not permitted to failover to the old verifier so >>> the choices are to: >>> >>> a) silently ignore it >>> b) ignore it but issue a warning >>> c) refuse to start the VM >>> >>> I presume you would prefer (b) or (c)? >> >> At startup time, the JVM doesn't know what kind of classfiles it's >> going to load. It doesn't get fed a steady diet of same-versioned >> classfiles. Failover is still an option for classfiles with >> classfile version 50. >> >> So it's really not being ignored, it still enables failover for old >> classfile versions. Just not the new ones. >> >> -- >> - Keith > > Hi Keith, > The problem is that bytecode transformations at runtime is a common > trick, > especially since the VM has an agent API (java.lanf.instrumentation). > Such agents modify the bytecode at runtime by rewritting it. > During the rewrite, the stackmap information are often discarded, > because the agent was written before the release of 1.6 or > because generating stackmap frames takes more time than using > the old verifier. > > With this fix, these agent libraries will stop working with 1.7 > classfiles > and there is no workaround until the agent code is updated. Agent libraries that re-write bytecodes of classfiles and do not also transform the StackMapTable attributes seem like very broken libraries to me. The java_crw_demo bytecode instrumentation code in the jdk used by hprof performs the necessary transformation of the StackMapTable offsets. See: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/820b4e843d51/src/share/demo/jvmti/java_crw_demo/java_crw_demo.c starting around line 1710. It wasn't that difficult. Bytecode transformation people should have known about this for a very long time. -kto > > R?mi From kelly.ohair at oracle.com Thu Jul 8 09:20:08 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 8 Jul 2010 09:20:08 -0700 Subject: bug 6693236 fix In-Reply-To: <4C35D805.9070403@oracle.com> References: <4C27560A.3020505@univ-mlv.fr> <4C354C48.9040808@oracle.com> <4C35A097.7060605@univ-mlv.fr> <4C35A4D8.8000307@oracle.com> <4C35BF7D.7000702@oracle.com> <4C35CEFA.9060901@univ-mlv.fr> <4C35D805.9070403@oracle.com> Message-ID: <7C45A436-1823-43AB-80C8-F398905189F2@oracle.com> On Jul 8, 2010, at 6:52 AM, Keith McGuigan wrote: > R?mi Forax wrote: >> Hi Keith, >> The problem is that bytecode transformations at runtime is a common >> trick, >> especially since the VM has an agent API (java.lanf.instrumentation). >> Such agents modify the bytecode at runtime by rewritting it. >> During the rewrite, the stackmap information are often discarded, >> because the agent was written before the release of 1.6 or >> because generating stackmap frames takes more time than using >> the old verifier. >> With this fix, these agent libraries will stop working with 1.7 >> classfiles >> and there is no workaround until the agent code is updated. > > Hi R?mi, > > I understand the issues. The failover flag has been in place for > years as a stopgap measure to let tools "catch up" to the new > classfile format. The specification is quite clear that stackmaps > are needed, so discarding them for convenience reasons isn't really > an option (as far as the spec/JVM is concerned). In order to > process classfiles with version >= 51, the tools must be updated to > emit the correct stackmaps. Otherwise they're not generating valid > classfiles. Tools that can't generate stackmaps for whatever > reasons shouldn't modify classfiles with version 51, then, I would > think. I vaguely recall that they could also downgrade the classfile version too, i.e. transform the classfile to an older version. Seemed like there were a variety of ways to deal with it, but many required actually making changes to the classfile re-writer code. Bytecode transformation code that did not inspect and correctly deal with the classfile version specifics may have been a common mistake. They cannot ignore the classfile version. -kto > > There is a workaround, though, if one does not care that modified > classes are verifiable, and that is to disable verification with - > Xverify:none. You can use that instead of the failover option but > keep in mind that you're treading on dangerous territory. > > From https://jdk.dev.java.net/verifier.html: > > If you develop or use tools that manipulate Java byte code, such > as > profilers, loggers, and class file rewriters, your tools may not > work > correctly with the new StackMapTable attribute. The fall-back > behavior > allows the existing tools to still work for version 50 class > files. However, > the tools need to migrate to the new format eventually because > the fall-back > behavior may not be feasible to support in the future. Besides, > you cannot > take advantage of the improved verifier until your class files > pass the type > checking verifier. This is especially important if your > applications are > performance sensitive. > > > -- > - Keith > > -- > - Keith > From karen.kinnear at oracle.com Thu Jul 8 08:06:29 2010 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 8 Jul 2010 11:06:29 -0400 Subject: Safepointing & Locking issue In-Reply-To: <2E6CDDE5-8A26-4C64-A625-2DBB4A7255E9@oracle.com> References: <2E6CDDE5-8A26-4C64-A625-2DBB4A7255E9@oracle.com> Message-ID: Nicolas, It would also be very helpful if you could possibly gather information to determine why you are running so many safepoints. Could you possibly try running with the following flags on a fairly current jdk7 binary? -XX:+PrintSafepointStatistics -XX:+TraceSafepointCleanupTime That should tell you why you are running so many safepoints (which would not be caused by lock inflation/deflation). It will also tell you details of time spent in different components of the safepoint cleanup time, including lock deflation. Note that the flags require a development build, like fastdebug. thanks, Karen On Jul 8, 2010, at 7:56 AM, Dave Dice wrote: > > On 2010-7-8, at 3:21 AM, Nicolas Michael wrote: > >> Hi all, >> >> I have yesterday been investigating a performance problem with one >> of our >> applications where I observed some "strange" JVM behavior (which >> might be as >> expected, but I'm not sure...). >> >> It's a heavily multi-threaded Java application with about 300 >> threads, running >> on a 4 CPU Solaris x86 box using a 32bit HotSpot Client VM build >> 16.3-b01 (JDK >> 1.6.0_20-b02). It seems to make extensive use of synchronization >> and suffers >> badly from lock contention. Thread #10 (the VM Thread) eats close >> to one CPU, >> mostly doing lock deflations during safepoints in stacks like this: >> >> libjvm.so`__1cNObjectMonitorHis_busy6kM_i_+0x26 >> >> libjvm.so`__1cSObjectSynchronizerVdeflate_idle_monitors6F_v_+0x210 >> >> libjvm.so`__1cUSafepointSynchronizeQdo_cleanup_tasks6F_v_+0x19 >> libjvm.so`__1cUSafepointSynchronizeFbegin6F_v_+0x3d0 >> libjvm.so`__1cIVMThreadEloop6M_v_+0x26c >> libjvm.so`__1cIVMThreadDrun6M_v_+0x88 >> libjvm.so`java_start+0xf9 >> libc.so.1`_thr_setup+0x4e >> libc.so.1`_lwp_start >> 287 >> >>> From safepointing point-of-view, the process isn't doing much >>> useful work -- it >> only got short periods of work interrupted by safepoints that take >> longer than >> the actual application runtime -- at a rate of 1709 safepoints per >> second (see >> below): >> >> Application time: 0.0000450 seconds >> Total time for which application threads were stopped: 0.0002397 >> seconds >> Application time: 0.0001607 seconds >> Total time for which application threads were stopped: 0.0002603 >> seconds >> Application time: 0.0000469 seconds >> Total time for which application threads were stopped: 0.0011530 >> seconds >> .. >> >>> From the perfdata statistics, I see >> sun.rt._sync_ContendedLockAttempts increasing by 12 / sec >> sun.rt._sync_Deflations increasing by 477 / sec >> sun.rt._sync_Inflations increasing by 477 / sec >> sun.rt._sync_Notifications increasing by 791 / sec >> sun.rt._sync_Parks increasing by 795 / sec >> sun.rt.safepoints increasing by 1709 / sec >> sun.rt.safepointTime is 0.82s and sun.rt.safepointSyncTime 0.15s >> per second. >> >> I guess we're using too much synchronization, Object.wait(ms) and >> notify() (or >> even notifyAll()) ... ;-) but I'm wondering whether it was "normal" >> to have that >> many safepoints and lock inflations/deflations because of that? >> >> My understanding was that safepoints are mainly caused by GC (not >> the case here) >> or deoptimization (should be visible with +LogCompilation, right? >> but nothing >> there either). Or bias revocation. Indeed, we do have some bias >> revocations >> (like this, see below), but this is at a much lower rate (only ~ >> 3.4 times per >> second): > > Hi Nick, > > Do you have test case that's easily packaged up? > > Inflation can be induced by a number of behaviors, such as wait(), > contention, deoptimization, bias revocation, JNI monitor access, > some hashCode actions, etc. By default, however, we don't trigger > stop-the-world safepoints to deflate. Absent safepoints, the > ultimate bound on the number of objectmonitors in play is just the > number of live and dead objects in the heap. That is, there's no > natural back-pressure on the number of monitors. If the number of > monitors becomes too large the JVM can spend inordinate amounts of > time in deflate_idle_monitors() scanning, trying to scavenge and > deflate monitors, so there's both a time problem and space problem > (arguably the space problem drives the time problem, but they > manifest differently for customers). > > There's a day-one assumption in various pieces of code that the > object:monitor relationship is stable except over potential > safepoints. That simplifies many operations but is the source of > the issue you're seeing. Ultimately, it's probably better to > deflate on the fly and decouple safepoints from deflation. (The old > ExactVM implementation did just that). It's relatively straight- > forward, but touches a good deal of code. If you're curious I've > left more detailed comments in synchronizer.cpp. > > In the mean time there are some palliative approaches under > consideration to (a) induce STW safepoints to bound the number of > extant monitors and in turn bound the cost of deflate_idle_monitors, > and (b) partition the monitors so we only need scan those that were > possibly inflated in the last STW epoch. We also have code > percolating through the system that might cut down on some of the > cases of inflation, which is why a test case would be of interest -- > to see if the specific case you're running into might already be > addressed. > > I vaguely recall adding a perfdata counter that reflects the number > of objectmonitors in the system. Where there any other rt._sync_* > variables visible in perfdata? > > Regards > Dave > > > >> >> >> Revoking bias with potentially per-thread safepoint: >> Revoking bias of object 0x6df887d0 , mark 0x08ee3805 , type >> org.jacorb.poa.RequestQueue , prototype header 0x00000005 , allow >> rebias 0 , >> requesting thread 0x09065800 >> Revoked bias of currently-unlocked object >> >> Revoking bias by walking my own stack: >> Revoking bias of object 0x6df887c8 , mark 0x09065805 , type >> java.lang.Object , >> prototype header 0x00000005 , allow rebias 0 , requesting thread >> 0x09065800 >> Revoked bias of currently-locked object >> Inflating object 0x6df887c8 , mark 0x0906042a , type java.lang.Object >> >> Also, disabling biased locking has no effect on the magnitude of >> safepointing, >> so I concluded that safepointing must then be caused by lock >> inflation/deflation >> (which seems to be supported by the stack above). >> >> Afaik a lock is being inflated when the leight-weight locking >> algorithm can't >> acquire the lock immediately ("contention"). It will then fall back >> to >> heavy-weight locking (OS mutex?) and notify (wake up) all waiting >> threads (?). >> We have about 40 lock inflations per contended lock attempt (see >> the perfdata >> statistics above), does that mean there were (on average) 40 >> threads waiting on >> that contended lock? >> >> Since we have the same amount of deflations as we have inflations, >> I would >> assume that each heavy-weight lock is shortly after being >> "contended" reverted >> to a leight-weight lock again (during a safepoint in >> deflate_idle_monitors() as >> in the stack above??). But why? Couldn't it stay as a heavy-weight >> lock, instead >> of being deflated, only to be inflated shortly after again? >> >> In the example below, lock 0x96568a60 is being inflated, deflated, >> inflated >> again and then deflated again: >> >> >> Inflating object 0x96568a60 , mark 0x08677ffe , type >> org.jacorb.poa.RequestProcessor >> >> Deflating object 0x96568a60 , mark 0x08677ffe , type >> org.jacorb.poa.RequestProcessor >> >> Inflating object 0x96568a60 , mark 0x0918f4fe , type >> org.jacorb.poa.RequestProcessor >> >> Inflating object 0x79bceee8 , mark 0x08c0b662 , type java.lang.Object >> >> Inflating object 0x79bceeb0 , mark 0x0914e9ee , type >> org.jacorb.orb.ReplyReceiver >> >> Deflating object 0x79bceee8 , mark 0x08c0b662 , type java.lang.Object >> Deflating object 0x79bceeb0 , mark 0x0914e9ee , type >> org.jacorb.orb.ReplyReceiver >> Deflating object 0x96568a60 , mark 0x0918f4fe , type >> org.jacorb.poa.RequestProcessor >> >> I was just curious whether this is the intended behavior in case of >> lock >> contention, or whether we're seing some pathological strange thing >> happen here. >> >> Btw, I've also ran the workload with Hotspot 19.0-b03 from the >> latest JDK 7 >> build with the same results. >> >> Any comments appreciated! >> >> Thanks, >> Nick. >> > From y.s.ramakrishna at oracle.com Thu Jul 8 10:03:46 2010 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Thu, 08 Jul 2010 10:03:46 -0700 Subject: Safepointing & Locking issue In-Reply-To: References: <2E6CDDE5-8A26-4C64-A625-2DBB4A7255E9@oracle.com> Message-ID: <4C3604F2.30102@oracle.com> On 07/08/10 08:06, Karen Kinnear wrote: > Nicolas, > > It would also be very helpful if you could possibly gather information > to determine > why you are running so many safepoints. > > Could you possibly try running with the following flags on a fairly > current jdk7 binary? > -XX:+PrintSafepointStatistics -XX:+TraceSafepointCleanupTime > > That should tell you why you are running so many safepoints (which would > not be caused > by lock inflation/deflation). It will also tell you details of time > spent in different components > of the safepoint cleanup time, including lock deflation. Note that the > flags require a development > build, like fastdebug. The two you mention above are also available in product builds, thanks to Xiaobin. But probably moot now considering what Nicolas has figured out since the first email on this thread (i.e. frequency of safepoints, not their duration or deflation per se, being the cause of his overhead). -- ramki From tom.rodriguez at oracle.com Thu Jul 8 10:16:53 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 8 Jul 2010 10:16:53 -0700 Subject: Safepointing & Locking issue In-Reply-To: References: Message-ID: <46F2D020-4C2B-405B-A845-73351ACD5979@oracle.com> I suspect you are hitting an issue with agents and exception throwing. It should have been fixed as part of 6902182 which is included in 6u21 which was just released. Basically JVMTI includes functionality that includes tracking the dispatch of exceptions and the machinery for that was being turned on whenever an agent was installed, even if the facility was being used. Part of this was falling back to the interpreter when dispatching the interpreter which is the DeoptimizeFrame safepoints you are seeing. Those don't really need to induce safepoints even if we are tracking exceptions which was also fixed as part of this change. So try out a recent JDK7 or 6u21 and see if you are seeing the asme problem. tom On Jul 8, 2010, at 6:12 AM, Nicolas Michael wrote: > Hi David and Dave, > > thanks a lot for your hints and background details on this issue. > > Adding -XX:+PrintSafepointStatistics to the options as suggested by David gives > about 1200+ DeoptimizeFrame's per second in the LogFile: > > vmop [threads: total initially_running > wait_to_block] [time: spin block sync cleanup vmop] page_trap_count > .. > 168.976: DeoptimizeFrame [ 217 0 0 > ] [ 0 0 0 0 0 ] 0 > 168.976: DeoptimizeFrame [ 217 0 0 > ] [ 0 0 0 0 0 ] 0 > 168.978: DeoptimizeFrame [ 217 0 0 > ] [ 0 0 0 0 0 ] 0 > 168.978: DeoptimizeFrame [ 217 0 0 > ] [ 0 0 0 0 0 ] 0 > 168.978: DeoptimizeFrame [ 217 0 0 > ] [ 0 0 0 0 0 ] 0 > .. > > The output from the various switches (as also -XX:+LogCompilation) are a bit > interleaved, but at this point in time (second 168ff) there are no other > compilation related outputs around. So is there any way to further find out why > a frame is being deoptimized? This would then lead so a safepoint, right? > > Oh, and yes, this JVM does have a JVMTI agent attached to it. But as far as I > could find out until now, it should only register for GC start/end events (which > are very rare in this process). > > With DTrace I just saw -- thanks to the really cool hotspot probes (some of them > seem to be new, it's the first time I see that great level of detail!) -- that > there are about 1000 Exceptions occurring per second ("ExceptionOccurred-entry") > (but less than one "ThrowNew-entry" per second). I'm not sure how ThrowNew > relates to ExceptionOccurred and what they are actually counting, and whether > 1000+ of ExceptionOccurred is "a lot" (it seems quite high ;-) ). Could > exceptions also cause deoptimization? > > Unfortunately we don't have a stand-alone easy to reproduce testcase for this. > > These are all the _sync_* that I get: > > sun.rt._sync_ContendedLockAttempts = 1625 > sun.rt._sync_Deflations = 66821 > sun.rt._sync_EmptyNotifications = 0 > sun.rt._sync_FailedSpins = 0 > sun.rt._sync_FutileWakeups = 56 > sun.rt._sync_Inflations = 66870 > sun.rt._sync_MonExtant = 6784 > sun.rt._sync_MonInCirculation = 0 > sun.rt._sync_MonScavenged = 0 > sun.rt._sync_Notifications = 116109 > sun.rt._sync_Parks = 117295 > sun.rt._sync_PrivateA = 0 > sun.rt._sync_PrivateB = 0 > sun.rt._sync_SlowEnter = 0 > sun.rt._sync_SlowExit = 0 > sun.rt._sync_SlowNotify = 0 > sun.rt._sync_SlowNotifyAll = 0 > sun.rt._sync_SuccessfulSpins = 0 > > Thanks for pointing me to synchronizer.cpp, this sounds worth reading your > comments there! > > Thanks, > Nick. > > > >> -----Original Message----- >> From: ext Dave Dice [mailto:dave.dice at oracle.com] >> Sent: Donnerstag, 8. Juli 2010 13:57 >> To: Nicolas Michael >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: Safepointing & Locking issue >> >> >> On 2010-7-8, at 3:21 AM, Nicolas Michael wrote: >> >>> Hi all, >>> >>> I have yesterday been investigating a performance problem >> with one of our >>> applications where I observed some "strange" JVM behavior >> (which might be as >>> expected, but I'm not sure...). >>> >>> It's a heavily multi-threaded Java application with about >> 300 threads, running >>> on a 4 CPU Solaris x86 box using a 32bit HotSpot Client VM >> build 16.3-b01 (JDK >>> 1.6.0_20-b02). It seems to make extensive use of >> synchronization and suffers >>> badly from lock contention. Thread #10 (the VM Thread) eats >> close to one CPU, >>> mostly doing lock deflations during safepoints in stacks like this: >>> >>> libjvm.so`__1cNObjectMonitorHis_busy6kM_i_+0x26 >>> >> libjvm.so`__1cSObjectSynchronizerVdeflate_idle_monitors6F_v_+0x210 >>> >> libjvm.so`__1cUSafepointSynchronizeQdo_cleanup_tasks6F_v_+0x19 >>> libjvm.so`__1cUSafepointSynchronizeFbegin6F_v_+0x3d0 >>> libjvm.so`__1cIVMThreadEloop6M_v_+0x26c >>> libjvm.so`__1cIVMThreadDrun6M_v_+0x88 >>> libjvm.so`java_start+0xf9 >>> libc.so.1`_thr_setup+0x4e >>> libc.so.1`_lwp_start >>> 287 >>> >>>> From safepointing point-of-view, the process isn't doing >> much useful work -- it >>> only got short periods of work interrupted by safepoints >> that take longer than >>> the actual application runtime -- at a rate of 1709 >> safepoints per second (see >>> below): >>> >>> Application time: 0.0000450 seconds >>> Total time for which application threads were stopped: >> 0.0002397 seconds >>> Application time: 0.0001607 seconds >>> Total time for which application threads were stopped: >> 0.0002603 seconds >>> Application time: 0.0000469 seconds >>> Total time for which application threads were stopped: >> 0.0011530 seconds >>> .. >>> >>>> From the perfdata statistics, I see >>> sun.rt._sync_ContendedLockAttempts increasing by 12 / sec >>> sun.rt._sync_Deflations increasing by 477 / sec >>> sun.rt._sync_Inflations increasing by 477 / sec >>> sun.rt._sync_Notifications increasing by 791 / sec >>> sun.rt._sync_Parks increasing by 795 / sec >>> sun.rt.safepoints increasing by 1709 / sec >>> sun.rt.safepointTime is 0.82s and sun.rt.safepointSyncTime >> 0.15s per second. >>> >>> I guess we're using too much synchronization, >> Object.wait(ms) and notify() (or >>> even notifyAll()) ... ;-) but I'm wondering whether it was >> "normal" to have that >>> many safepoints and lock inflations/deflations because of that? >>> >>> My understanding was that safepoints are mainly caused by >> GC (not the case here) >>> or deoptimization (should be visible with +LogCompilation, >> right? but nothing >>> there either). Or bias revocation. Indeed, we do have some >> bias revocations >>> (like this, see below), but this is at a much lower rate >> (only ~ 3.4 times per >>> second): >> >> Hi Nick, >> >> Do you have test case that's easily packaged up? >> >> Inflation can be induced by a number of behaviors, such as >> wait(), contention, deoptimization, bias revocation, JNI >> monitor access, some hashCode actions, etc. By default, >> however, we don't trigger stop-the-world safepoints to >> deflate. Absent safepoints, the ultimate bound on the >> number of objectmonitors in play is just the number of live >> and dead objects in the heap. That is, there's no natural >> back-pressure on the number of monitors. If the number of >> monitors becomes too large the JVM can spend inordinate >> amounts of time in deflate_idle_monitors() scanning, trying >> to scavenge and deflate monitors, so there's both a time >> problem and space problem (arguably the space problem drives >> the time problem, but they manifest differently for customers). >> >> There's a day-one assumption in various pieces of code that >> the object:monitor relationship is stable except over >> potential safepoints. That simplifies many operations but >> is the source of the issue you're seeing. Ultimately, it's >> probably better to deflate on the fly and decouple safepoints >> from deflation. (The old ExactVM implementation did just >> that). It's relatively straight-forward, but touches a good >> deal of code. If you're curious I've left more detailed >> comments in synchronizer.cpp. >> >> In the mean time there are some palliative approaches under >> consideration to (a) induce STW safepoints to bound the >> number of extant monitors and in turn bound the cost of >> deflate_idle_monitors, and (b) partition the monitors so we >> only need scan those that were possibly inflated in the last >> STW epoch. We also have code percolating through the >> system that might cut down on some of the cases of inflation, >> which is why a test case would be of interest -- to see if >> the specific case you're running into might already be addressed. >> >> I vaguely recall adding a perfdata counter that reflects the >> number of objectmonitors in the system. Where there any >> other rt._sync_* variables visible in perfdata? >> >> Regards >> Dave >> >> >> >>> >>> >>> Revoking bias with potentially per-thread safepoint: >>> Revoking bias of object 0x6df887d0 , mark 0x08ee3805 , type >>> org.jacorb.poa.RequestQueue , prototype header 0x00000005 , >> allow rebias 0 , >>> requesting thread 0x09065800 >>> Revoked bias of currently-unlocked object >>> >>> Revoking bias by walking my own stack: >>> Revoking bias of object 0x6df887c8 , mark 0x09065805 , type >> java.lang.Object , >>> prototype header 0x00000005 , allow rebias 0 , requesting >> thread 0x09065800 >>> Revoked bias of currently-locked object >>> Inflating object 0x6df887c8 , mark 0x0906042a , type >> java.lang.Object >>> >>> Also, disabling biased locking has no effect on the >> magnitude of safepointing, >>> so I concluded that safepointing must then be caused by >> lock inflation/deflation >>> (which seems to be supported by the stack above). >>> >>> Afaik a lock is being inflated when the leight-weight >> locking algorithm can't >>> acquire the lock immediately ("contention"). It will then >> fall back to >>> heavy-weight locking (OS mutex?) and notify (wake up) all >> waiting threads (?). >>> We have about 40 lock inflations per contended lock attempt >> (see the perfdata >>> statistics above), does that mean there were (on average) >> 40 threads waiting on >>> that contended lock? >>> >>> Since we have the same amount of deflations as we have >> inflations, I would >>> assume that each heavy-weight lock is shortly after being >> "contended" reverted >>> to a leight-weight lock again (during a safepoint in >> deflate_idle_monitors() as >>> in the stack above??). But why? Couldn't it stay as a >> heavy-weight lock, instead >>> of being deflated, only to be inflated shortly after again? >>> >>> In the example below, lock 0x96568a60 is being inflated, >> deflated, inflated >>> again and then deflated again: >>> >>> >>> Inflating object 0x96568a60 , mark 0x08677ffe , type >> org.jacorb.poa.RequestProcessor >>> >>> Deflating object 0x96568a60 , mark 0x08677ffe , type >> org.jacorb.poa.RequestProcessor >>> >>> Inflating object 0x96568a60 , mark 0x0918f4fe , type >> org.jacorb.poa.RequestProcessor >>> >>> Inflating object 0x79bceee8 , mark 0x08c0b662 , type >> java.lang.Object >>> >>> Inflating object 0x79bceeb0 , mark 0x0914e9ee , type >> org.jacorb.orb.ReplyReceiver >>> >>> Deflating object 0x79bceee8 , mark 0x08c0b662 , type >> java.lang.Object >>> Deflating object 0x79bceeb0 , mark 0x0914e9ee , type >> org.jacorb.orb.ReplyReceiver >>> Deflating object 0x96568a60 , mark 0x0918f4fe , type >> org.jacorb.poa.RequestProcessor >>> >>> I was just curious whether this is the intended behavior in >> case of lock >>> contention, or whether we're seing some pathological >> strange thing happen here. >>> >>> Btw, I've also ran the workload with Hotspot 19.0-b03 from >> the latest JDK 7 >>> build with the same results. >>> >>> Any comments appreciated! >>> >>> Thanks, >>> Nick. >>> >> >> > > From mailing at nmichael.de Thu Jul 8 11:04:52 2010 From: mailing at nmichael.de (Nicolas Michael) Date: Thu, 08 Jul 2010 20:04:52 +0200 Subject: Safepointing & Locking issue In-Reply-To: <4C3604F2.30102@oracle.com> References: <2E6CDDE5-8A26-4C64-A625-2DBB4A7255E9@oracle.com> <4C3604F2.30102@oracle.com> Message-ID: <4C361344.5030808@nmichael.de> Thanks, I will add -XX:+TraceSafepointCleanupTime as well. The output for -XX:+PrintSafepointStatistics was in my previous mail -- it's basically "DeoptimizeFrame" about 1200 times a second. And Ramki, you are right: It's actually more about the frequency of the safepoints, not necessarily their duration. I didn't do a real (i.e. SunStudio) profiling, just some quick DTrace profiling, which always captured deflate_idle_monitors() being top of the stack. Nick. Am 08.07.2010 19:03, schrieb Y. S. Ramakrishna: > > > On 07/08/10 08:06, Karen Kinnear wrote: >> Nicolas, >> >> It would also be very helpful if you could possibly gather information >> to determine >> why you are running so many safepoints. >> >> Could you possibly try running with the following flags on a fairly >> current jdk7 binary? >> -XX:+PrintSafepointStatistics -XX:+TraceSafepointCleanupTime >> >> That should tell you why you are running so many safepoints (which >> would not be caused >> by lock inflation/deflation). It will also tell you details of time >> spent in different components >> of the safepoint cleanup time, including lock deflation. Note that the >> flags require a development >> build, like fastdebug. > > The two you mention above are also available in product builds, thanks > to Xiaobin. > But probably moot now considering what Nicolas has figured out since the > first email on this thread (i.e. frequency of safepoints, not their > duration or deflation per se, being the cause of his overhead). > > -- ramki > > From mailing at nmichael.de Thu Jul 8 11:10:53 2010 From: mailing at nmichael.de (Nicolas Michael) Date: Thu, 08 Jul 2010 20:10:53 +0200 Subject: Safepointing & Locking issue In-Reply-To: <46F2D020-4C2B-405B-A845-73351ACD5979@oracle.com> References: <46F2D020-4C2B-405B-A845-73351ACD5979@oracle.com> Message-ID: <4C3614AD.4090905@nmichael.de> Hi Tom, our production VM is 6u20, but I already ran some tests with the latest JDK 7 (Hotspot 19.0-b03). Actually, the last numbers I've posted were for Hotspot 19 (where this bug should be fixed, right?)... So it seems the problem presists. But I will focus on the agent nevertheless. Unfortunately, we have some wrappers around our code launching the JVM, so it's not as simple as just removing the JVM option ... I have to patch the wrapper in order to get rid of the agent. :-( Nick. Am 08.07.2010 19:16, schrieb Tom Rodriguez: > I suspect you are hitting an issue with agents and exception throwing. It should have been fixed as part of 6902182 which is included in 6u21 which was just released. Basically JVMTI includes functionality that includes tracking the dispatch of exceptions and the machinery for that was being turned on whenever an agent was installed, even if the facility was being used. Part of this was falling back to the interpreter when dispatching the interpreter which is the DeoptimizeFrame safepoints you are seeing. Those don't really need to induce safepoints even if we are tracking exceptions which was also fixed as part of this change. So try out a recent JDK7 or 6u21 and see if you are seeing the asme problem. > > tom > > On Jul 8, 2010, at 6:12 AM, Nicolas Michael wrote: > >> Hi David and Dave, >> >> thanks a lot for your hints and background details on this issue. >> >> Adding -XX:+PrintSafepointStatistics to the options as suggested by David gives >> about 1200+ DeoptimizeFrame's per second in the LogFile: >> >> vmop [threads: total initially_running >> wait_to_block] [time: spin block sync cleanup vmop] page_trap_count >> .. >> 168.976: DeoptimizeFrame [ 217 0 0 >> ] [ 0 0 0 0 0 ] 0 >> 168.976: DeoptimizeFrame [ 217 0 0 >> ] [ 0 0 0 0 0 ] 0 >> 168.978: DeoptimizeFrame [ 217 0 0 >> ] [ 0 0 0 0 0 ] 0 >> 168.978: DeoptimizeFrame [ 217 0 0 >> ] [ 0 0 0 0 0 ] 0 >> 168.978: DeoptimizeFrame [ 217 0 0 >> ] [ 0 0 0 0 0 ] 0 >> .. >> >> The output from the various switches (as also -XX:+LogCompilation) are a bit >> interleaved, but at this point in time (second 168ff) there are no other >> compilation related outputs around. So is there any way to further find out why >> a frame is being deoptimized? This would then lead so a safepoint, right? >> >> Oh, and yes, this JVM does have a JVMTI agent attached to it. But as far as I >> could find out until now, it should only register for GC start/end events (which >> are very rare in this process). >> >> With DTrace I just saw -- thanks to the really cool hotspot probes (some of them >> seem to be new, it's the first time I see that great level of detail!) -- that >> there are about 1000 Exceptions occurring per second ("ExceptionOccurred-entry") >> (but less than one "ThrowNew-entry" per second). I'm not sure how ThrowNew >> relates to ExceptionOccurred and what they are actually counting, and whether >> 1000+ of ExceptionOccurred is "a lot" (it seems quite high ;-) ). Could >> exceptions also cause deoptimization? >> >> Unfortunately we don't have a stand-alone easy to reproduce testcase for this. >> >> These are all the _sync_* that I get: >> >> sun.rt._sync_ContendedLockAttempts = 1625 >> sun.rt._sync_Deflations = 66821 >> sun.rt._sync_EmptyNotifications = 0 >> sun.rt._sync_FailedSpins = 0 >> sun.rt._sync_FutileWakeups = 56 >> sun.rt._sync_Inflations = 66870 >> sun.rt._sync_MonExtant = 6784 >> sun.rt._sync_MonInCirculation = 0 >> sun.rt._sync_MonScavenged = 0 >> sun.rt._sync_Notifications = 116109 >> sun.rt._sync_Parks = 117295 >> sun.rt._sync_PrivateA = 0 >> sun.rt._sync_PrivateB = 0 >> sun.rt._sync_SlowEnter = 0 >> sun.rt._sync_SlowExit = 0 >> sun.rt._sync_SlowNotify = 0 >> sun.rt._sync_SlowNotifyAll = 0 >> sun.rt._sync_SuccessfulSpins = 0 >> >> Thanks for pointing me to synchronizer.cpp, this sounds worth reading your >> comments there! >> >> Thanks, >> Nick. >> >> >> >>> -----Original Message----- >>> From: ext Dave Dice [mailto:dave.dice at oracle.com] >>> Sent: Donnerstag, 8. Juli 2010 13:57 >>> To: Nicolas Michael >>> Cc: hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: Safepointing& Locking issue >>> >>> >>> On 2010-7-8, at 3:21 AM, Nicolas Michael wrote: >>> >>>> Hi all, >>>> >>>> I have yesterday been investigating a performance problem >>> with one of our >>>> applications where I observed some "strange" JVM behavior >>> (which might be as >>>> expected, but I'm not sure...). >>>> >>>> It's a heavily multi-threaded Java application with about >>> 300 threads, running >>>> on a 4 CPU Solaris x86 box using a 32bit HotSpot Client VM >>> build 16.3-b01 (JDK >>>> 1.6.0_20-b02). It seems to make extensive use of >>> synchronization and suffers >>>> badly from lock contention. Thread #10 (the VM Thread) eats >>> close to one CPU, >>>> mostly doing lock deflations during safepoints in stacks like this: >>>> >>>> libjvm.so`__1cNObjectMonitorHis_busy6kM_i_+0x26 >>>> >>> libjvm.so`__1cSObjectSynchronizerVdeflate_idle_monitors6F_v_+0x210 >>>> >>> libjvm.so`__1cUSafepointSynchronizeQdo_cleanup_tasks6F_v_+0x19 >>>> libjvm.so`__1cUSafepointSynchronizeFbegin6F_v_+0x3d0 >>>> libjvm.so`__1cIVMThreadEloop6M_v_+0x26c >>>> libjvm.so`__1cIVMThreadDrun6M_v_+0x88 >>>> libjvm.so`java_start+0xf9 >>>> libc.so.1`_thr_setup+0x4e >>>> libc.so.1`_lwp_start >>>> 287 >>>> >>>>> From safepointing point-of-view, the process isn't doing >>> much useful work -- it >>>> only got short periods of work interrupted by safepoints >>> that take longer than >>>> the actual application runtime -- at a rate of 1709 >>> safepoints per second (see >>>> below): >>>> >>>> Application time: 0.0000450 seconds >>>> Total time for which application threads were stopped: >>> 0.0002397 seconds >>>> Application time: 0.0001607 seconds >>>> Total time for which application threads were stopped: >>> 0.0002603 seconds >>>> Application time: 0.0000469 seconds >>>> Total time for which application threads were stopped: >>> 0.0011530 seconds >>>> .. >>>> >>>>> From the perfdata statistics, I see >>>> sun.rt._sync_ContendedLockAttempts increasing by 12 / sec >>>> sun.rt._sync_Deflations increasing by 477 / sec >>>> sun.rt._sync_Inflations increasing by 477 / sec >>>> sun.rt._sync_Notifications increasing by 791 / sec >>>> sun.rt._sync_Parks increasing by 795 / sec >>>> sun.rt.safepoints increasing by 1709 / sec >>>> sun.rt.safepointTime is 0.82s and sun.rt.safepointSyncTime >>> 0.15s per second. >>>> >>>> I guess we're using too much synchronization, >>> Object.wait(ms) and notify() (or >>>> even notifyAll()) ... ;-) but I'm wondering whether it was >>> "normal" to have that >>>> many safepoints and lock inflations/deflations because of that? >>>> >>>> My understanding was that safepoints are mainly caused by >>> GC (not the case here) >>>> or deoptimization (should be visible with +LogCompilation, >>> right? but nothing >>>> there either). Or bias revocation. Indeed, we do have some >>> bias revocations >>>> (like this, see below), but this is at a much lower rate >>> (only ~ 3.4 times per >>>> second): >>> >>> Hi Nick, >>> >>> Do you have test case that's easily packaged up? >>> >>> Inflation can be induced by a number of behaviors, such as >>> wait(), contention, deoptimization, bias revocation, JNI >>> monitor access, some hashCode actions, etc. By default, >>> however, we don't trigger stop-the-world safepoints to >>> deflate. Absent safepoints, the ultimate bound on the >>> number of objectmonitors in play is just the number of live >>> and dead objects in the heap. That is, there's no natural >>> back-pressure on the number of monitors. If the number of >>> monitors becomes too large the JVM can spend inordinate >>> amounts of time in deflate_idle_monitors() scanning, trying >>> to scavenge and deflate monitors, so there's both a time >>> problem and space problem (arguably the space problem drives >>> the time problem, but they manifest differently for customers). >>> >>> There's a day-one assumption in various pieces of code that >>> the object:monitor relationship is stable except over >>> potential safepoints. That simplifies many operations but >>> is the source of the issue you're seeing. Ultimately, it's >>> probably better to deflate on the fly and decouple safepoints >>> from deflation. (The old ExactVM implementation did just >>> that). It's relatively straight-forward, but touches a good >>> deal of code. If you're curious I've left more detailed >>> comments in synchronizer.cpp. >>> >>> In the mean time there are some palliative approaches under >>> consideration to (a) induce STW safepoints to bound the >>> number of extant monitors and in turn bound the cost of >>> deflate_idle_monitors, and (b) partition the monitors so we >>> only need scan those that were possibly inflated in the last >>> STW epoch. We also have code percolating through the >>> system that might cut down on some of the cases of inflation, >>> which is why a test case would be of interest -- to see if >>> the specific case you're running into might already be addressed. >>> >>> I vaguely recall adding a perfdata counter that reflects the >>> number of objectmonitors in the system. Where there any >>> other rt._sync_* variables visible in perfdata? >>> >>> Regards >>> Dave >>> >>> >>> >>>> >>>> >>>> Revoking bias with potentially per-thread safepoint: >>>> Revoking bias of object 0x6df887d0 , mark 0x08ee3805 , type >>>> org.jacorb.poa.RequestQueue , prototype header 0x00000005 , >>> allow rebias 0 , >>>> requesting thread 0x09065800 >>>> Revoked bias of currently-unlocked object >>>> >>>> Revoking bias by walking my own stack: >>>> Revoking bias of object 0x6df887c8 , mark 0x09065805 , type >>> java.lang.Object , >>>> prototype header 0x00000005 , allow rebias 0 , requesting >>> thread 0x09065800 >>>> Revoked bias of currently-locked object >>>> Inflating object 0x6df887c8 , mark 0x0906042a , type >>> java.lang.Object >>>> >>>> Also, disabling biased locking has no effect on the >>> magnitude of safepointing, >>>> so I concluded that safepointing must then be caused by >>> lock inflation/deflation >>>> (which seems to be supported by the stack above). >>>> >>>> Afaik a lock is being inflated when the leight-weight >>> locking algorithm can't >>>> acquire the lock immediately ("contention"). It will then >>> fall back to >>>> heavy-weight locking (OS mutex?) and notify (wake up) all >>> waiting threads (?). >>>> We have about 40 lock inflations per contended lock attempt >>> (see the perfdata >>>> statistics above), does that mean there were (on average) >>> 40 threads waiting on >>>> that contended lock? >>>> >>>> Since we have the same amount of deflations as we have >>> inflations, I would >>>> assume that each heavy-weight lock is shortly after being >>> "contended" reverted >>>> to a leight-weight lock again (during a safepoint in >>> deflate_idle_monitors() as >>>> in the stack above??). But why? Couldn't it stay as a >>> heavy-weight lock, instead >>>> of being deflated, only to be inflated shortly after again? >>>> >>>> In the example below, lock 0x96568a60 is being inflated, >>> deflated, inflated >>>> again and then deflated again: >>>> >>>> >>>> Inflating object 0x96568a60 , mark 0x08677ffe , type >>> org.jacorb.poa.RequestProcessor >>>> >>>> Deflating object 0x96568a60 , mark 0x08677ffe , type >>> org.jacorb.poa.RequestProcessor >>>> >>>> Inflating object 0x96568a60 , mark 0x0918f4fe , type >>> org.jacorb.poa.RequestProcessor >>>> >>>> Inflating object 0x79bceee8 , mark 0x08c0b662 , type >>> java.lang.Object >>>> >>>> Inflating object 0x79bceeb0 , mark 0x0914e9ee , type >>> org.jacorb.orb.ReplyReceiver >>>> >>>> Deflating object 0x79bceee8 , mark 0x08c0b662 , type >>> java.lang.Object >>>> Deflating object 0x79bceeb0 , mark 0x0914e9ee , type >>> org.jacorb.orb.ReplyReceiver >>>> Deflating object 0x96568a60 , mark 0x0918f4fe , type >>> org.jacorb.poa.RequestProcessor >>>> >>>> I was just curious whether this is the intended behavior in >>> case of lock >>>> contention, or whether we're seing some pathological >>> strange thing happen here. >>>> >>>> Btw, I've also ran the workload with Hotspot 19.0-b03 from >>> the latest JDK 7 >>>> build with the same results. >>>> >>>> Any comments appreciated! >>>> >>>> Thanks, >>>> Nick. >>>> >>> >>> >> >> > > From mailing at nmichael.de Thu Jul 8 10:57:24 2010 From: mailing at nmichael.de (Nicolas Michael) Date: Thu, 08 Jul 2010 19:57:24 +0200 Subject: Safepointing & Locking issue In-Reply-To: <64A4118A-8440-48B6-93D7-E388F68E14DC@oracle.com> References: <64A4118A-8440-48B6-93D7-E388F68E14DC@oracle.com> Message-ID: <4C361184.5020508@nmichael.de> Hi Dave, Am 08.07.2010 16:59, schrieb Dave Dice: >> These are all the _sync_* that I get: >> >> sun.rt._sync_ContendedLockAttempts = 1625 >> sun.rt._sync_Deflations = 66821 >> sun.rt._sync_EmptyNotifications = 0 >> sun.rt._sync_FailedSpins = 0 >> sun.rt._sync_FutileWakeups = 56 >> sun.rt._sync_Inflations = 66870 >> sun.rt._sync_MonExtant = 6784 >> sun.rt._sync_MonInCirculation = 0 >> sun.rt._sync_MonScavenged = 0 >> sun.rt._sync_Notifications = 116109 >> sun.rt._sync_Parks = 117295 >> sun.rt._sync_PrivateA = 0 >> sun.rt._sync_PrivateB = 0 >> sun.rt._sync_SlowEnter = 0 >> sun.rt._sync_SlowExit = 0 >> sun.rt._sync_SlowNotify = 0 >> sun.rt._sync_SlowNotifyAll = 0 >> sun.rt._sync_SuccessfulSpins = 0 > > You've only got 6784 extant monitors, which is quite reasonable. (We over-provision somewhat to allow per-thread free lists of readily usable monitors -- this reduces contention on the central free list -- so the actually number of monitors in-use at any one time will have been much less than 6874). The monitor scan/scavenge costs should be dominated by and only a small fraction of the overhead to rendezvous for the safepoint. At the last safepoint you had 49 monitors actually in-use, which probably means you had about 49 threads blocked on wait() or contended monitor entry. Does that agree with what you know of the application? The inflation and deflation counts relative to the # of extant monitors suggests that monitors are circulating properly. So I don't see anything particular amiss in the data above. 49 threads sounds very reasonable. There are different types of threads, but the ones that are doing wait() on the one queue are 50 threads in total. >> Thanks for pointing me to synchronizer.cpp, this sounds worth reading your >> comments there! > > By all means feel free to ask questions. Great, thanks. Nick. From tom.rodriguez at oracle.com Thu Jul 8 11:45:59 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 8 Jul 2010 11:45:59 -0700 Subject: Safepointing & Locking issue In-Reply-To: <4C3614AD.4090905@nmichael.de> References: <46F2D020-4C2B-405B-A845-73351ACD5979@oracle.com> <4C3614AD.4090905@nmichael.de> Message-ID: <529DD4AC-E757-4762-9C71-82BD86DA7452@oracle.com> On Jul 8, 2010, at 11:10 AM, Nicolas Michael wrote: > Hi Tom, > > our production VM is 6u20, but I already ran some tests with the latest JDK 7 (Hotspot 19.0-b03). Actually, the last numbers I've posted were for Hotspot 19 (where this bug should be fixed, right?)... So it seems the problem presists. Are you using client or server? I can see some places in client compiler code where we are still using the safepoint variant. Even after the fix you are still being slightly penalized for the use of an agent, it's just that it's not stopped all threads too. If you search the serviceability-dev list for the discussion about 6902182 you can see the issues involved. > But I will focus on the agent nevertheless. Unfortunately, we have some wrappers around our code launching the JVM, so it's not as simple as just removing the JVM option ... I have to patch the wrapper in order to get rid of the agent. :-( The only uses of VM_DeoptimizeFrame are associated with JVMTI agent logic so I think that's the right place to look. tom > > Nick. > > Am 08.07.2010 19:16, schrieb Tom Rodriguez: >> I suspect you are hitting an issue with agents and exception throwing. It should have been fixed as part of 6902182 which is included in 6u21 which was just released. Basically JVMTI includes functionality that includes tracking the dispatch of exceptions and the machinery for that was being turned on whenever an agent was installed, even if the facility was being used. Part of this was falling back to the interpreter when dispatching the interpreter which is the DeoptimizeFrame safepoints you are seeing. Those don't really need to induce safepoints even if we are tracking exceptions which was also fixed as part of this change. So try out a recent JDK7 or 6u21 and see if you are seeing the asme problem. >> >> tom >> >> On Jul 8, 2010, at 6:12 AM, Nicolas Michael wrote: >> >>> Hi David and Dave, >>> >>> thanks a lot for your hints and background details on this issue. >>> >>> Adding -XX:+PrintSafepointStatistics to the options as suggested by David gives >>> about 1200+ DeoptimizeFrame's per second in the LogFile: >>> >>> vmop [threads: total initially_running >>> wait_to_block] [time: spin block sync cleanup vmop] page_trap_count >>> .. >>> 168.976: DeoptimizeFrame [ 217 0 0 >>> ] [ 0 0 0 0 0 ] 0 >>> 168.976: DeoptimizeFrame [ 217 0 0 >>> ] [ 0 0 0 0 0 ] 0 >>> 168.978: DeoptimizeFrame [ 217 0 0 >>> ] [ 0 0 0 0 0 ] 0 >>> 168.978: DeoptimizeFrame [ 217 0 0 >>> ] [ 0 0 0 0 0 ] 0 >>> 168.978: DeoptimizeFrame [ 217 0 0 >>> ] [ 0 0 0 0 0 ] 0 >>> .. >>> >>> The output from the various switches (as also -XX:+LogCompilation) are a bit >>> interleaved, but at this point in time (second 168ff) there are no other >>> compilation related outputs around. So is there any way to further find out why >>> a frame is being deoptimized? This would then lead so a safepoint, right? >>> >>> Oh, and yes, this JVM does have a JVMTI agent attached to it. But as far as I >>> could find out until now, it should only register for GC start/end events (which >>> are very rare in this process). >>> >>> With DTrace I just saw -- thanks to the really cool hotspot probes (some of them >>> seem to be new, it's the first time I see that great level of detail!) -- that >>> there are about 1000 Exceptions occurring per second ("ExceptionOccurred-entry") >>> (but less than one "ThrowNew-entry" per second). I'm not sure how ThrowNew >>> relates to ExceptionOccurred and what they are actually counting, and whether >>> 1000+ of ExceptionOccurred is "a lot" (it seems quite high ;-) ). Could >>> exceptions also cause deoptimization? >>> >>> Unfortunately we don't have a stand-alone easy to reproduce testcase for this. >>> >>> These are all the _sync_* that I get: >>> >>> sun.rt._sync_ContendedLockAttempts = 1625 >>> sun.rt._sync_Deflations = 66821 >>> sun.rt._sync_EmptyNotifications = 0 >>> sun.rt._sync_FailedSpins = 0 >>> sun.rt._sync_FutileWakeups = 56 >>> sun.rt._sync_Inflations = 66870 >>> sun.rt._sync_MonExtant = 6784 >>> sun.rt._sync_MonInCirculation = 0 >>> sun.rt._sync_MonScavenged = 0 >>> sun.rt._sync_Notifications = 116109 >>> sun.rt._sync_Parks = 117295 >>> sun.rt._sync_PrivateA = 0 >>> sun.rt._sync_PrivateB = 0 >>> sun.rt._sync_SlowEnter = 0 >>> sun.rt._sync_SlowExit = 0 >>> sun.rt._sync_SlowNotify = 0 >>> sun.rt._sync_SlowNotifyAll = 0 >>> sun.rt._sync_SuccessfulSpins = 0 >>> >>> Thanks for pointing me to synchronizer.cpp, this sounds worth reading your >>> comments there! >>> >>> Thanks, >>> Nick. >>> >>> >>> >>>> -----Original Message----- >>>> From: ext Dave Dice [mailto:dave.dice at oracle.com] >>>> Sent: Donnerstag, 8. Juli 2010 13:57 >>>> To: Nicolas Michael >>>> Cc: hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: Safepointing& Locking issue >>>> >>>> >>>> On 2010-7-8, at 3:21 AM, Nicolas Michael wrote: >>>> >>>>> Hi all, >>>>> >>>>> I have yesterday been investigating a performance problem >>>> with one of our >>>>> applications where I observed some "strange" JVM behavior >>>> (which might be as >>>>> expected, but I'm not sure...). >>>>> >>>>> It's a heavily multi-threaded Java application with about >>>> 300 threads, running >>>>> on a 4 CPU Solaris x86 box using a 32bit HotSpot Client VM >>>> build 16.3-b01 (JDK >>>>> 1.6.0_20-b02). It seems to make extensive use of >>>> synchronization and suffers >>>>> badly from lock contention. Thread #10 (the VM Thread) eats >>>> close to one CPU, >>>>> mostly doing lock deflations during safepoints in stacks like this: >>>>> >>>>> libjvm.so`__1cNObjectMonitorHis_busy6kM_i_+0x26 >>>>> >>>> libjvm.so`__1cSObjectSynchronizerVdeflate_idle_monitors6F_v_+0x210 >>>>> >>>> libjvm.so`__1cUSafepointSynchronizeQdo_cleanup_tasks6F_v_+0x19 >>>>> libjvm.so`__1cUSafepointSynchronizeFbegin6F_v_+0x3d0 >>>>> libjvm.so`__1cIVMThreadEloop6M_v_+0x26c >>>>> libjvm.so`__1cIVMThreadDrun6M_v_+0x88 >>>>> libjvm.so`java_start+0xf9 >>>>> libc.so.1`_thr_setup+0x4e >>>>> libc.so.1`_lwp_start >>>>> 287 >>>>> >>>>>> From safepointing point-of-view, the process isn't doing >>>> much useful work -- it >>>>> only got short periods of work interrupted by safepoints >>>> that take longer than >>>>> the actual application runtime -- at a rate of 1709 >>>> safepoints per second (see >>>>> below): >>>>> >>>>> Application time: 0.0000450 seconds >>>>> Total time for which application threads were stopped: >>>> 0.0002397 seconds >>>>> Application time: 0.0001607 seconds >>>>> Total time for which application threads were stopped: >>>> 0.0002603 seconds >>>>> Application time: 0.0000469 seconds >>>>> Total time for which application threads were stopped: >>>> 0.0011530 seconds >>>>> .. >>>>> >>>>>> From the perfdata statistics, I see >>>>> sun.rt._sync_ContendedLockAttempts increasing by 12 / sec >>>>> sun.rt._sync_Deflations increasing by 477 / sec >>>>> sun.rt._sync_Inflations increasing by 477 / sec >>>>> sun.rt._sync_Notifications increasing by 791 / sec >>>>> sun.rt._sync_Parks increasing by 795 / sec >>>>> sun.rt.safepoints increasing by 1709 / sec >>>>> sun.rt.safepointTime is 0.82s and sun.rt.safepointSyncTime >>>> 0.15s per second. >>>>> >>>>> I guess we're using too much synchronization, >>>> Object.wait(ms) and notify() (or >>>>> even notifyAll()) ... ;-) but I'm wondering whether it was >>>> "normal" to have that >>>>> many safepoints and lock inflations/deflations because of that? >>>>> >>>>> My understanding was that safepoints are mainly caused by >>>> GC (not the case here) >>>>> or deoptimization (should be visible with +LogCompilation, >>>> right? but nothing >>>>> there either). Or bias revocation. Indeed, we do have some >>>> bias revocations >>>>> (like this, see below), but this is at a much lower rate >>>> (only ~ 3.4 times per >>>>> second): >>>> >>>> Hi Nick, >>>> >>>> Do you have test case that's easily packaged up? >>>> >>>> Inflation can be induced by a number of behaviors, such as >>>> wait(), contention, deoptimization, bias revocation, JNI >>>> monitor access, some hashCode actions, etc. By default, >>>> however, we don't trigger stop-the-world safepoints to >>>> deflate. Absent safepoints, the ultimate bound on the >>>> number of objectmonitors in play is just the number of live >>>> and dead objects in the heap. That is, there's no natural >>>> back-pressure on the number of monitors. If the number of >>>> monitors becomes too large the JVM can spend inordinate >>>> amounts of time in deflate_idle_monitors() scanning, trying >>>> to scavenge and deflate monitors, so there's both a time >>>> problem and space problem (arguably the space problem drives >>>> the time problem, but they manifest differently for customers). >>>> >>>> There's a day-one assumption in various pieces of code that >>>> the object:monitor relationship is stable except over >>>> potential safepoints. That simplifies many operations but >>>> is the source of the issue you're seeing. Ultimately, it's >>>> probably better to deflate on the fly and decouple safepoints >>>> from deflation. (The old ExactVM implementation did just >>>> that). It's relatively straight-forward, but touches a good >>>> deal of code. If you're curious I've left more detailed >>>> comments in synchronizer.cpp. >>>> >>>> In the mean time there are some palliative approaches under >>>> consideration to (a) induce STW safepoints to bound the >>>> number of extant monitors and in turn bound the cost of >>>> deflate_idle_monitors, and (b) partition the monitors so we >>>> only need scan those that were possibly inflated in the last >>>> STW epoch. We also have code percolating through the >>>> system that might cut down on some of the cases of inflation, >>>> which is why a test case would be of interest -- to see if >>>> the specific case you're running into might already be addressed. >>>> >>>> I vaguely recall adding a perfdata counter that reflects the >>>> number of objectmonitors in the system. Where there any >>>> other rt._sync_* variables visible in perfdata? >>>> >>>> Regards >>>> Dave >>>> >>>> >>>> >>>>> >>>>> >>>>> Revoking bias with potentially per-thread safepoint: >>>>> Revoking bias of object 0x6df887d0 , mark 0x08ee3805 , type >>>>> org.jacorb.poa.RequestQueue , prototype header 0x00000005 , >>>> allow rebias 0 , >>>>> requesting thread 0x09065800 >>>>> Revoked bias of currently-unlocked object >>>>> >>>>> Revoking bias by walking my own stack: >>>>> Revoking bias of object 0x6df887c8 , mark 0x09065805 , type >>>> java.lang.Object , >>>>> prototype header 0x00000005 , allow rebias 0 , requesting >>>> thread 0x09065800 >>>>> Revoked bias of currently-locked object >>>>> Inflating object 0x6df887c8 , mark 0x0906042a , type >>>> java.lang.Object >>>>> >>>>> Also, disabling biased locking has no effect on the >>>> magnitude of safepointing, >>>>> so I concluded that safepointing must then be caused by >>>> lock inflation/deflation >>>>> (which seems to be supported by the stack above). >>>>> >>>>> Afaik a lock is being inflated when the leight-weight >>>> locking algorithm can't >>>>> acquire the lock immediately ("contention"). It will then >>>> fall back to >>>>> heavy-weight locking (OS mutex?) and notify (wake up) all >>>> waiting threads (?). >>>>> We have about 40 lock inflations per contended lock attempt >>>> (see the perfdata >>>>> statistics above), does that mean there were (on average) >>>> 40 threads waiting on >>>>> that contended lock? >>>>> >>>>> Since we have the same amount of deflations as we have >>>> inflations, I would >>>>> assume that each heavy-weight lock is shortly after being >>>> "contended" reverted >>>>> to a leight-weight lock again (during a safepoint in >>>> deflate_idle_monitors() as >>>>> in the stack above??). But why? Couldn't it stay as a >>>> heavy-weight lock, instead >>>>> of being deflated, only to be inflated shortly after again? >>>>> >>>>> In the example below, lock 0x96568a60 is being inflated, >>>> deflated, inflated >>>>> again and then deflated again: >>>>> >>>>> >>>>> Inflating object 0x96568a60 , mark 0x08677ffe , type >>>> org.jacorb.poa.RequestProcessor >>>>> >>>>> Deflating object 0x96568a60 , mark 0x08677ffe , type >>>> org.jacorb.poa.RequestProcessor >>>>> >>>>> Inflating object 0x96568a60 , mark 0x0918f4fe , type >>>> org.jacorb.poa.RequestProcessor >>>>> >>>>> Inflating object 0x79bceee8 , mark 0x08c0b662 , type >>>> java.lang.Object >>>>> >>>>> Inflating object 0x79bceeb0 , mark 0x0914e9ee , type >>>> org.jacorb.orb.ReplyReceiver >>>>> >>>>> Deflating object 0x79bceee8 , mark 0x08c0b662 , type >>>> java.lang.Object >>>>> Deflating object 0x79bceeb0 , mark 0x0914e9ee , type >>>> org.jacorb.orb.ReplyReceiver >>>>> Deflating object 0x96568a60 , mark 0x0918f4fe , type >>>> org.jacorb.poa.RequestProcessor >>>>> >>>>> I was just curious whether this is the intended behavior in >>>> case of lock >>>>> contention, or whether we're seing some pathological >>>> strange thing happen here. >>>>> >>>>> Btw, I've also ran the workload with Hotspot 19.0-b03 from >>>> the latest JDK 7 >>>>> build with the same results. >>>>> >>>>> Any comments appreciated! >>>>> >>>>> Thanks, >>>>> Nick. >>>>> >>>> >>>> >>> >>> >> >> From mandy.chung at oracle.com Fri Jul 9 02:31:09 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 09 Jul 2010 09:31:09 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6967423: Hotspot support for modules image Message-ID: <20100709093118.E98A747868@hg.openjdk.java.net> Changeset: 0e7d2a08b605 Author: mchung Date: 2010-07-07 15:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0e7d2a08b605 6967423: Hotspot support for modules image Summary: Add hotspot support for modules image Reviewed-by: acorn ! make/linux/makefiles/sa.make ! make/solaris/makefiles/sa.make ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/os.cpp From mailing at nmichael.de Fri Jul 9 03:02:47 2010 From: mailing at nmichael.de (Nicolas Michael) Date: Fri, 09 Jul 2010 12:02:47 +0200 Subject: Safepointing & Locking issue In-Reply-To: <529DD4AC-E757-4762-9C71-82BD86DA7452@oracle.com> References: <46F2D020-4C2B-405B-A845-73351ACD5979@oracle.com> <4C3614AD.4090905@nmichael.de> <529DD4AC-E757-4762-9C71-82BD86DA7452@oracle.com> Message-ID: <4C36F3C7.1080704@nmichael.de> Am 08.07.2010 20:45, schrieb Tom Rodriguez: > > On Jul 8, 2010, at 11:10 AM, Nicolas Michael wrote: > >> Hi Tom, >> >> our production VM is 6u20, but I already ran some tests with the latest JDK 7 (Hotspot 19.0-b03). Actually, the last numbers I've posted were for Hotspot 19 (where this bug should be fixed, right?)... So it seems the problem presists. > > Are you using client or server? I can see some places in client compiler code where we are still using the safepoint variant. Even after the fix you are still being slightly penalized for the use of an agent, it's just that it's not stopped all threads too. If you search the serviceability-dev list for the discussion about 6902182 you can see the issues involved. Oh ... we're using client for this application. But that's actually more by mistake ... ;-) Well, it's for historic reasons: Even though most of our applications are loooooong running server-style application, we also need to have the JVM "warm and ready to process requests" right away if it has been restarted -- and therefore couldn't in the past accept the impact of the C2 compiler needing much more resources during this phase. Running on x86 hardware has reduced this problem quite a lot (we deploy fewer JVM's on those boxes, and the high single-thread performance helps C2 compilation as well). I have just moved this application to server (with JDK7), and wow: We now see about 20x the throughput for this application than before! No needless safepointing any more! :-) And that also matches about our expectations we've had for running this app on this HW. So, this solves our problem! Great, thanks a lot for your help! Just out of curiosity, are you going to fix that "slight penalty for the use of an agent" for client as well? ;-) >> But I will focus on the agent nevertheless. Unfortunately, we have some wrappers around our code launching the JVM, so it's not as simple as just removing the JVM option ... I have to patch the wrapper in order to get rid of the agent. :-( > > The only uses of VM_DeoptimizeFrame are associated with JVMTI agent logic so I think that's the right place to look. Yep, that was it. Thanks again! Nick. >> Am 08.07.2010 19:16, schrieb Tom Rodriguez: >>> I suspect you are hitting an issue with agents and exception throwing. It should have been fixed as part of 6902182 which is included in 6u21 which was just released. Basically JVMTI includes functionality that includes tracking the dispatch of exceptions and the machinery for that was being turned on whenever an agent was installed, even if the facility was being used. Part of this was falling back to the interpreter when dispatching the interpreter which is the DeoptimizeFrame safepoints you are seeing. Those don't really need to induce safepoints even if we are tracking exceptions which was also fixed as part of this change. So try out a recent JDK7 or 6u21 and see if you are seeing the asme problem. >>> >>> tom >>> >>> On Jul 8, 2010, at 6:12 AM, Nicolas Michael wrote: >>> >>>> Hi David and Dave, >>>> >>>> thanks a lot for your hints and background details on this issue. >>>> >>>> Adding -XX:+PrintSafepointStatistics to the options as suggested by David gives >>>> about 1200+ DeoptimizeFrame's per second in the LogFile: >>>> >>>> vmop [threads: total initially_running >>>> wait_to_block] [time: spin block sync cleanup vmop] page_trap_count >>>> .. >>>> 168.976: DeoptimizeFrame [ 217 0 0 >>>> ] [ 0 0 0 0 0 ] 0 >>>> 168.976: DeoptimizeFrame [ 217 0 0 >>>> ] [ 0 0 0 0 0 ] 0 >>>> 168.978: DeoptimizeFrame [ 217 0 0 >>>> ] [ 0 0 0 0 0 ] 0 >>>> 168.978: DeoptimizeFrame [ 217 0 0 >>>> ] [ 0 0 0 0 0 ] 0 >>>> 168.978: DeoptimizeFrame [ 217 0 0 >>>> ] [ 0 0 0 0 0 ] 0 >>>> .. >>>> >>>> The output from the various switches (as also -XX:+LogCompilation) are a bit >>>> interleaved, but at this point in time (second 168ff) there are no other >>>> compilation related outputs around. So is there any way to further find out why >>>> a frame is being deoptimized? This would then lead so a safepoint, right? >>>> >>>> Oh, and yes, this JVM does have a JVMTI agent attached to it. But as far as I >>>> could find out until now, it should only register for GC start/end events (which >>>> are very rare in this process). >>>> >>>> With DTrace I just saw -- thanks to the really cool hotspot probes (some of them >>>> seem to be new, it's the first time I see that great level of detail!) -- that >>>> there are about 1000 Exceptions occurring per second ("ExceptionOccurred-entry") >>>> (but less than one "ThrowNew-entry" per second). I'm not sure how ThrowNew >>>> relates to ExceptionOccurred and what they are actually counting, and whether >>>> 1000+ of ExceptionOccurred is "a lot" (it seems quite high ;-) ). Could >>>> exceptions also cause deoptimization? >>>> >>>> Unfortunately we don't have a stand-alone easy to reproduce testcase for this. >>>> >>>> These are all the _sync_* that I get: >>>> >>>> sun.rt._sync_ContendedLockAttempts = 1625 >>>> sun.rt._sync_Deflations = 66821 >>>> sun.rt._sync_EmptyNotifications = 0 >>>> sun.rt._sync_FailedSpins = 0 >>>> sun.rt._sync_FutileWakeups = 56 >>>> sun.rt._sync_Inflations = 66870 >>>> sun.rt._sync_MonExtant = 6784 >>>> sun.rt._sync_MonInCirculation = 0 >>>> sun.rt._sync_MonScavenged = 0 >>>> sun.rt._sync_Notifications = 116109 >>>> sun.rt._sync_Parks = 117295 >>>> sun.rt._sync_PrivateA = 0 >>>> sun.rt._sync_PrivateB = 0 >>>> sun.rt._sync_SlowEnter = 0 >>>> sun.rt._sync_SlowExit = 0 >>>> sun.rt._sync_SlowNotify = 0 >>>> sun.rt._sync_SlowNotifyAll = 0 >>>> sun.rt._sync_SuccessfulSpins = 0 >>>> >>>> Thanks for pointing me to synchronizer.cpp, this sounds worth reading your >>>> comments there! >>>> >>>> Thanks, >>>> Nick. >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Dave Dice [mailto:dave.dice at oracle.com] >>>>> Sent: Donnerstag, 8. Juli 2010 13:57 >>>>> To: Nicolas Michael >>>>> Cc: hotspot-runtime-dev at openjdk.java.net >>>>> Subject: Re: Safepointing& Locking issue >>>>> >>>>> >>>>> On 2010-7-8, at 3:21 AM, Nicolas Michael wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I have yesterday been investigating a performance problem >>>>> with one of our >>>>>> applications where I observed some "strange" JVM behavior >>>>> (which might be as >>>>>> expected, but I'm not sure...). >>>>>> >>>>>> It's a heavily multi-threaded Java application with about >>>>> 300 threads, running >>>>>> on a 4 CPU Solaris x86 box using a 32bit HotSpot Client VM >>>>> build 16.3-b01 (JDK >>>>>> 1.6.0_20-b02). It seems to make extensive use of >>>>> synchronization and suffers >>>>>> badly from lock contention. Thread #10 (the VM Thread) eats >>>>> close to one CPU, >>>>>> mostly doing lock deflations during safepoints in stacks like this: >>>>>> >>>>>> libjvm.so`__1cNObjectMonitorHis_busy6kM_i_+0x26 >>>>>> >>>>> libjvm.so`__1cSObjectSynchronizerVdeflate_idle_monitors6F_v_+0x210 >>>>>> >>>>> libjvm.so`__1cUSafepointSynchronizeQdo_cleanup_tasks6F_v_+0x19 >>>>>> libjvm.so`__1cUSafepointSynchronizeFbegin6F_v_+0x3d0 >>>>>> libjvm.so`__1cIVMThreadEloop6M_v_+0x26c >>>>>> libjvm.so`__1cIVMThreadDrun6M_v_+0x88 >>>>>> libjvm.so`java_start+0xf9 >>>>>> libc.so.1`_thr_setup+0x4e >>>>>> libc.so.1`_lwp_start >>>>>> 287 >>>>>> >>>>>>> From safepointing point-of-view, the process isn't doing >>>>> much useful work -- it >>>>>> only got short periods of work interrupted by safepoints >>>>> that take longer than >>>>>> the actual application runtime -- at a rate of 1709 >>>>> safepoints per second (see >>>>>> below): >>>>>> >>>>>> Application time: 0.0000450 seconds >>>>>> Total time for which application threads were stopped: >>>>> 0.0002397 seconds >>>>>> Application time: 0.0001607 seconds >>>>>> Total time for which application threads were stopped: >>>>> 0.0002603 seconds >>>>>> Application time: 0.0000469 seconds >>>>>> Total time for which application threads were stopped: >>>>> 0.0011530 seconds >>>>>> .. >>>>>> >>>>>>> From the perfdata statistics, I see >>>>>> sun.rt._sync_ContendedLockAttempts increasing by 12 / sec >>>>>> sun.rt._sync_Deflations increasing by 477 / sec >>>>>> sun.rt._sync_Inflations increasing by 477 / sec >>>>>> sun.rt._sync_Notifications increasing by 791 / sec >>>>>> sun.rt._sync_Parks increasing by 795 / sec >>>>>> sun.rt.safepoints increasing by 1709 / sec >>>>>> sun.rt.safepointTime is 0.82s and sun.rt.safepointSyncTime >>>>> 0.15s per second. >>>>>> >>>>>> I guess we're using too much synchronization, >>>>> Object.wait(ms) and notify() (or >>>>>> even notifyAll()) ... ;-) but I'm wondering whether it was >>>>> "normal" to have that >>>>>> many safepoints and lock inflations/deflations because of that? >>>>>> >>>>>> My understanding was that safepoints are mainly caused by >>>>> GC (not the case here) >>>>>> or deoptimization (should be visible with +LogCompilation, >>>>> right? but nothing >>>>>> there either). Or bias revocation. Indeed, we do have some >>>>> bias revocations >>>>>> (like this, see below), but this is at a much lower rate >>>>> (only ~ 3.4 times per >>>>>> second): >>>>> >>>>> Hi Nick, >>>>> >>>>> Do you have test case that's easily packaged up? >>>>> >>>>> Inflation can be induced by a number of behaviors, such as >>>>> wait(), contention, deoptimization, bias revocation, JNI >>>>> monitor access, some hashCode actions, etc. By default, >>>>> however, we don't trigger stop-the-world safepoints to >>>>> deflate. Absent safepoints, the ultimate bound on the >>>>> number of objectmonitors in play is just the number of live >>>>> and dead objects in the heap. That is, there's no natural >>>>> back-pressure on the number of monitors. If the number of >>>>> monitors becomes too large the JVM can spend inordinate >>>>> amounts of time in deflate_idle_monitors() scanning, trying >>>>> to scavenge and deflate monitors, so there's both a time >>>>> problem and space problem (arguably the space problem drives >>>>> the time problem, but they manifest differently for customers). >>>>> >>>>> There's a day-one assumption in various pieces of code that >>>>> the object:monitor relationship is stable except over >>>>> potential safepoints. That simplifies many operations but >>>>> is the source of the issue you're seeing. Ultimately, it's >>>>> probably better to deflate on the fly and decouple safepoints >>>>> from deflation. (The old ExactVM implementation did just >>>>> that). It's relatively straight-forward, but touches a good >>>>> deal of code. If you're curious I've left more detailed >>>>> comments in synchronizer.cpp. >>>>> >>>>> In the mean time there are some palliative approaches under >>>>> consideration to (a) induce STW safepoints to bound the >>>>> number of extant monitors and in turn bound the cost of >>>>> deflate_idle_monitors, and (b) partition the monitors so we >>>>> only need scan those that were possibly inflated in the last >>>>> STW epoch. We also have code percolating through the >>>>> system that might cut down on some of the cases of inflation, >>>>> which is why a test case would be of interest -- to see if >>>>> the specific case you're running into might already be addressed. >>>>> >>>>> I vaguely recall adding a perfdata counter that reflects the >>>>> number of objectmonitors in the system. Where there any >>>>> other rt._sync_* variables visible in perfdata? >>>>> >>>>> Regards >>>>> Dave >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> Revoking bias with potentially per-thread safepoint: >>>>>> Revoking bias of object 0x6df887d0 , mark 0x08ee3805 , type >>>>>> org.jacorb.poa.RequestQueue , prototype header 0x00000005 , >>>>> allow rebias 0 , >>>>>> requesting thread 0x09065800 >>>>>> Revoked bias of currently-unlocked object >>>>>> >>>>>> Revoking bias by walking my own stack: >>>>>> Revoking bias of object 0x6df887c8 , mark 0x09065805 , type >>>>> java.lang.Object , >>>>>> prototype header 0x00000005 , allow rebias 0 , requesting >>>>> thread 0x09065800 >>>>>> Revoked bias of currently-locked object >>>>>> Inflating object 0x6df887c8 , mark 0x0906042a , type >>>>> java.lang.Object >>>>>> >>>>>> Also, disabling biased locking has no effect on the >>>>> magnitude of safepointing, >>>>>> so I concluded that safepointing must then be caused by >>>>> lock inflation/deflation >>>>>> (which seems to be supported by the stack above). >>>>>> >>>>>> Afaik a lock is being inflated when the leight-weight >>>>> locking algorithm can't >>>>>> acquire the lock immediately ("contention"). It will then >>>>> fall back to >>>>>> heavy-weight locking (OS mutex?) and notify (wake up) all >>>>> waiting threads (?). >>>>>> We have about 40 lock inflations per contended lock attempt >>>>> (see the perfdata >>>>>> statistics above), does that mean there were (on average) >>>>> 40 threads waiting on >>>>>> that contended lock? >>>>>> >>>>>> Since we have the same amount of deflations as we have >>>>> inflations, I would >>>>>> assume that each heavy-weight lock is shortly after being >>>>> "contended" reverted >>>>>> to a leight-weight lock again (during a safepoint in >>>>> deflate_idle_monitors() as >>>>>> in the stack above??). But why? Couldn't it stay as a >>>>> heavy-weight lock, instead >>>>>> of being deflated, only to be inflated shortly after again? >>>>>> >>>>>> In the example below, lock 0x96568a60 is being inflated, >>>>> deflated, inflated >>>>>> again and then deflated again: >>>>>> >>>>>> >>>>>> Inflating object 0x96568a60 , mark 0x08677ffe , type >>>>> org.jacorb.poa.RequestProcessor >>>>>> >>>>>> Deflating object 0x96568a60 , mark 0x08677ffe , type >>>>> org.jacorb.poa.RequestProcessor >>>>>> >>>>>> Inflating object 0x96568a60 , mark 0x0918f4fe , type >>>>> org.jacorb.poa.RequestProcessor >>>>>> >>>>>> Inflating object 0x79bceee8 , mark 0x08c0b662 , type >>>>> java.lang.Object >>>>>> >>>>>> Inflating object 0x79bceeb0 , mark 0x0914e9ee , type >>>>> org.jacorb.orb.ReplyReceiver >>>>>> >>>>>> Deflating object 0x79bceee8 , mark 0x08c0b662 , type >>>>> java.lang.Object >>>>>> Deflating object 0x79bceeb0 , mark 0x0914e9ee , type >>>>> org.jacorb.orb.ReplyReceiver >>>>>> Deflating object 0x96568a60 , mark 0x0918f4fe , type >>>>> org.jacorb.poa.RequestProcessor >>>>>> >>>>>> I was just curious whether this is the intended behavior in >>>>> case of lock >>>>>> contention, or whether we're seing some pathological >>>>> strange thing happen here. >>>>>> >>>>>> Btw, I've also ran the workload with Hotspot 19.0-b03 from >>>>> the latest JDK 7 >>>>>> build with the same results. >>>>>> >>>>>> Any comments appreciated! >>>>>> >>>>>> Thanks, >>>>>> Nick. >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> > > From stas.oskin at gmail.com Fri Jul 9 05:30:53 2010 From: stas.oskin at gmail.com (Stas Oskin) Date: Fri, 9 Jul 2010 15:30:53 +0300 Subject: Fwd: JVM hangs beyond recovery In-Reply-To: References: <4BC8EE42.9070404@oracle.com> <4BC8F8D4.5020707@oracle.com> <4BCD0019.2020601@oracle.com> <4C0EC6B9.5020901@oracle.com> <4C0F5B21.8030707@oracle.com> <4C0F5CDA.7010500@oracle.com> <4C0F9051.7080203@oracle.com> <4C15E065.1000101@oracle.com> <4C1C1B1A.1020203@oracle.com> <4C1DA58C.2060700@oracle.com> <4C354E12.3080703@oracle.com> Message-ID: Sorry, forgot to CC the list as well. ---------- Forwarded message ---------- From: Stas Oskin Date: Fri, Jul 9, 2010 at 3:30 PM Subject: Re: JVM hangs beyond recovery To: David Holmes Hi David. > Will appreciate any idea on subject. >> > > Is there any LD debugging/tracing that might help? > > If I understand correctly, you mean tracing LD calls, and trying to see where exactly it hanged, right? Do you know of any tools on Linux that can do it? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100709/29fa2691/attachment.html From David.Holmes at oracle.com Fri Jul 9 17:08:54 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 10 Jul 2010 10:08:54 +1000 Subject: Fwd: JVM hangs beyond recovery In-Reply-To: References: <4BCD0019.2020601@oracle.com> <4C0EC6B9.5020901@oracle.com> <4C0F5B21.8030707@oracle.com> <4C0F5CDA.7010500@oracle.com> <4C0F9051.7080203@oracle.com> <4C15E065.1000101@oracle.com> <4C1C1B1A.1020203@oracle.com> <4C1DA58C.2060700@oracle.com> <4C354E12.3080703@oracle.com> Message-ID: <4C37BA16.1090109@oracle.com> Stas Oskin said the following on 07/09/10 22:30: > Sorry, forgot to CC the list as well. Me too :) > Is there any LD debugging/tracing that might help? > > If I understand correctly, you mean tracing LD calls, and trying to see > where exactly it hanged, right? Right. > Do you know of any tools on Linux that can do it? Something here might help: http://linux.die.net/man/8/ld-linux David From y.s.ramakrishna at oracle.com Fri Jul 9 17:17:36 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Fri, 09 Jul 2010 17:17:36 -0700 Subject: Fwd: JVM hangs beyond recovery In-Reply-To: <4C37BA16.1090109@oracle.com> References: <4C0EC6B9.5020901@oracle.com> <4C0F5B21.8030707@oracle.com> <4C0F5CDA.7010500@oracle.com> <4C0F9051.7080203@oracle.com> <4C15E065.1000101@oracle.com> <4C1C1B1A.1020203@oracle.com> <4C1DA58C.2060700@oracle.com> <4C354E12.3080703@oracle.com> <4C37BA16.1090109@oracle.com> Message-ID: <4C37BC20.5080902@oracle.com> David Holmes wrote: ... > http://linux.die.net/man/8/ld-linux aha, didn't know Linux supported LD_DEBUG too. I bet there's stuff under LD_DEBUG that would help here. -- ramki From stas.oskin at gmail.com Sun Jul 11 13:25:26 2010 From: stas.oskin at gmail.com (Stas Oskin) Date: Sun, 11 Jul 2010 23:25:26 +0300 Subject: Fwd: JVM hangs beyond recovery In-Reply-To: <4C37BC20.5080902@oracle.com> References: <4C0EC6B9.5020901@oracle.com> <4C0F5B21.8030707@oracle.com> <4C0F5CDA.7010500@oracle.com> <4C0F9051.7080203@oracle.com> <4C15E065.1000101@oracle.com> <4C1C1B1A.1020203@oracle.com> <4C1DA58C.2060700@oracle.com> <4C354E12.3080703@oracle.com> <4C37BA16.1090109@oracle.com> <4C37BC20.5080902@oracle.com> Message-ID: Hi. http://linux.die.net/man/8/ld-linux >> > > aha, didn't know Linux supported LD_DEBUG too. I bet there's > stuff under LD_DEBUG that would help here. > > > Actually the help for this variable lists the following switches: libs display library search paths reloc display relocation processing files display progress for input file symbols display symbol table processing bindings display information about symbol binding versions display version dependencies all all previous options combined statistics display relocation statistics unused determined unused DSOs help display this help message and exit I presume I need to try and catch the line where the LD hangs? This will tell me which library the JVM has hanged. Any idea which of these switches will help the most to track this? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100711/68d40162/attachment.html From David.Holmes at oracle.com Sun Jul 11 15:22:51 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 12 Jul 2010 08:22:51 +1000 Subject: Fwd: JVM hangs beyond recovery In-Reply-To: References: <4C0F5B21.8030707@oracle.com> <4C0F5CDA.7010500@oracle.com> <4C0F9051.7080203@oracle.com> <4C15E065.1000101@oracle.com> <4C1C1B1A.1020203@oracle.com> <4C1DA58C.2060700@oracle.com> <4C354E12.3080703@oracle.com> <4C37BA16.1090109@oracle.com> <4C37BC20.5080902@oracle.com> Message-ID: <4C3A443B.1010304@oracle.com> Stas, I would just start with "all" and see what that gives you. David Stas Oskin said the following on 07/12/10 06:25: > Hi. > > http://linux.die.net/man/8/ld-linux > > > aha, didn't know Linux supported LD_DEBUG too. I bet there's > stuff under LD_DEBUG that would help here. > > > > Actually the help for this variable lists the following switches: > > libs display library search paths > reloc display relocation processing > files display progress for input file > symbols display symbol table processing > bindings display information about symbol binding > versions display version dependencies > all all previous options combined > statistics display relocation statistics > unused determined unused DSOs > help display this help message and exit > > > I presume I need to try and catch the line where the LD hangs? This will > tell me which library the JVM has hanged. > > Any idea which of these switches will help the most to track this? > > Regards. From tom.rodriguez at oracle.com Mon Jul 12 11:31:17 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 12 Jul 2010 11:31:17 -0700 Subject: Safepointing & Locking issue In-Reply-To: <4C36F3C7.1080704@nmichael.de> References: <46F2D020-4C2B-405B-A845-73351ACD5979@oracle.com> <4C3614AD.4090905@nmichael.de> <529DD4AC-E757-4762-9C71-82BD86DA7452@oracle.com> <4C36F3C7.1080704@nmichael.de> Message-ID: On Jul 9, 2010, at 3:02 AM, Nicolas Michael wrote: > Am 08.07.2010 20:45, schrieb Tom Rodriguez: >> >> On Jul 8, 2010, at 11:10 AM, Nicolas Michael wrote: >> >>> Hi Tom, >>> >>> our production VM is 6u20, but I already ran some tests with the latest JDK 7 (Hotspot 19.0-b03). Actually, the last numbers I've posted were for Hotspot 19 (where this bug should be fixed, right?)... So it seems the problem presists. >> >> Are you using client or server? I can see some places in client compiler code where we are still using the safepoint variant. Even after the fix you are still being slightly penalized for the use of an agent, it's just that it's not stopped all threads too. If you search the serviceability-dev list for the discussion about 6902182 you can see the issues involved. > > Oh ... we're using client for this application. But that's actually more by mistake ... ;-) Well, it's for historic reasons: Even though most of our applications are loooooong running server-style application, we also need to have the JVM "warm and ready to process requests" right away if it has been restarted -- and therefore couldn't in the past accept the impact of the C2 compiler needing much more resources during this phase. Running on x86 hardware has reduced this problem quite a lot (we deploy fewer JVM's on those boxes, and the high single-thread performance helps C2 compilation as well). > > I have just moved this application to server (with JDK7), and wow: We now see about 20x the throughput for this application than before! No needless safepointing any more! :-) And that also matches about our expectations we've had for running this app on this HW. So, this solves our problem! For my own curiosity can you compare server but without the fix for the 6902182, so 6u20 or 7b82? You've changed two things at once and I'm curious how much came from the fix itself. > > Great, thanks a lot for your help! > > Just out of curiosity, are you going to fix that "slight penalty for the use of an agent" for client as well? ;-) There are two issues. We need to fix the places in client where it's still using VM_DeoptimizeFrame which is probably the major source of your slowdown. I filed 6968367 for that issue. The issue I was actually referring to is that even in server we still need to deopt in some cases to make jvmti exception notification work correctly. Basically during the exception dispatch itself we may force a deopt to avoid double notifies. I had intended to file a bug for that before and forgot so I've done it now. It's 6968383. I don't think anyone will be fixing that issue any time soon since it's lower in our priority than other things. I'll fix the DeoptimizeFrame issue soon though. Thanks! tom > >>> But I will focus on the agent nevertheless. Unfortunately, we have some wrappers around our code launching the JVM, so it's not as simple as just removing the JVM option ... I have to patch the wrapper in order to get rid of the agent. :-( >> >> The only uses of VM_DeoptimizeFrame are associated with JVMTI agent logic so I think that's the right place to look. > > Yep, that was it. > > Thanks again! > > Nick. > >>> Am 08.07.2010 19:16, schrieb Tom Rodriguez: >>>> I suspect you are hitting an issue with agents and exception throwing. It should have been fixed as part of 6902182 which is included in 6u21 which was just released. Basically JVMTI includes functionality that includes tracking the dispatch of exceptions and the machinery for that was being turned on whenever an agent was installed, even if the facility was being used. Part of this was falling back to the interpreter when dispatching the interpreter which is the DeoptimizeFrame safepoints you are seeing. Those don't really need to induce safepoints even if we are tracking exceptions which was also fixed as part of this change. So try out a recent JDK7 or 6u21 and see if you are seeing the asme problem. >>>> >>>> tom >>>> >>>> On Jul 8, 2010, at 6:12 AM, Nicolas Michael wrote: >>>> >>>>> Hi David and Dave, >>>>> >>>>> thanks a lot for your hints and background details on this issue. >>>>> >>>>> Adding -XX:+PrintSafepointStatistics to the options as suggested by David gives >>>>> about 1200+ DeoptimizeFrame's per second in the LogFile: >>>>> >>>>> vmop [threads: total initially_running >>>>> wait_to_block] [time: spin block sync cleanup vmop] page_trap_count >>>>> .. >>>>> 168.976: DeoptimizeFrame [ 217 0 0 >>>>> ] [ 0 0 0 0 0 ] 0 >>>>> 168.976: DeoptimizeFrame [ 217 0 0 >>>>> ] [ 0 0 0 0 0 ] 0 >>>>> 168.978: DeoptimizeFrame [ 217 0 0 >>>>> ] [ 0 0 0 0 0 ] 0 >>>>> 168.978: DeoptimizeFrame [ 217 0 0 >>>>> ] [ 0 0 0 0 0 ] 0 >>>>> 168.978: DeoptimizeFrame [ 217 0 0 >>>>> ] [ 0 0 0 0 0 ] 0 >>>>> .. >>>>> >>>>> The output from the various switches (as also -XX:+LogCompilation) are a bit >>>>> interleaved, but at this point in time (second 168ff) there are no other >>>>> compilation related outputs around. So is there any way to further find out why >>>>> a frame is being deoptimized? This would then lead so a safepoint, right? >>>>> >>>>> Oh, and yes, this JVM does have a JVMTI agent attached to it. But as far as I >>>>> could find out until now, it should only register for GC start/end events (which >>>>> are very rare in this process). >>>>> >>>>> With DTrace I just saw -- thanks to the really cool hotspot probes (some of them >>>>> seem to be new, it's the first time I see that great level of detail!) -- that >>>>> there are about 1000 Exceptions occurring per second ("ExceptionOccurred-entry") >>>>> (but less than one "ThrowNew-entry" per second). I'm not sure how ThrowNew >>>>> relates to ExceptionOccurred and what they are actually counting, and whether >>>>> 1000+ of ExceptionOccurred is "a lot" (it seems quite high ;-) ). Could >>>>> exceptions also cause deoptimization? >>>>> >>>>> Unfortunately we don't have a stand-alone easy to reproduce testcase for this. >>>>> >>>>> These are all the _sync_* that I get: >>>>> >>>>> sun.rt._sync_ContendedLockAttempts = 1625 >>>>> sun.rt._sync_Deflations = 66821 >>>>> sun.rt._sync_EmptyNotifications = 0 >>>>> sun.rt._sync_FailedSpins = 0 >>>>> sun.rt._sync_FutileWakeups = 56 >>>>> sun.rt._sync_Inflations = 66870 >>>>> sun.rt._sync_MonExtant = 6784 >>>>> sun.rt._sync_MonInCirculation = 0 >>>>> sun.rt._sync_MonScavenged = 0 >>>>> sun.rt._sync_Notifications = 116109 >>>>> sun.rt._sync_Parks = 117295 >>>>> sun.rt._sync_PrivateA = 0 >>>>> sun.rt._sync_PrivateB = 0 >>>>> sun.rt._sync_SlowEnter = 0 >>>>> sun.rt._sync_SlowExit = 0 >>>>> sun.rt._sync_SlowNotify = 0 >>>>> sun.rt._sync_SlowNotifyAll = 0 >>>>> sun.rt._sync_SuccessfulSpins = 0 >>>>> >>>>> Thanks for pointing me to synchronizer.cpp, this sounds worth reading your >>>>> comments there! >>>>> >>>>> Thanks, >>>>> Nick. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ext Dave Dice [mailto:dave.dice at oracle.com] >>>>>> Sent: Donnerstag, 8. Juli 2010 13:57 >>>>>> To: Nicolas Michael >>>>>> Cc: hotspot-runtime-dev at openjdk.java.net >>>>>> Subject: Re: Safepointing& Locking issue >>>>>> >>>>>> >>>>>> On 2010-7-8, at 3:21 AM, Nicolas Michael wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I have yesterday been investigating a performance problem >>>>>> with one of our >>>>>>> applications where I observed some "strange" JVM behavior >>>>>> (which might be as >>>>>>> expected, but I'm not sure...). >>>>>>> >>>>>>> It's a heavily multi-threaded Java application with about >>>>>> 300 threads, running >>>>>>> on a 4 CPU Solaris x86 box using a 32bit HotSpot Client VM >>>>>> build 16.3-b01 (JDK >>>>>>> 1.6.0_20-b02). It seems to make extensive use of >>>>>> synchronization and suffers >>>>>>> badly from lock contention. Thread #10 (the VM Thread) eats >>>>>> close to one CPU, >>>>>>> mostly doing lock deflations during safepoints in stacks like this: >>>>>>> >>>>>>> libjvm.so`__1cNObjectMonitorHis_busy6kM_i_+0x26 >>>>>>> >>>>>> libjvm.so`__1cSObjectSynchronizerVdeflate_idle_monitors6F_v_+0x210 >>>>>>> >>>>>> libjvm.so`__1cUSafepointSynchronizeQdo_cleanup_tasks6F_v_+0x19 >>>>>>> libjvm.so`__1cUSafepointSynchronizeFbegin6F_v_+0x3d0 >>>>>>> libjvm.so`__1cIVMThreadEloop6M_v_+0x26c >>>>>>> libjvm.so`__1cIVMThreadDrun6M_v_+0x88 >>>>>>> libjvm.so`java_start+0xf9 >>>>>>> libc.so.1`_thr_setup+0x4e >>>>>>> libc.so.1`_lwp_start >>>>>>> 287 >>>>>>> >>>>>>>> From safepointing point-of-view, the process isn't doing >>>>>> much useful work -- it >>>>>>> only got short periods of work interrupted by safepoints >>>>>> that take longer than >>>>>>> the actual application runtime -- at a rate of 1709 >>>>>> safepoints per second (see >>>>>>> below): >>>>>>> >>>>>>> Application time: 0.0000450 seconds >>>>>>> Total time for which application threads were stopped: >>>>>> 0.0002397 seconds >>>>>>> Application time: 0.0001607 seconds >>>>>>> Total time for which application threads were stopped: >>>>>> 0.0002603 seconds >>>>>>> Application time: 0.0000469 seconds >>>>>>> Total time for which application threads were stopped: >>>>>> 0.0011530 seconds >>>>>>> .. >>>>>>> >>>>>>>> From the perfdata statistics, I see >>>>>>> sun.rt._sync_ContendedLockAttempts increasing by 12 / sec >>>>>>> sun.rt._sync_Deflations increasing by 477 / sec >>>>>>> sun.rt._sync_Inflations increasing by 477 / sec >>>>>>> sun.rt._sync_Notifications increasing by 791 / sec >>>>>>> sun.rt._sync_Parks increasing by 795 / sec >>>>>>> sun.rt.safepoints increasing by 1709 / sec >>>>>>> sun.rt.safepointTime is 0.82s and sun.rt.safepointSyncTime >>>>>> 0.15s per second. >>>>>>> >>>>>>> I guess we're using too much synchronization, >>>>>> Object.wait(ms) and notify() (or >>>>>>> even notifyAll()) ... ;-) but I'm wondering whether it was >>>>>> "normal" to have that >>>>>>> many safepoints and lock inflations/deflations because of that? >>>>>>> >>>>>>> My understanding was that safepoints are mainly caused by >>>>>> GC (not the case here) >>>>>>> or deoptimization (should be visible with +LogCompilation, >>>>>> right? but nothing >>>>>>> there either). Or bias revocation. Indeed, we do have some >>>>>> bias revocations >>>>>>> (like this, see below), but this is at a much lower rate >>>>>> (only ~ 3.4 times per >>>>>>> second): >>>>>> >>>>>> Hi Nick, >>>>>> >>>>>> Do you have test case that's easily packaged up? >>>>>> >>>>>> Inflation can be induced by a number of behaviors, such as >>>>>> wait(), contention, deoptimization, bias revocation, JNI >>>>>> monitor access, some hashCode actions, etc. By default, >>>>>> however, we don't trigger stop-the-world safepoints to >>>>>> deflate. Absent safepoints, the ultimate bound on the >>>>>> number of objectmonitors in play is just the number of live >>>>>> and dead objects in the heap. That is, there's no natural >>>>>> back-pressure on the number of monitors. If the number of >>>>>> monitors becomes too large the JVM can spend inordinate >>>>>> amounts of time in deflate_idle_monitors() scanning, trying >>>>>> to scavenge and deflate monitors, so there's both a time >>>>>> problem and space problem (arguably the space problem drives >>>>>> the time problem, but they manifest differently for customers). >>>>>> >>>>>> There's a day-one assumption in various pieces of code that >>>>>> the object:monitor relationship is stable except over >>>>>> potential safepoints. That simplifies many operations but >>>>>> is the source of the issue you're seeing. Ultimately, it's >>>>>> probably better to deflate on the fly and decouple safepoints >>>>>> from deflation. (The old ExactVM implementation did just >>>>>> that). It's relatively straight-forward, but touches a good >>>>>> deal of code. If you're curious I've left more detailed >>>>>> comments in synchronizer.cpp. >>>>>> >>>>>> In the mean time there are some palliative approaches under >>>>>> consideration to (a) induce STW safepoints to bound the >>>>>> number of extant monitors and in turn bound the cost of >>>>>> deflate_idle_monitors, and (b) partition the monitors so we >>>>>> only need scan those that were possibly inflated in the last >>>>>> STW epoch. We also have code percolating through the >>>>>> system that might cut down on some of the cases of inflation, >>>>>> which is why a test case would be of interest -- to see if >>>>>> the specific case you're running into might already be addressed. >>>>>> >>>>>> I vaguely recall adding a perfdata counter that reflects the >>>>>> number of objectmonitors in the system. Where there any >>>>>> other rt._sync_* variables visible in perfdata? >>>>>> >>>>>> Regards >>>>>> Dave >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Revoking bias with potentially per-thread safepoint: >>>>>>> Revoking bias of object 0x6df887d0 , mark 0x08ee3805 , type >>>>>>> org.jacorb.poa.RequestQueue , prototype header 0x00000005 , >>>>>> allow rebias 0 , >>>>>>> requesting thread 0x09065800 >>>>>>> Revoked bias of currently-unlocked object >>>>>>> >>>>>>> Revoking bias by walking my own stack: >>>>>>> Revoking bias of object 0x6df887c8 , mark 0x09065805 , type >>>>>> java.lang.Object , >>>>>>> prototype header 0x00000005 , allow rebias 0 , requesting >>>>>> thread 0x09065800 >>>>>>> Revoked bias of currently-locked object >>>>>>> Inflating object 0x6df887c8 , mark 0x0906042a , type >>>>>> java.lang.Object >>>>>>> >>>>>>> Also, disabling biased locking has no effect on the >>>>>> magnitude of safepointing, >>>>>>> so I concluded that safepointing must then be caused by >>>>>> lock inflation/deflation >>>>>>> (which seems to be supported by the stack above). >>>>>>> >>>>>>> Afaik a lock is being inflated when the leight-weight >>>>>> locking algorithm can't >>>>>>> acquire the lock immediately ("contention"). It will then >>>>>> fall back to >>>>>>> heavy-weight locking (OS mutex?) and notify (wake up) all >>>>>> waiting threads (?). >>>>>>> We have about 40 lock inflations per contended lock attempt >>>>>> (see the perfdata >>>>>>> statistics above), does that mean there were (on average) >>>>>> 40 threads waiting on >>>>>>> that contended lock? >>>>>>> >>>>>>> Since we have the same amount of deflations as we have >>>>>> inflations, I would >>>>>>> assume that each heavy-weight lock is shortly after being >>>>>> "contended" reverted >>>>>>> to a leight-weight lock again (during a safepoint in >>>>>> deflate_idle_monitors() as >>>>>>> in the stack above??). But why? Couldn't it stay as a >>>>>> heavy-weight lock, instead >>>>>>> of being deflated, only to be inflated shortly after again? >>>>>>> >>>>>>> In the example below, lock 0x96568a60 is being inflated, >>>>>> deflated, inflated >>>>>>> again and then deflated again: >>>>>>> >>>>>>> >>>>>>> Inflating object 0x96568a60 , mark 0x08677ffe , type >>>>>> org.jacorb.poa.RequestProcessor >>>>>>> >>>>>>> Deflating object 0x96568a60 , mark 0x08677ffe , type >>>>>> org.jacorb.poa.RequestProcessor >>>>>>> >>>>>>> Inflating object 0x96568a60 , mark 0x0918f4fe , type >>>>>> org.jacorb.poa.RequestProcessor >>>>>>> >>>>>>> Inflating object 0x79bceee8 , mark 0x08c0b662 , type >>>>>> java.lang.Object >>>>>>> >>>>>>> Inflating object 0x79bceeb0 , mark 0x0914e9ee , type >>>>>> org.jacorb.orb.ReplyReceiver >>>>>>> >>>>>>> Deflating object 0x79bceee8 , mark 0x08c0b662 , type >>>>>> java.lang.Object >>>>>>> Deflating object 0x79bceeb0 , mark 0x0914e9ee , type >>>>>> org.jacorb.orb.ReplyReceiver >>>>>>> Deflating object 0x96568a60 , mark 0x0918f4fe , type >>>>>> org.jacorb.poa.RequestProcessor >>>>>>> >>>>>>> I was just curious whether this is the intended behavior in >>>>>> case of lock >>>>>>> contention, or whether we're seing some pathological >>>>>> strange thing happen here. >>>>>>> >>>>>>> Btw, I've also ran the workload with Hotspot 19.0-b03 from >>>>>> the latest JDK 7 >>>>>>> build with the same results. >>>>>>> >>>>>>> Any comments appreciated! >>>>>>> >>>>>>> Thanks, >>>>>>> Nick. >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >> >> From mailing at nmichael.de Mon Jul 12 15:41:27 2010 From: mailing at nmichael.de (Nicolas Michael) Date: Tue, 13 Jul 2010 00:41:27 +0200 Subject: Safepointing & Locking issue In-Reply-To: References: <46F2D020-4C2B-405B-A845-73351ACD5979@oracle.com> <4C3614AD.4090905@nmichael.de> <529DD4AC-E757-4762-9C71-82BD86DA7452@oracle.com> <4C36F3C7.1080704@nmichael.de> Message-ID: <4C3B9A17.80204@nmichael.de> Am 12.07.2010 20:31, schrieb Tom Rodriguez: > On Jul 9, 2010, at 3:02 AM, Nicolas Michael wrote: > > >> I have just moved this application to server (with JDK7), and wow: We now see about 20x the throughput for this application than before! No needless safepointing any more! :-) And that also matches about our expectations we've had for running this app on this HW. So, this solves our problem! >> > For my own curiosity can you compare server but without the fix for the 6902182, so 6u20 or 7b82? You've changed two things at once and I'm curious how much came from the fix itself. > Generally we see something as a 40% performance gain when going from Client to Server (for Java 6) for most of our applications. This particular application is a bit different and might have slightly different numbers, but "most" (almost all) of the performance gain is definitely due to the fix. Without that fix (and using Client), the application was spending 82% of the elapsed time in a safepoint (sun.rt.safepointTime) and 15% coming to a safepoint (sun.rt.safepointSyncTime) -- if I interprete those correctly. If I add those two up, there isn't much remaining time for doing useful work ... With the fix, this time is down to close to zero. I also had a testrun with 6u20 and Server, which was slightly better than with Client, but not much (about 25% - 33%). It's a bit difficult to really compare those to the one with the fix, as for the testruns without the fix, it's not only the throughput that's bad, but also the response times -- and due to the resulting lock contention, the CPU load was rather spiky and unstable. Therefore, I would say, the throughput gain (for Server) was in the range of 10x to 15x comparing 6u20 and the latest JDK 7 (HS 19), plus improved response times as well. I guess this huge performance increase might be something special for this particular application (lots of threads, lots of locks being accessed rather frequently and by multiple threads), so that safepointing became very expensive since it had to deflate "idle monitors" (that weren't that idle at all and were shortly after inflated again). >> Just out of curiosity, are you going to fix that "slight penalty for the use of an agent" for client as well? ;-) >> > There are two issues. We need to fix the places in client where it's still using VM_DeoptimizeFrame which is probably the major source of your slowdown. I filed 6968367 for that issue. The issue I was actually referring to is that even in server we still need to deopt in some cases to make jvmti exception notification work correctly. Basically during the exception dispatch itself we may force a deopt to avoid double notifies. I had intended to file a bug for that before and forgot so I've done it now. It's 6968383. I don't think anyone will be fixing that issue any time soon since it's lower in our priority than other things. I'll fix the DeoptimizeFrame issue soon though. Thanks! > Great, thanks! Nick. From alan.bateman at oracle.com Fri Jul 16 08:34:33 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 16 Jul 2010 15:34:33 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6649594: Intermittent IOExceptions during dynamic attach on linux and solaris Message-ID: <20100716153442.3994947A2C@hg.openjdk.java.net> Changeset: a81afd9c293c Author: alanb Date: 2010-07-16 13:14 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a81afd9c293c 6649594: Intermittent IOExceptions during dynamic attach on linux and solaris Reviewed-by: dcubed, dholmes ! src/os/linux/vm/attachListener_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp From john.coomes at oracle.com Fri Jul 16 11:35:26 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Jul 2010 18:35:26 +0000 Subject: hg: jdk7/hotspot-rt: Added tag jdk7-b100 for changeset b218a53ec7d3 Message-ID: <20100716183526.6E0E247A35@hg.openjdk.java.net> Changeset: 4193eaf5f1b8 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/4193eaf5f1b8 Added tag jdk7-b100 for changeset b218a53ec7d3 ! .hgtags From john.coomes at oracle.com Fri Jul 16 11:35:30 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Jul 2010 18:35:30 +0000 Subject: hg: jdk7/hotspot-rt/corba: Added tag jdk7-b100 for changeset a56d734a1e97 Message-ID: <20100716183533.A955B47A36@hg.openjdk.java.net> Changeset: 86a239832646 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/86a239832646 Added tag jdk7-b100 for changeset a56d734a1e97 ! .hgtags From john.coomes at oracle.com Fri Jul 16 11:54:52 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Jul 2010 18:54:52 +0000 Subject: hg: jdk7/hotspot-rt/jaxp: Added tag jdk7-b100 for changeset d524be5ef62e Message-ID: <20100716185452.5546B47A37@hg.openjdk.java.net> Changeset: 17f62a566a20 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/17f62a566a20 Added tag jdk7-b100 for changeset d524be5ef62e ! .hgtags From john.coomes at oracle.com Fri Jul 16 11:54:56 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Jul 2010 18:54:56 +0000 Subject: hg: jdk7/hotspot-rt/jaxws: Added tag jdk7-b100 for changeset bd26d0ce0c3c Message-ID: <20100716185456.B5F2247A38@hg.openjdk.java.net> Changeset: b55ce2744900 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/b55ce2744900 Added tag jdk7-b100 for changeset bd26d0ce0c3c ! .hgtags From john.coomes at oracle.com Fri Jul 16 11:55:07 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Jul 2010 18:55:07 +0000 Subject: hg: jdk7/hotspot-rt/jdk: 3 new changesets Message-ID: <20100716185644.2FEDD47A39@hg.openjdk.java.net> Changeset: 820b4e843d51 Author: ohair Date: 2010-07-07 10:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/820b4e843d51 6967036: Need to fix links with // in Javadoc comments Reviewed-by: mchung ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java ! src/share/classes/com/sun/security/auth/LdapPrincipal.java ! src/share/classes/com/sun/security/sasl/CramMD5Client.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/ExternalClient.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/nio/charset/package.html ! src/share/classes/javax/management/remote/JMXServiceURL.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/sun/awt/image/PNGImageDecoder.java Changeset: 93c4e6d14010 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/93c4e6d14010 Added tag jdk7-b100 for changeset 820b4e843d51 ! .hgtags Changeset: d58354a69011 Author: bpatel Date: 2010-07-14 15:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d58354a69011 6955341: Oracle rebranding changes for man pages Reviewed-by: darcy ! src/linux/doc/man/appletviewer.1 ! src/linux/doc/man/apt.1 ! src/linux/doc/man/extcheck.1 ! src/linux/doc/man/idlj.1 ! src/linux/doc/man/ja/appletviewer.1 ! src/linux/doc/man/ja/apt.1 ! src/linux/doc/man/ja/extcheck.1 ! src/linux/doc/man/ja/idlj.1 ! src/linux/doc/man/ja/jar.1 ! src/linux/doc/man/ja/jarsigner.1 ! src/linux/doc/man/ja/java.1 ! src/linux/doc/man/ja/javac.1 ! src/linux/doc/man/ja/javadoc.1 ! src/linux/doc/man/ja/javah.1 ! src/linux/doc/man/ja/javap.1 ! src/linux/doc/man/ja/javaws.1 ! src/linux/doc/man/ja/jconsole.1 ! src/linux/doc/man/ja/jdb.1 ! src/linux/doc/man/ja/jhat.1 ! src/linux/doc/man/ja/jinfo.1 ! src/linux/doc/man/ja/jmap.1 ! src/linux/doc/man/ja/jps.1 ! src/linux/doc/man/ja/jrunscript.1 ! src/linux/doc/man/ja/jsadebugd.1 ! src/linux/doc/man/ja/jstack.1 ! src/linux/doc/man/ja/jstat.1 ! src/linux/doc/man/ja/jstatd.1 ! src/linux/doc/man/ja/keytool.1 - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 ! src/linux/doc/man/ja/native2ascii.1 ! src/linux/doc/man/ja/orbd.1 ! src/linux/doc/man/ja/pack200.1 ! src/linux/doc/man/ja/policytool.1 ! src/linux/doc/man/ja/rmic.1 ! src/linux/doc/man/ja/rmid.1 ! src/linux/doc/man/ja/rmiregistry.1 ! src/linux/doc/man/ja/schemagen.1 ! src/linux/doc/man/ja/serialver.1 ! src/linux/doc/man/ja/servertool.1 ! src/linux/doc/man/ja/tnameserv.1 ! src/linux/doc/man/ja/unpack200.1 ! src/linux/doc/man/ja/wsgen.1 ! src/linux/doc/man/ja/wsimport.1 ! src/linux/doc/man/ja/xjc.1 ! src/linux/doc/man/jar.1 ! src/linux/doc/man/jarsigner.1 ! src/linux/doc/man/java.1 ! src/linux/doc/man/javac.1 ! src/linux/doc/man/javadoc.1 ! src/linux/doc/man/javah.1 ! src/linux/doc/man/javap.1 ! src/linux/doc/man/javaws.1 ! src/linux/doc/man/jconsole.1 ! src/linux/doc/man/jdb.1 ! src/linux/doc/man/jhat.1 ! src/linux/doc/man/jinfo.1 ! src/linux/doc/man/jmap.1 ! src/linux/doc/man/jps.1 ! src/linux/doc/man/jrunscript.1 ! src/linux/doc/man/jsadebugd.1 ! src/linux/doc/man/jstack.1 ! src/linux/doc/man/jstat.1 ! src/linux/doc/man/jstatd.1 ! src/linux/doc/man/keytool.1 ! src/linux/doc/man/native2ascii.1 ! src/linux/doc/man/orbd.1 ! src/linux/doc/man/pack200.1 ! src/linux/doc/man/policytool.1 ! src/linux/doc/man/rmic.1 ! src/linux/doc/man/rmid.1 ! src/linux/doc/man/rmiregistry.1 ! src/linux/doc/man/schemagen.1 ! src/linux/doc/man/serialver.1 ! src/linux/doc/man/servertool.1 ! src/linux/doc/man/tnameserv.1 ! src/linux/doc/man/unpack200.1 ! src/linux/doc/man/wsgen.1 ! src/linux/doc/man/wsimport.1 ! src/linux/doc/man/xjc.1 ! src/solaris/doc/sun/man/man1/appletviewer.1 ! src/solaris/doc/sun/man/man1/apt.1 ! src/solaris/doc/sun/man/man1/extcheck.1 ! src/solaris/doc/sun/man/man1/idlj.1 ! src/solaris/doc/sun/man/man1/ja/appletviewer.1 ! src/solaris/doc/sun/man/man1/ja/apt.1 ! src/solaris/doc/sun/man/man1/ja/extcheck.1 ! src/solaris/doc/sun/man/man1/ja/idlj.1 ! src/solaris/doc/sun/man/man1/ja/jar.1 ! src/solaris/doc/sun/man/man1/ja/jarsigner.1 ! src/solaris/doc/sun/man/man1/ja/java.1 ! src/solaris/doc/sun/man/man1/ja/javac.1 ! src/solaris/doc/sun/man/man1/ja/javadoc.1 ! src/solaris/doc/sun/man/man1/ja/javah.1 ! src/solaris/doc/sun/man/man1/ja/javap.1 ! src/solaris/doc/sun/man/man1/ja/javaws.1 ! src/solaris/doc/sun/man/man1/ja/jconsole.1 ! src/solaris/doc/sun/man/man1/ja/jdb.1 ! src/solaris/doc/sun/man/man1/ja/jhat.1 ! src/solaris/doc/sun/man/man1/ja/jinfo.1 ! src/solaris/doc/sun/man/man1/ja/jmap.1 ! src/solaris/doc/sun/man/man1/ja/jps.1 ! src/solaris/doc/sun/man/man1/ja/jrunscript.1 ! src/solaris/doc/sun/man/man1/ja/jsadebugd.1 ! src/solaris/doc/sun/man/man1/ja/jstack.1 ! src/solaris/doc/sun/man/man1/ja/jstat.1 ! src/solaris/doc/sun/man/man1/ja/jstatd.1 ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/ja/native2ascii.1 ! src/solaris/doc/sun/man/man1/ja/orbd.1 ! src/solaris/doc/sun/man/man1/ja/pack200.1 ! src/solaris/doc/sun/man/man1/ja/policytool.1 ! src/solaris/doc/sun/man/man1/ja/rmic.1 ! src/solaris/doc/sun/man/man1/ja/rmid.1 ! src/solaris/doc/sun/man/man1/ja/rmiregistry.1 ! src/solaris/doc/sun/man/man1/ja/schemagen.1 ! src/solaris/doc/sun/man/man1/ja/serialver.1 ! src/solaris/doc/sun/man/man1/ja/servertool.1 ! src/solaris/doc/sun/man/man1/ja/tnameserv.1 ! src/solaris/doc/sun/man/man1/ja/unpack200.1 ! src/solaris/doc/sun/man/man1/ja/wsgen.1 ! src/solaris/doc/sun/man/man1/ja/wsimport.1 ! src/solaris/doc/sun/man/man1/ja/xjc.1 ! src/solaris/doc/sun/man/man1/jar.1 ! src/solaris/doc/sun/man/man1/jarsigner.1 ! src/solaris/doc/sun/man/man1/java.1 ! src/solaris/doc/sun/man/man1/javac.1 ! src/solaris/doc/sun/man/man1/javadoc.1 ! src/solaris/doc/sun/man/man1/javah.1 ! src/solaris/doc/sun/man/man1/javap.1 ! src/solaris/doc/sun/man/man1/javaws.1 ! src/solaris/doc/sun/man/man1/jconsole.1 ! src/solaris/doc/sun/man/man1/jdb.1 ! src/solaris/doc/sun/man/man1/jhat.1 ! src/solaris/doc/sun/man/man1/jinfo.1 ! src/solaris/doc/sun/man/man1/jmap.1 ! src/solaris/doc/sun/man/man1/jps.1 ! src/solaris/doc/sun/man/man1/jrunscript.1 ! src/solaris/doc/sun/man/man1/jsadebugd.1 ! src/solaris/doc/sun/man/man1/jstack.1 ! src/solaris/doc/sun/man/man1/jstat.1 ! src/solaris/doc/sun/man/man1/jstatd.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! src/solaris/doc/sun/man/man1/native2ascii.1 ! src/solaris/doc/sun/man/man1/orbd.1 ! src/solaris/doc/sun/man/man1/pack200.1 ! src/solaris/doc/sun/man/man1/policytool.1 ! src/solaris/doc/sun/man/man1/rmic.1 ! src/solaris/doc/sun/man/man1/rmid.1 ! src/solaris/doc/sun/man/man1/rmiregistry.1 ! src/solaris/doc/sun/man/man1/schemagen.1 ! src/solaris/doc/sun/man/man1/serialver.1 ! src/solaris/doc/sun/man/man1/servertool.1 ! src/solaris/doc/sun/man/man1/tnameserv.1 ! src/solaris/doc/sun/man/man1/unpack200.1 ! src/solaris/doc/sun/man/man1/wsgen.1 ! src/solaris/doc/sun/man/man1/wsimport.1 ! src/solaris/doc/sun/man/man1/xjc.1 From john.coomes at oracle.com Fri Jul 16 12:08:38 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Jul 2010 19:08:38 +0000 Subject: hg: jdk7/hotspot-rt/langtools: Added tag jdk7-b100 for changeset d1d7595fa824 Message-ID: <20100716190845.9AF5047A3B@hg.openjdk.java.net> Changeset: 20a8fe72ee7b Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/20a8fe72ee7b Added tag jdk7-b100 for changeset d1d7595fa824 ! .hgtags From andrei.pangin at sun.com Sun Jul 18 01:38:15 2010 From: andrei.pangin at sun.com (andrei.pangin at sun.com) Date: Sun, 18 Jul 2010 08:38:15 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 14 new changesets Message-ID: <20100718083840.B228247AA7@hg.openjdk.java.net> Changeset: 65b0c03b165d Author: never Date: 2010-07-02 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/65b0c03b165d 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 Reviewed-by: kvn, dcubed ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp Changeset: 60a14ad85270 Author: kvn Date: 2010-07-02 17:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/60a14ad85270 6966411: escape.cpp:450 assert(base->Opcode() == Op_ConP Summary: Execute IGVN optimization before and after Escape Analysis Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: a693e51ac197 Author: never Date: 2010-07-07 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a693e51ac197 Merge Changeset: b2a00dd3117c Author: jcoomes Date: 2010-07-01 21:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b2a00dd3117c 6957084: simplify TaskQueue overflow handling Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 9ee05c8ab82f Author: ysr Date: 2010-07-12 12:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/9ee05c8ab82f Merge Changeset: 1e7ec26380bd Author: apangin Date: 2010-07-14 17:52 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1e7ec26380bd Merge Changeset: 2a47bd84841f Author: never Date: 2010-07-08 14:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2a47bd84841f 6965184: possible races in make_not_entrant_or_zombie Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/vmStructs.cpp - src/share/vm/runtime/vtune.hpp Changeset: 3941674cc7fa Author: never Date: 2010-07-12 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3941674cc7fa 6958668: repeated uncommon trapping for new of klass which is being initialized Reviewed-by: kvn, jrose ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parseHelper.cpp Changeset: 8d5934a77f10 Author: never Date: 2010-07-12 22:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8d5934a77f10 6968385: malformed xml in sweeper logging Reviewed-by: kvn ! src/share/vm/runtime/sweeper.cpp Changeset: 079980c86f33 Author: kvn Date: 2010-07-14 14:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/079980c86f33 6968646: JVM crashes with SIGFPE during startup Summary: Check that cpuid returns valid values for processor topology (not zeros). Reviewed-by: never, twisti ! src/cpu/x86/vm/vm_version_x86.hpp Changeset: 8099e71601df Author: kvn Date: 2010-07-14 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8099e71601df 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies Summary: Use GrowableArray and VectorSet allocated in ciEnv arena. Reviewed-by: never, twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core Changeset: a528509c992b Author: never Date: 2010-07-15 08:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a528509c992b 6968336: VM crash guarantee(!nm->is_zombie()) failed: cannot lock a zombie method Reviewed-by: twisti ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp Changeset: 61fdaf88f57f Author: never Date: 2010-07-15 13:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/61fdaf88f57f Merge - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp - src/share/vm/runtime/vtune.hpp Changeset: 920aa833fd16 Author: apangin Date: 2010-07-17 21:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/920aa833fd16 Merge From daniel.daugherty at oracle.com Tue Jul 20 11:35:17 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 20 Jul 2010 12:35:17 -0600 Subject: SDK Test Fixes Batch for 2010.07 (6941287, 6962804, 6964018) Message-ID: <4C45EC65.7020707@oracle.com> Greetings, I have fixes for three different test bugs ready to go for OpenJDK7. I've run these tests manually on Linux, Solaris SPARC, Solaris X86 and WinXP/Cygwin. I've run these tests through JPRT several times to make sure they are stable (which also covers WinXP/MKS). I've been running select tests from this set in loops for 12-24 hours on Linux, Solaris X86 and WinXP/Cygwin to make sure they don't hiccup. This first fix I've had for a while and it has been used in my personal baseline testing for the last several JDK7 promotions: http://cr.openjdk.java.net/~dcubed/6941287-webrev/0/ Yes, it could be refactored to use some of the newer logic that I added in the fix for 6964018, but that's a task that should be applied to all the test/sun/tools/* tests. This second fix was intended to add diagnostic information for tracking down some of the strange intermittent failures on Windows: http://cr.openjdk.java.net/~dcubed/6962804-webrev/0/ However, the fix seems to have solved the intermittent failures on Windows problem. I haven't seen these failures reproduce in my personal baseline testing on the last several JDK7 promotions and a stress loop using JDK7-B98 bits hasn't reproduced the failures either. I suspect that my refactoring of the logic that handles a missing NL at the end of a file has fixed this problem. The scaffold no longer creates a temporary file every time a test runs; it is only created when needed to solve the missing NL problem. The third fix gets my recent Logger WeakReference leak tests back into the available test mix: http://cr.openjdk.java.net/~dcubed/6964018-webrev/0/ This fix refactors and enhances some of the test infrastructure in test/sun/tools/common/* and changes the new Logger WeakReference leak tests to use that infrastructure. Other tests in test/sun/tools/* also need minor tweaks to fit into the new infrastructure. Thanks, in advance, for any reviews. Dan From daniel.daugherty at oracle.com Tue Jul 20 11:52:57 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 20 Jul 2010 12:52:57 -0600 Subject: SDK Test Fixes Batch for 2010.07 (6941287, 6962804, 6964018) In-Reply-To: <4C45EC65.7020707@oracle.com> References: <4C45EC65.7020707@oracle.com> Message-ID: <4C45F089.3000101@oracle.com> One thing I forgot to make clear about this fix. For the folks that were worried about the test execution time for the two new tests, I was able to add an early bailout if the test detected that the instance count was the same or decreasing for the target leak(s). This means that test now only runs until it determines that the bits being tested have the fix in place. Only bits without the fix will execute for the full time. Dan On 7/20/2010 12:35 PM, Daniel D. Daugherty wrote: > The third fix gets my recent Logger WeakReference leak tests back into > the available test mix: > > http://cr.openjdk.java.net/~dcubed/6964018-webrev/0/ > > This fix refactors and enhances some of the test infrastructure in > test/sun/tools/common/* and changes the new Logger WeakReference leak > tests to use that infrastructure. Other tests in test/sun/tools/* > also need minor tweaks to fit into the new infrastructure. From kelly.ohair at oracle.com Tue Jul 20 13:22:22 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 20 Jul 2010 13:22:22 -0700 Subject: SDK Test Fixes Batch for 2010.07 (6941287, 6962804, 6964018) In-Reply-To: <4C45EC65.7020707@oracle.com> References: <4C45EC65.7020707@oracle.com> Message-ID: The first two batches look fine to me. The last one was pretty big, and I poked around a little, looks fine to me, but I am not sure I gave it a very good review. I think getting these tests right may be more difficult than getting the API to work. :^{ So for risking your sanity and working on these tests, you get 3 gold stars. ;^) -kto On Jul 20, 2010, at 11:35 AM, Daniel D. Daugherty wrote: > Greetings, > > I have fixes for three different test bugs ready to go for OpenJDK7. > I've run these tests manually on Linux, Solaris SPARC, Solaris X86 > and WinXP/Cygwin. I've run these tests through JPRT several times to > make sure they are stable (which also covers WinXP/MKS). I've been > running select tests from this set in loops for 12-24 hours on Linux, > Solaris X86 and WinXP/Cygwin to make sure they don't hiccup. > > This first fix I've had for a while and it has been used in my > personal > baseline testing for the last several JDK7 promotions: > > http://cr.openjdk.java.net/~dcubed/6941287-webrev/0/ > > Yes, it could be refactored to use some of the newer logic that I > added > in the fix for 6964018, but that's a task that should be applied to > all > the test/sun/tools/* tests. > > This second fix was intended to add diagnostic information for > tracking > down some of the strange intermittent failures on Windows: > > http://cr.openjdk.java.net/~dcubed/6962804-webrev/0/ > > However, the fix seems to have solved the intermittent failures on > Windows problem. I haven't seen these failures reproduce in my > personal > baseline testing on the last several JDK7 promotions and a stress loop > using JDK7-B98 bits hasn't reproduced the failures either. I suspect > that my refactoring of the logic that handles a missing NL at the end > of a file has fixed this problem. The scaffold no longer creates a > temporary file every time a test runs; it is only created when needed > to solve the missing NL problem. > > The third fix gets my recent Logger WeakReference leak tests back into > the available test mix: > > http://cr.openjdk.java.net/~dcubed/6964018-webrev/0/ > > This fix refactors and enhances some of the test infrastructure in > test/sun/tools/common/* and changes the new Logger WeakReference leak > tests to use that infrastructure. Other tests in test/sun/tools/* > also need minor tweaks to fit into the new infrastructure. > > Thanks, in advance, for any reviews. > > Dan > > From daniel.daugherty at oracle.com Tue Jul 20 13:58:12 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 20 Jul 2010 14:58:12 -0600 Subject: SDK Test Fixes Batch for 2010.07 (6941287, 6962804, 6964018) In-Reply-To: References: <4C45EC65.7020707@oracle.com> Message-ID: <4C460DE4.7020802@oracle.com> On 7/20/2010 2:22 PM, Kelly O'Hair wrote: > The first two batches look fine to me. Thanks! > The last one was pretty big, and I poked around a little, looks fine > to me, > but I am not sure I gave it a very good review. I'll wait to see if one of the original Logger WeakRef leak reviewers chimes in here (Alan, David or Eamonn...) I'm very confident of the tests at this point; you've probably seen all the test JPRT jobs that I've been sending through... :-) > I think getting these tests right may be more difficult than getting > the API to work. :^{ Hence the refactoring of the infrastructure stuff into common files. I'm getting tired of fixing this infrastructure stuff in more than one place... > So for risking your sanity and working on these tests, you get 3 gold > stars. ;^) Thanks! There will be more fixes coming in the test arena... Dan > > > > -kto > > On Jul 20, 2010, at 11:35 AM, Daniel D. Daugherty wrote: > >> Greetings, >> >> I have fixes for three different test bugs ready to go for OpenJDK7. >> I've run these tests manually on Linux, Solaris SPARC, Solaris X86 >> and WinXP/Cygwin. I've run these tests through JPRT several times to >> make sure they are stable (which also covers WinXP/MKS). I've been >> running select tests from this set in loops for 12-24 hours on Linux, >> Solaris X86 and WinXP/Cygwin to make sure they don't hiccup. >> >> This first fix I've had for a while and it has been used in my personal >> baseline testing for the last several JDK7 promotions: >> >> http://cr.openjdk.java.net/~dcubed/6941287-webrev/0/ >> >> Yes, it could be refactored to use some of the newer logic that I added >> in the fix for 6964018, but that's a task that should be applied to all >> the test/sun/tools/* tests. >> >> This second fix was intended to add diagnostic information for tracking >> down some of the strange intermittent failures on Windows: >> >> http://cr.openjdk.java.net/~dcubed/6962804-webrev/0/ >> >> However, the fix seems to have solved the intermittent failures on >> Windows problem. I haven't seen these failures reproduce in my personal >> baseline testing on the last several JDK7 promotions and a stress loop >> using JDK7-B98 bits hasn't reproduced the failures either. I suspect >> that my refactoring of the logic that handles a missing NL at the end >> of a file has fixed this problem. The scaffold no longer creates a >> temporary file every time a test runs; it is only created when needed >> to solve the missing NL problem. >> >> The third fix gets my recent Logger WeakReference leak tests back into >> the available test mix: >> >> http://cr.openjdk.java.net/~dcubed/6964018-webrev/0/ >> >> This fix refactors and enhances some of the test infrastructure in >> test/sun/tools/common/* and changes the new Logger WeakReference leak >> tests to use that infrastructure. Other tests in test/sun/tools/* >> also need minor tweaks to fit into the new infrastructure. >> >> Thanks, in advance, for any reviews. >> >> Dan >> >> > From andrei.pangin at sun.com Tue Jul 20 15:42:59 2010 From: andrei.pangin at sun.com (andrei.pangin at sun.com) Date: Tue, 20 Jul 2010 22:42:59 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6964170: Verifier crashes Message-ID: <20100720224302.7838347B2C@hg.openjdk.java.net> Changeset: a5c9d63a187d Author: apangin Date: 2010-07-20 08:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a5c9d63a187d 6964170: Verifier crashes Summary: Check if klassOop != NULL rather than klass_part != NULL Reviewed-by: kamg, never ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verifier.cpp From daniel.daugherty at oracle.com Wed Jul 21 13:12:19 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 21 Jul 2010 14:12:19 -0600 Subject: [Fwd: Re: SDK Test Fixes Batch for 2010.07 (6941287, 6962804, 6964018)] Message-ID: <4C4754A3.3060808@oracle.com> Here is relevant e-mail about the third fix (6964018) that I sent to Alan Bateman off list. It's probably interesting to anyone else that plans to review 6964018... Dan -------- Original Message -------- Subject: Re: SDK Test Fixes Batch for 2010.07 (6941287, 6962804, 6964018) Date: Wed, 21 Jul 2010 09:16:29 -0600 From: Daniel D. Daugherty Reply-To: daniel.daugherty at oracle.com To: Alan Bateman References: <4C45EC65.7020707 at oracle.com> On 7/20/2010 12:35 PM, Daniel D. Daugherty wrote: > The third fix gets my recent Logger WeakReference leak tests back into > the available test mix: > > http://cr.openjdk.java.net/~dcubed/6964018-webrev/0/ > > This fix refactors and enhances some of the test infrastructure in > test/sun/tools/common/* and changes the new Logger WeakReference leak > tests to use that infrastructure. Other tests in test/sun/tools/* > also need minor tweaks to fit into the new infrastructure. Here is what changed in the webrev. Now that I've written it out I can see why it looks like a lot. I'm hoping that you think I've made some good and useful improvements to both the infrastructure and tests that you created... Dan test/java/util/logging/AnonLoggerWeakRefLeak.java - refactored to be a subclass of SimpleApplication - changed duration from 60 -> 120 seconds because 60 seconds wasn't reliably reproducing the leak on an overloaded test machine test/java/util/logging/AnonLoggerWeakRefLeak.sh - refactored to use sun/tools/common/* infrastructure - drop incoming env check; now in CommonSetup.sh - drop command paths; now in CommonSetup.sh - drop grep_cmd function and rework both grep calls and sed calls to use PATTERN_EOL and PATTERN_WS constants - drop flag setting code; now in CommonSetup.sh - drop app launch and pid finding stuff in favor of startApplication, stopApplication, waitApplication and killApplication - changed timeout from 3 minutes to 4 minutes since test can now run for 2 minutes instead of 1 minute - rework jmap version check to not crash process group on Linux - rework jmap retry stuff to work around intermittent jmap bugs - allow for early termination if instance count is the same or decreasing which indicates that the bits being tested have the fix. - clarify messages when the test fails and when the test pass test/java/util/logging/LoggerWeakRefLeak.java - refactored to be a subclass of SimpleApplication test/java/util/logging/LoggerWeakRefLeak.sh - same fixes as for AnonLoggerWeakRefLeak.sh except the timeout was already 4 minutes for this test test/sun/tools/common/ApplicationSetup.sh - startApplication changes: - rename exported "pid" variable to appJavaPid; add appOtherPid, appPidList and appOutput exported variables - refactor "-classpath $TESTCLASSES" into function - switch to "$@" to preserve arg spacing - redirect stderr to output file in addition to stdout - refactor Cygwin pid logic to use "ps" and "sed" instead of "ps", "tail" and "awk" (fewer pipes and processes) - refactor MKS pid logic use "ps" and "sed" instead of "ps", "grep", "grep", "cut" (fewer pipes and processes) - stopApplication changes - refactor ShutdownSimpleApplication classname into function - add waitForApplication() and killApplication functions test/sun/tools/common/CommonSetup.sh - add JPS program path constant; also sorted the constants - add PATTERN_EOL and PATTERN_WS constants - cleanup incoming env vars check a bit - add 'set -eu' for paranoia - add isFoo flags (Cygwin, MKS, Linux,Solaris, Unknown and Windows) - change Cygwin PS value from ";" to (default) ":" test/sun/tools/common/CommonTests.sh - new tests for the infrastructure in ApplicationSetup.sh and CommonSetup.sh; allows for easier porting test/sun/tools/common/ShutdownSimpleApplication.java - Fix comment about the class argument being a file that contains the port number instead of being the port number - added a usage check for wrong number of parameters - added a "done connecting" message - added System.exit(0) (set -e now in use) test/sun/tools/common/SimpleApplication.java - clarify that the class argument is a file that contains the port number. - refactor main() into doMyAppStart(), doMyAppWork() and doMyAppFinish() pieces to permit easy subclassing - add getMyApp() and setMyApp() - refactor main() to permit subclassing test/sun/tools/common/SleeperApplication.java - add SleeperApplication to illustrate subclassing of SimpleApplication test/sun/tools/jhat/ParseTest.sh - add missing failed variable initialization - add 'set +e' since this test already checks return statuses test/sun/tools/jinfo/Basic.sh - refactor startApplication and stopApplication calls - add waitForApplication call - use "appJavaPid" variable instead of "pid" variable - use new flags as appropriate - add 'set +e' since this test already checks return statuses test/sun/tools/jmap/Basic.sh - refactor startApplication and stopApplication calls - add waitForApplication call - use "appJavaPid" variable instead of "pid" variable - add 'set +e' since this test already checks return statuses - delete unnecessary "p" variable setting and usage test/sun/tools/jstack/Basic.sh - refactor startApplication and stopApplication calls - add waitForApplication call - use "appJavaPid" variable instead of "pid" variable - add 'set +e' since this test already checks return statuses From daniel.daugherty at oracle.com Wed Jul 21 13:12:25 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 21 Jul 2010 14:12:25 -0600 Subject: [Fwd: SDK Test Fixes Batch for 2010.07 (6941287, 6962804, 6964018)] In-Reply-To: <4C474DE9.2070109@oracle.com> References: <4C467204.6000100@oracle.com> <4C46CF24.6020909@oracle.com> <4C46E765.1040205@oracle.com> <4C474DE9.2070109@oracle.com> Message-ID: <4C4754A9.4070006@oracle.com> Alan, I'm adding the OpenJDK aliases back into this e-mail thread for this reply. Just trying to keep folks in the loop... Thanks for squeezing in time for a review of 6964018. On 7/21/2010 1:43 PM, Alan Bateman wrote: > Daniel D. Daugherty wrote: >> On 7/21/2010 4:42 AM, Alan Bateman wrote: >>> Daniel D. Daugherty wrote: >>>> Alan, >>>> >>>> A quick look from you at the third webrev would be much appreciated... >>>> >>>> Dan >>> Sorry Dan, I just don't have the cycles today due to a couple of >>> high priority issues. I might get cycles on Friday if we really >>> want me to review. >> >> I may just go with only Kelly's review. :-| > I just spent 15-20m going through > http://cr.openjdk.java.net/~dcubed/6964018-webrev/0/ in more detail > and it looks fine to me. Thanks for explaining about the refactoring > as it looks more than it really is on first glance. I'm happy with > the updates to the existing tests and happy to see the new > test/java/util/logging tests are more reliable. Given that this is > tests only change then one reviewer should be fine. I'll put both you and Kelly down for 6964018. I'll put just Kelly down for the first two. Of course, that could change if I get more reviewer comments. > Minor nits in ShutdownSimpleApplication.java is that System.exit is > probably not needed. Because I added the 'set -e' option, I think it is needed. Otherwise I get a random process exit status. > Also the pre-existing empty comment lines L25-26 can probably be removed. I wondered why those were there so I left them in. I had meant to ping you about them, but I forgot... I'll remove them. > Same comments for SimpleApplication. Hopefully, the same resolutions will be OK with you. > BTW: In test/java/util/logging/LoggerWeakRefLeak.sh you can listed > issues with jmap - are they still valid with the updated test and the > recent fix to the attach API? I suspect that your recent attach API fix will resolve those issues, but I plan to specifically test for that after your fix gets promoted. > The only outstanding issue that I can think of is where you try to > attach just as the process is about to exit (but with the updated test > this doesn't happen due to the "handshake"/socket connection). Agreed and thank you for pointing me in that direction. Dan From David.Holmes at oracle.com Wed Jul 21 16:41:38 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 22 Jul 2010 09:41:38 +1000 Subject: [Fwd: SDK Test Fixes Batch for 2010.07 (6941287, 6962804, 6964018)] In-Reply-To: <4C4754A9.4070006@oracle.com> References: <4C467204.6000100@oracle.com> <4C46CF24.6020909@oracle.com> <4C46E765.1040205@oracle.com> <4C474DE9.2070109@oracle.com> <4C4754A9.4070006@oracle.com> Message-ID: <4C4785B2.1080809@oracle.com> Dan, You can add me to the first two if you like. The third was over my head :) As Alan said these are test changes so not so critical ... and if there's a problem with them you get to fix it again :) Cheers, David Daniel D. Daugherty said the following on 07/22/10 06:12: > Alan, > > I'm adding the OpenJDK aliases back into this e-mail thread for > this reply. Just trying to keep folks in the loop... > > Thanks for squeezing in time for a review of 6964018. > > > On 7/21/2010 1:43 PM, Alan Bateman wrote: >> Daniel D. Daugherty wrote: >>> On 7/21/2010 4:42 AM, Alan Bateman wrote: >>>> Daniel D. Daugherty wrote: >>>>> Alan, >>>>> >>>>> A quick look from you at the third webrev would be much appreciated... >>>>> >>>>> Dan >>>> Sorry Dan, I just don't have the cycles today due to a couple of >>>> high priority issues. I might get cycles on Friday if we really >>>> want me to review. >>> >>> I may just go with only Kelly's review. :-| >> I just spent 15-20m going through >> http://cr.openjdk.java.net/~dcubed/6964018-webrev/0/ in more detail >> and it looks fine to me. Thanks for explaining about the refactoring >> as it looks more than it really is on first glance. I'm happy with >> the updates to the existing tests and happy to see the new >> test/java/util/logging tests are more reliable. Given that this is >> tests only change then one reviewer should be fine. > > I'll put both you and Kelly down for 6964018. I'll put just Kelly > down for the first two. Of course, that could change if I get more > reviewer comments. > > >> Minor nits in ShutdownSimpleApplication.java is that System.exit is >> probably not needed. > > Because I added the 'set -e' option, I think it is needed. Otherwise > I get a random process exit status. > > >> Also the pre-existing empty comment lines L25-26 can probably be removed. > > I wondered why those were there so I left them in. I had meant to > ping you about them, but I forgot... I'll remove them. > > >> Same comments for SimpleApplication. > > Hopefully, the same resolutions will be OK with you. > > >> BTW: In test/java/util/logging/LoggerWeakRefLeak.sh you can listed >> issues with jmap - are they still valid with the updated test and the >> recent fix to the attach API? > > I suspect that your recent attach API fix will resolve those > issues, but I plan to specifically test for that after your > fix gets promoted. > > >> The only outstanding issue that I can think of is where you try to >> attach just as the process is about to exit (but with the updated test >> this doesn't happen due to the "handshake"/socket connection). > > Agreed and thank you for pointing me in that direction. > > Dan > From daniel.daugherty at oracle.com Wed Jul 21 16:43:59 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 21 Jul 2010 17:43:59 -0600 Subject: [Fwd: SDK Test Fixes Batch for 2010.07 (6941287, 6962804, 6964018)] In-Reply-To: <4C4785B2.1080809@oracle.com> References: <4C467204.6000100@oracle.com> <4C46CF24.6020909@oracle.com> <4C46E765.1040205@oracle.com> <4C474DE9.2070109@oracle.com> <4C4754A9.4070006@oracle.com> <4C4785B2.1080809@oracle.com> Message-ID: <4C47863F.90304@oracle.com> On 7/21/2010 5:41 PM, David Holmes wrote: > Dan, > > You can add me to the first two if you like. Thanks! > The third was over my head :) I doubt that, but I have two for that one :-) > As Alan said these are test changes so not so critical ... Unless you're trying to get an SDK/JDK job through the JPRT queue :-) > and if there's a problem with them you get to fix it again :) Yup. And now I have a template/shared code to use to fix other annoyingly intermittent tests... Dan > > Cheers, > David > > Daniel D. Daugherty said the following on 07/22/10 06:12: >> Alan, >> >> I'm adding the OpenJDK aliases back into this e-mail thread for >> this reply. Just trying to keep folks in the loop... >> >> Thanks for squeezing in time for a review of 6964018. >> >> >> On 7/21/2010 1:43 PM, Alan Bateman wrote: >>> Daniel D. Daugherty wrote: >>>> On 7/21/2010 4:42 AM, Alan Bateman wrote: >>>>> Daniel D. Daugherty wrote: >>>>>> Alan, >>>>>> >>>>>> A quick look from you at the third webrev would be much >>>>>> appreciated... >>>>>> >>>>>> Dan >>>>> Sorry Dan, I just don't have the cycles today due to a couple of >>>>> high priority issues. I might get cycles on Friday if we really >>>>> want me to review. >>>> >>>> I may just go with only Kelly's review. :-| >>> I just spent 15-20m going through >>> http://cr.openjdk.java.net/~dcubed/6964018-webrev/0/ in more detail >>> and it looks fine to me. Thanks for explaining about the refactoring >>> as it looks more than it really is on first glance. I'm happy with >>> the updates to the existing tests and happy to see the new >>> test/java/util/logging tests are more reliable. Given that this is >>> tests only change then one reviewer should be fine. >> >> I'll put both you and Kelly down for 6964018. I'll put just Kelly >> down for the first two. Of course, that could change if I get more >> reviewer comments. >> >> >>> Minor nits in ShutdownSimpleApplication.java is that System.exit is >>> probably not needed. >> >> Because I added the 'set -e' option, I think it is needed. Otherwise >> I get a random process exit status. >> >> >>> Also the pre-existing empty comment lines L25-26 can probably be >>> removed. >> >> I wondered why those were there so I left them in. I had meant to >> ping you about them, but I forgot... I'll remove them. >> >> >>> Same comments for SimpleApplication. >> >> Hopefully, the same resolutions will be OK with you. >> >> >>> BTW: In test/java/util/logging/LoggerWeakRefLeak.sh you can listed >>> issues with jmap - are they still valid with the updated test and >>> the recent fix to the attach API? >> >> I suspect that your recent attach API fix will resolve those >> issues, but I plan to specifically test for that after your >> fix gets promoted. >> >> >>> The only outstanding issue that I can think of is where you try to >>> attach just as the process is about to exit (but with the updated >>> test this doesn't happen due to the "handshake"/socket connection). >> >> Agreed and thank you for pointing me in that direction. >> >> Dan >> From john.coomes at oracle.com Thu Jul 22 22:29:33 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Jul 2010 05:29:33 +0000 Subject: hg: jdk7/hotspot-rt: 4 new changesets Message-ID: <20100723052933.3F11547BCD@hg.openjdk.java.net> Changeset: 055626b50d2d Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/055626b50d2d Added tag jdk7-b101 for changeset 4193eaf5f1b8 ! .hgtags Changeset: a191e79df156 Author: lana Date: 2010-06-29 10:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/a191e79df156 Merge Changeset: 9cda7c220c08 Author: lana Date: 2010-07-12 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/9cda7c220c08 Merge Changeset: a136a51f5113 Author: lana Date: 2010-07-20 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/a136a51f5113 Merge From john.coomes at oracle.com Thu Jul 22 22:30:09 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Jul 2010 05:30:09 +0000 Subject: hg: jdk7/hotspot-rt/corba: 4 new changesets Message-ID: <20100723053013.D8C0847BCE@hg.openjdk.java.net> Changeset: d130544adab3 Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/d130544adab3 Added tag jdk7-b101 for changeset 86a239832646 ! .hgtags Changeset: 03fd3d78e344 Author: lana Date: 2010-06-29 10:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/03fd3d78e344 Merge Changeset: 98da66f47273 Author: lana Date: 2010-07-12 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/98da66f47273 Merge Changeset: 78561a957790 Author: lana Date: 2010-07-20 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/78561a957790 Merge From john.coomes at oracle.com Thu Jul 22 22:35:27 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Jul 2010 05:35:27 +0000 Subject: hg: jdk7/hotspot-rt/jaxp: 5 new changesets Message-ID: <20100723053527.8AAA447BD0@hg.openjdk.java.net> Changeset: c9bd73f6d584 Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/c9bd73f6d584 Added tag jdk7-b101 for changeset 17f62a566a20 ! .hgtags Changeset: 34ed99f84832 Author: ohair Date: 2010-06-24 08:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/34ed99f84832 6963941: Correct download link for source drop bundle Reviewed-by: darcy ! jaxp.properties Changeset: e46c304486c0 Author: lana Date: 2010-06-29 10:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/e46c304486c0 Merge Changeset: 70c8a34e2eb6 Author: lana Date: 2010-07-12 19:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/70c8a34e2eb6 Merge Changeset: 15573625af97 Author: lana Date: 2010-07-20 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/15573625af97 Merge From john.coomes at oracle.com Thu Jul 22 22:36:03 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Jul 2010 05:36:03 +0000 Subject: hg: jdk7/hotspot-rt/jaxws: 4 new changesets Message-ID: <20100723053603.9FE2347BD1@hg.openjdk.java.net> Changeset: d1525c38428a Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/d1525c38428a Added tag jdk7-b101 for changeset b55ce2744900 ! .hgtags Changeset: 2dd6394ddec2 Author: lana Date: 2010-06-29 10:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/2dd6394ddec2 Merge Changeset: 2b7a1ec9562e Author: lana Date: 2010-07-12 19:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/2b7a1ec9562e Merge Changeset: d8580443d181 Author: lana Date: 2010-07-20 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/d8580443d181 Merge From john.coomes at oracle.com Thu Jul 22 22:38:47 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Jul 2010 05:38:47 +0000 Subject: hg: jdk7/hotspot-rt/jdk: 76 new changesets Message-ID: <20100723055105.5855547BD2@hg.openjdk.java.net> Changeset: 6c4450bbad6d Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6c4450bbad6d Added tag jdk7-b101 for changeset d58354a69011 ! .hgtags Changeset: c801686d91f4 Author: prr Date: 2010-06-29 09:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c801686d91f4 6943487: NPE in makeMultiCharsetString while printing on linux Reviewed-by: igor, jgodinez ! src/share/classes/sun/awt/PlatformFont.java ! src/share/classes/sun/java2d/HeadlessGraphicsEnvironment.java Changeset: 4da6837dd085 Author: lana Date: 2010-06-30 15:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4da6837dd085 Merge Changeset: ab55cb957830 Author: igor Date: 2010-07-06 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ab55cb957830 6967050: JDK build issues with cygwin/vc2010 Reviewed-by: prr, ohair ! make/common/shared/Defs-windows.gmk ! make/mkdemo/Makefile Changeset: e03065fc64e7 Author: igor Date: 2010-07-12 13:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e03065fc64e7 6959998: Return of SurfaceData_InitOps point not checked in all cases (parfait found these) Reviewed-by: prr Contributed-by: ohair ! src/share/native/sun/awt/image/BufImgSurfaceData.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp Changeset: 2ad69cb576b4 Author: igor Date: 2010-07-12 15:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2ad69cb576b4 6968373: FontUtilities static initializer throws AccessControlException Reviewed-by: prr ! src/share/classes/sun/font/FontUtilities.java ! test/java/awt/FontClass/FontPrivilege.java Changeset: 4a639bcd3361 Author: lana Date: 2010-07-12 19:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4a639bcd3361 Merge Changeset: f5145c7119c2 Author: yan Date: 2010-06-24 11:50 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f5145c7119c2 6957166: With XAWT, set arguments properly creating a MouseWheelEvent. Summary: swap some parameters to allow bigger values for click count. Reviewed-by: dav ! src/solaris/classes/sun/awt/X11/XWindow.java Changeset: bccf2a4ee318 Author: art Date: 2010-07-06 17:59 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/bccf2a4ee318 6424157: java.awt.EventQueue push/pop might cause threading issues Reviewed-by: ant, dcherepanov ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/SunToolkit.java ! test/java/awt/EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java + test/java/awt/EventDispatchThread/PreserveDispathThread/PreserveDispatchThread.java ! test/java/awt/EventQueue/PushPopDeadlock2/PushPopTest.java Changeset: 21b17c64df74 Author: dcherepanov Date: 2010-07-06 18:23 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/21b17c64df74 6966643: GTK FileDialog hangs when user manually closes it Reviewed-by: art ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c Changeset: 9950dc616615 Author: dcherepanov Date: 2010-07-07 14:20 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9950dc616615 6959174: Need to introduce sun.awt.disableGtkFileDialogs system property Reviewed-by: art, anthony ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 48aa2a1edd2b Author: lana Date: 2010-07-08 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/48aa2a1edd2b Merge Changeset: 2d8f060dd1c5 Author: lana Date: 2010-07-12 19:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2d8f060dd1c5 Merge Changeset: 69ddf06e616a Author: malenkov Date: 2010-06-22 12:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/69ddf06e616a 6707234: Method returned by Introspector.internalFindMethod not necessarily most specific Reviewed-by: peterz ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test6707234.java Changeset: 5af3b0430bbe Author: peterz Date: 2010-06-22 14:36 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5af3b0430bbe 6959260: javax/swing/JLabel/6501991/bug6501991.java failed on build 1.7.0-ea-b96 Reviewed-by: rupashka ! src/share/classes/sun/swing/SwingUtilities2.java ! test/ProblemList.txt ! test/com/sun/java/swing/plaf/gtk/Test6635110.java Changeset: dea63f6dda7a Author: alexp Date: 2010-06-22 19:38 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/dea63f6dda7a 6777378: NullPointerException in XPDefaultRenderer.paint() Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java + test/javax/swing/JTable/6777378/bug6777378.java Changeset: a05e047c5b98 Author: alexp Date: 2010-06-22 20:36 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a05e047c5b98 6684401: JTree isExpanded should not call itself recursively Reviewed-by: rupashka ! src/share/classes/javax/swing/JTree.java Changeset: f1bafc4f249d Author: peterz Date: 2010-06-29 14:42 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f1bafc4f249d 6963870: NPE in CompoundBorder.getInsets() Reviewed-by: alexp Contributed-by: jon.vanalten at redhat.com ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java + test/com/sun/java/swing/plaf/gtk/Test6963870.java Changeset: c0e785f055a7 Author: lana Date: 2010-06-30 19:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c0e785f055a7 Merge ! test/ProblemList.txt Changeset: d062afbe2107 Author: malenkov Date: 2010-07-01 18:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d062afbe2107 4129681: Cannot get a title border to display its label as disabled Reviewed-by: alexp, rupashka ! src/share/classes/javax/swing/border/TitledBorder.java + test/javax/swing/border/Test4129681.html + test/javax/swing/border/Test4129681.java + test/javax/swing/border/Test4760089.html + test/javax/swing/border/Test4760089.java Changeset: 46306a419ba3 Author: malenkov Date: 2010-07-01 18:47 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/46306a419ba3 6959266: test javax/swing/JInternalFrame/6725409/bug6725409.java should be modified Reviewed-by: alexp ! test/javax/swing/JInternalFrame/6725409/bug6725409.java Changeset: e94a94d176f9 Author: alexp Date: 2010-07-02 19:28 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e94a94d176f9 6711682: JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java + test/javax/swing/AbstractButton/6711682/bug6711682.java Changeset: 46d5aef470a3 Author: alexp Date: 2010-07-02 19:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/46d5aef470a3 6937415: Some components return undocumented default values under Nimbus LaF Reviewed-by: peterz ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/plaf/nimbus/skin.laf Changeset: e12c92d2dc11 Author: rupashka Date: 2010-07-08 19:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e12c92d2dc11 6520101: FileChooser will cause OutOfMemory when application will run long time Reviewed-by: peterz ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java + test/javax/swing/JFileChooser/6520101/bug6520101.java Changeset: d0bcc9aa5a7a Author: malenkov Date: 2010-07-09 19:42 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d0bcc9aa5a7a 6894597: test/closed/javax/swing/JPopupMenu/6495920/bug6495920.java fails Reviewed-by: alexp, peterz + test/javax/swing/JPopupMenu/6495920/bug6495920.java Changeset: 3dc686ecb4cd Author: malenkov Date: 2010-07-09 22:07 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3dc686ecb4cd 6963811: Deadlock-prone locking changes in Introspector Reviewed-by: peterz, rupashka ! src/share/classes/com/sun/beans/finder/InstanceFinder.java ! src/share/classes/com/sun/beans/finder/PersistenceDelegateFinder.java ! src/share/classes/com/sun/beans/finder/PropertyEditorFinder.java ! src/share/classes/java/beans/Encoder.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyEditorManager.java + test/java/beans/Introspector/Test6963811.java + test/java/beans/PropertyEditor/Test6963811.java + test/java/beans/XMLEncoder/Test6963811.java Changeset: a93a7ed5018c Author: lana Date: 2010-07-12 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a93a7ed5018c Merge Changeset: dd98b0b747ec Author: ohair Date: 2010-06-22 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/dd98b0b747ec 6931871: Rebranding of javadoc generation in makefiles 6951293: control docs target does not work on windows Reviewed-by: jjg + make/common/shared/Defs-javadoc.gmk ! make/docs/Makefile Changeset: d7fdaee81c14 Author: sherman Date: 2010-06-22 14:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d7fdaee81c14 6963156: TEST_BUG: Several tests under sun/nio/cs failed Summary: Updated the test cases and removed them from ProblemList.txt Reviewed-by: alanb ! test/ProblemList.txt ! test/sun/nio/cs/FindDecoderBugs.java ! test/sun/nio/cs/TestX11CNS.java Changeset: 6fe3b86f4720 Author: sherman Date: 2010-06-22 14:22 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6fe3b86f4720 Merge Changeset: 4e76be6e9fe1 Author: dcubed Date: 2010-06-22 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4e76be6e9fe1 6942989: 2/2 Memory leak of java.lang.ref.WeakReference objects Summary: Use ReferenceQueues to manage WeakReferences in LogManager and Logger. Reviewed-by: dholmes, alanb, emcmanus, tonyp Contributed-by: jeremymanson at google.com ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/AnonLoggerWeakRefLeak.java + test/java/util/logging/AnonLoggerWeakRefLeak.sh + test/java/util/logging/LoggerWeakRefLeak.java + test/java/util/logging/LoggerWeakRefLeak.sh Changeset: 600ef8b4a211 Author: dcubed Date: 2010-06-22 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/600ef8b4a211 Merge Changeset: 25fe5c3bf7b7 Author: ohair Date: 2010-06-22 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/25fe5c3bf7b7 6939022: Source code adjustments for parfait compilation Reviewed-by: jjg ! src/solaris/demo/jni/Poller/Poller.c Changeset: 848e69fcf2f3 Author: ohair Date: 2010-06-22 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/848e69fcf2f3 6933622: Duplicate class files in rt.jar and charsets.jar 6895003: JarReorder is not excluding a requested file. Reviewed-by: jjg ! make/common/Release.gmk ! make/tools/src/build/tools/jarreorder/JarReorder.java ! test/ProblemList.txt Changeset: 3c745249065f Author: ohair Date: 2010-06-22 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3c745249065f Merge Changeset: 887e525597f8 Author: dsamersoff Date: 2010-06-23 17:25 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/887e525597f8 6931566: NetworkInterface is not working when interface name is more than 15 characters long Summary: Separate Linux and Solaris code, use lifreq under Solaris Reviewed-by: chegar ! src/solaris/native/java/net/NetworkInterface.c Changeset: eb84b89ef3ff Author: alanb Date: 2010-06-23 20:19 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/eb84b89ef3ff 6963027: TEST_BUG: channels and buffer tests need to run in samevm mode Reviewed-by: ohair, sherman, chegar ! test/Makefile ! test/ProblemList.txt ! test/java/nio/BufferPoolMXBean/Basic.java ! test/java/nio/MappedByteBuffer/Basic.java ! test/java/nio/MappedByteBuffer/Force.java ! test/java/nio/MappedByteBuffer/ZeroMap.java ! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java ! test/java/nio/channels/AsynchronousChannelGroup/Identity.java ! test/java/nio/channels/AsynchronousDatagramChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/Lock.java ! test/java/nio/channels/AsynchronousFileChannel/LotsOfWrites.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java ! test/java/nio/channels/Channels/Basic2.java ! test/java/nio/channels/Channels/Write.java ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java ! test/java/nio/channels/DatagramChannel/EmptyBuffer.java ! test/java/nio/channels/DatagramChannel/ReceiveISA.java ! test/java/nio/channels/DatagramChannel/SelectWhenRefused.java ! test/java/nio/channels/FileChannel/Args.java ! test/java/nio/channels/FileChannel/ClosedChannelTransfer.java ! test/java/nio/channels/FileChannel/ExpandingMap.java ! test/java/nio/channels/FileChannel/Lock.java ! test/java/nio/channels/FileChannel/MapOverEnd.java ! test/java/nio/channels/FileChannel/MapReadOnly.java ! test/java/nio/channels/FileChannel/MapTest.java ! test/java/nio/channels/FileChannel/Mode.java ! test/java/nio/channels/FileChannel/Position.java ! test/java/nio/channels/FileChannel/Pread.java ! test/java/nio/channels/FileChannel/Pwrite.java ! test/java/nio/channels/FileChannel/Read.java ! test/java/nio/channels/FileChannel/ReadFull.java ! test/java/nio/channels/FileChannel/ReadToLimit.java ! test/java/nio/channels/FileChannel/ReleaseOnCloseDeadlock.java ! test/java/nio/channels/FileChannel/ScatteringRead.java ! test/java/nio/channels/FileChannel/Size.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/channels/FileChannel/TransferToChannel.java ! test/java/nio/channels/FileChannel/TransferToNonWritable.java ! test/java/nio/channels/FileChannel/Transfers.java ! test/java/nio/channels/FileChannel/TryLock.java ! test/java/nio/channels/FileChannel/Write.java ! test/java/nio/channels/Pipe/NonBlocking.java ! test/java/nio/channels/Pipe/SelectPipe.java ! test/java/nio/channels/SelectionKey/AtomicAttachTest.java ! test/java/nio/channels/Selector/BasicAccept.java ! test/java/nio/channels/Selector/BasicConnect.java ! test/java/nio/channels/Selector/CheckLocking.java ! test/java/nio/channels/Selector/CloseInvalidatesKeys.java ! test/java/nio/channels/Selector/CloseWhenKeyIdle.java ! test/java/nio/channels/Selector/Connect.java ! test/java/nio/channels/Selector/ConnectWrite.java ! test/java/nio/channels/Selector/HelperSlowToDie.java ! test/java/nio/channels/Selector/KeysReady.java ! test/java/nio/channels/Selector/LotsOfChannels.java ! test/java/nio/channels/Selector/RegAfterPreClose.java ! test/java/nio/channels/Selector/SelectAndCancel.java ! test/java/nio/channels/Selector/SelectorLimit.java ! test/java/nio/channels/Selector/SelectorTest.java ! test/java/nio/channels/Selector/WakeupNow.java ! test/java/nio/channels/Selector/WakeupOverflow.java ! test/java/nio/channels/Selector/WakeupSpeed.java - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java ! test/java/nio/channels/SocketChannel/Bind.java ! test/java/nio/channels/SocketChannel/Close.java ! test/java/nio/channels/SocketChannel/CloseRegisteredChannel.java ! test/java/nio/channels/SocketChannel/CloseTimeoutChannel.java ! test/java/nio/channels/SocketChannel/IsConnectable.java ! test/java/nio/channels/SocketChannel/LocalAddress.java ! test/java/nio/channels/SocketChannel/SocketInheritance.java ! test/java/nio/channels/SocketChannel/Trivial.java ! test/java/nio/channels/SocketChannel/UnboundSocketTests.java ! test/java/nio/channels/etc/Shadow.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/ClosedStreams.java ! test/sun/nio/ch/Basic.java ! test/sun/nio/ch/TempBuffer.java ! test/sun/nio/cs/ReadZero.java ! test/sun/nio/cs/Test4206507.java ! test/sun/nio/cs/TestStringCoding.java Changeset: 55aa27b8bb98 Author: alanb Date: 2010-06-23 21:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/55aa27b8bb98 Merge Changeset: c4d60bcce958 Author: darcy Date: 2010-06-23 17:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c4d60bcce958 6911258: Project Coin: Add essential API support for Automatic Resource Management (ARM) blocks 6911261: Project Coin: Retrofit Automatic Resource Management (ARM) support onto platform APIs 6962571: Infinite loop in printing out Throwable stack traces with circular references Reviewed-by: darcy, alanb Contributed-by: jjb at google.com ! make/java/java/FILES_java.gmk ! src/share/classes/java/io/Closeable.java + src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/javax/imageio/stream/ImageInputStream.java + test/java/lang/Throwable/SuppressedExceptions.java Changeset: 706e2d1fc378 Author: weijun Date: 2010-06-24 14:26 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/706e2d1fc378 6958026: Problem with PKCS12 keystore Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java + test/sun/security/pkcs12/PKCS12SameKeyId.java Changeset: 1da7dfca3e20 Author: weijun Date: 2010-06-24 14:26 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1da7dfca3e20 6844907: krb5 etype order should be from strong to weak Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java + test/sun/security/krb5/etype/ETypeOrder.java ! test/sun/security/krb5/ktab/HighestKvno.java Changeset: 9c0f542c8b37 Author: weijun Date: 2010-06-24 14:26 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9c0f542c8b37 6946669: SSL/Krb5 should not call EncryptedData.reset(data, false) Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/EncryptedData.java ! src/share/classes/sun/security/krb5/KrbApRep.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbCred.java ! src/share/classes/sun/security/krb5/KrbPriv.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! src/share/classes/sun/security/ssl/krb5/KerberosPreMasterSecret.java ! test/sun/security/krb5/auto/SSL.java Changeset: 2e9ef9a80d82 Author: ohair Date: 2010-06-25 08:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2e9ef9a80d82 6964311: Build regression due to rt.jar contents change Summary: The fix for 6933622 regressed control builds, this is a workaround fix, filed 6964313 to find the right answer to why it happened and how to fix it correctly. Reviewed-by: alanb, darcy ! make/common/Release.gmk Changeset: 6bf403a14da4 Author: alanb Date: 2010-06-25 18:31 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6bf403a14da4 6963828: TEST_BUG: java/nio/channels/FileTransfer.java takes too long (win) Reviewed-by: chegar ! test/java/nio/channels/FileChannel/Transfer.java Changeset: 0995c5a2dc6d Author: alanb Date: 2010-06-25 18:34 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0995c5a2dc6d Merge Changeset: 6d274503d1b7 Author: chegar Date: 2010-06-28 14:55 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6d274503d1b7 6954525: Testcase failure java/net/Authenticator/B4769350.java Reviewed-by: michaelm, weijun ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/java/net/Authenticator/B4769350.java Changeset: a89f8c292a5b Author: chegar Date: 2010-06-28 15:06 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a89f8c292a5b Merge Changeset: 7c3da1f0e17c Author: chegar Date: 2010-06-28 20:52 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7c3da1f0e17c 6961029: java/net/BindException/Test.java should not use wildcard address Reviewed-by: michaelm, alanb ! test/ProblemList.txt ! test/java/net/BindException/Test.java ! test/java/net/ipv6tests/Tests.java Changeset: a9e0a6fb6057 Author: ksrini Date: 2010-06-28 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a9e0a6fb6057 6856415: Enabling java security manager will make programe thrown wrong exception ( main method not found ) Reviewed-by: darcy ! src/share/classes/sun/launcher/LauncherHelper.java + test/tools/launcher/VerifyExceptions.java Changeset: 5c5fe62d990d Author: alanb Date: 2010-06-29 17:11 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5c5fe62d990d 6213702: (so) non-blocking sockets with TCP urgent disabled get still selected for read ops (win) Reviewed-by: michaelm, chegar ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/native/sun/nio/ch/WindowsSelectorImpl.c + test/java/nio/channels/Selector/OutOfBand.java Changeset: b318df97820f Author: lana Date: 2010-06-29 10:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b318df97820f Merge Changeset: 4436a3e97a9b Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4436a3e97a9b 6934268: Better implementation of Character.isValidCodePoint Summary: Use the cleverest possible bit-twiddling micro-optimizations Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/Character.java Changeset: 1776791f4fb9 Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1776791f4fb9 6934265: Add public method Character.isBmpCodePoint Summary: Move isBmpCodePoint from sun.nio.cs.Surrogate to Character Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/String.java ! src/share/classes/sun/io/CharToByteDBCS_ASCII.java ! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java ! src/share/classes/sun/nio/cs/Surrogate.java ! src/share/classes/sun/nio/cs/UTF_32Coder.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/IBM33722.java ! src/share/classes/sun/nio/cs/ext/IBM964.java ! test/java/nio/charset/coders/BashStreams.java - test/java/nio/charset/coders/Surrogate.java ! test/java/nio/charset/coders/Surrogates.java Changeset: 5503dbb2e6cc Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5503dbb2e6cc 6937112: String.lastIndexOf confused by unpaired trailing surrogate Summary: Rewrite lastIndexOf for performance and correctness Reviewed-by: sherman Contributed-by: Reviewed by Ulf Zibis ! src/share/classes/java/lang/String.java ! test/java/lang/String/Supplementary.java ! test/java/lang/StringBuffer/Supplementary.java ! test/java/lang/StringBuilder/Supplementary.java Changeset: 5e9daa8fd04a Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5e9daa8fd04a 6940381: Wording improvements for String.indexOf, String.lastIndexOf Summary: Make wording of javadoc clearer and more consistent Reviewed-by: sherman ! src/share/classes/java/lang/String.java Changeset: 0d2bff3b2ca6 Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0d2bff3b2ca6 6963749: Minor improvements to Character.UnicodeBlock Summary: Fix surrogate area docs; make source more readable Reviewed-by: okutsu, sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/Character.java Changeset: 4f1b4e3c6d1b Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4f1b4e3c6d1b 6934270: Remove javac warnings from Character.java Summary: Use generics and conform to coding style Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/Character.java Changeset: 98186c162c1e Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/98186c162c1e 6933322: Add methods highSurrogate(), lowSurrogate() to class Character Summary: Add public variants of methods Surrogate.high, Surrogate.low Reviewed-by: okutsu, sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/String.java ! src/share/classes/sun/nio/cs/Surrogate.java ! src/share/classes/sun/nio/cs/UTF_32Coder.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/UnicodeEncoder.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! test/java/nio/charset/coders/BashStreams.java Changeset: 838a21b99591 Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/838a21b99591 6934271: Better handling of longer utf-8 sequences Summary: Various cleanups, including clever bit-twiddling Reviewed-by: sherman ! src/share/classes/sun/nio/cs/UTF_8.java Changeset: 9c80da212eaf Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9c80da212eaf 6935172: Optimize bit-twiddling in Bits.java Summary: Transformations to reduce size of bytecode Reviewed-by: sherman Contributed-by: Based on an idea by Ulf Zibis ! src/share/classes/java/io/Bits.java Changeset: ce0ba8da0bd1 Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ce0ba8da0bd1 6940258: (bf) Use intrinsified reverseBytes operation; elide no-op constructs Reviewed-by: alanb, sherman Contributed-by: Ulf Zibis ! src/share/classes/java/nio/Bits.java Changeset: a5a34c696d62 Author: alanb Date: 2010-07-01 16:28 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a5a34c696d62 6947216: Even more Dual-pivot quicksort improvements Reviewed-by: jjb Contributed-by: vladimir.yaroslavskiy at sun.com ! src/share/classes/java/util/DualPivotQuicksort.java ! test/java/util/Arrays/Sorting.java Changeset: 9bffc32b645d Author: mullan Date: 2010-07-01 15:20 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9bffc32b645d 6782979: Add JNLPAppletLauncher (6618105) to blacklist Reviewed-by: ohair ! make/java/security/Makefile Changeset: c0d2a097eb99 Author: mullan Date: 2010-07-01 15:30 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c0d2a097eb99 Merge Changeset: 425960cef714 Author: darcy Date: 2010-07-06 18:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/425960cef714 6963723: Project Coin: Retrofit more JDK classes for ARM Reviewed-by: alanb, malenkov, prr, amenkov ! src/share/classes/java/beans/XMLDecoder.java ! src/share/classes/java/beans/XMLEncoder.java ! src/share/classes/java/io/ObjectInput.java ! src/share/classes/java/io/ObjectOutput.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/javax/sound/midi/MidiDevice.java ! src/share/classes/javax/sound/midi/Receiver.java ! src/share/classes/javax/sound/midi/Transmitter.java ! src/share/classes/javax/sound/sampled/Line.java Changeset: d6f8ffc3c54a Author: ohair Date: 2010-07-07 10:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d6f8ffc3c54a 6954517: Testcase failure tools/launcher/UnicodeTest.sh Reviewed-by: ksrini ! test/tools/launcher/UnicodeTest.sh Changeset: f13e94562d84 Author: ksrini Date: 2010-07-09 09:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f13e94562d84 6930056: (launcher) Need to remove or build as part of test these liblibrary.so files Reviewed-by: ohair, darcy - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: da8526047e5f Author: martin Date: 2010-07-09 18:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/da8526047e5f 6967533: Epoch bug: ExceptionInInitializerError on systems with uninitialized clock Summary: Remove (hopefully!) unnecessary check of currentTimeMillis Reviewed-by: dholmes Contributed-by: Jon VanAlten ! src/share/classes/java/lang/System.java Changeset: a7f8f269f741 Author: chegar Date: 2010-07-12 18:13 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a7f8f269f741 6967937: Scope id no longer being set after 6931566 Reviewed-by: alanb, dsamersoff ! src/solaris/native/java/net/NetworkInterface.c ! test/java/net/Inet6Address/B6214234.java Changeset: 1371a2d5f3a8 Author: chegar Date: 2010-07-12 18:16 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1371a2d5f3a8 6967684: httpserver using a non thread-safe SimpleDateFormat Reviewed-by: michaelm ! src/share/classes/sun/net/httpserver/ExchangeImpl.java Changeset: bb0b32ffefe9 Author: chegar Date: 2010-07-12 18:18 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/bb0b32ffefe9 6966846: Incorrect assertion in java.net.Inet6Address.readObject Reviewed-by: michaelm ! src/share/classes/java/net/Inet6Address.java Changeset: d3fa95d0710c Author: ksrini Date: 2010-07-09 11:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d3fa95d0710c 6921472: RFE: java launcher code needs clean up Summary: This changeset also contains fixes for 6405284, 6753938 and 6922500 Reviewed-by: darcy ! src/share/bin/emessages.h ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/jli_util.c ! src/share/bin/jli_util.h ! src/solaris/bin/java_md.c ! src/windows/bin/java_md.c ! test/tools/launcher/Arrrghs.java Changeset: ddf825161d2d Author: dcubed Date: 2010-07-12 14:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ddf825161d2d 6968401: 3/3 disable tests added by 6942989 until 6964018 is fixed Summary: Disable AnonLoggerWeakRefLeak.sh and LoggerWeakRefLeak.sh Reviewed-by: ohair ! test/java/util/logging/AnonLoggerWeakRefLeak.sh ! test/java/util/logging/LoggerWeakRefLeak.sh Changeset: 4e365ef6576d Author: dcubed Date: 2010-07-12 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4e365ef6576d Merge Changeset: c5a436f053aa Author: lana Date: 2010-07-12 19:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c5a436f053aa Merge ! test/ProblemList.txt - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: 13029a61b16b Author: lana Date: 2010-07-20 22:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/13029a61b16b Merge - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so From john.coomes at oracle.com Thu Jul 22 23:02:35 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Jul 2010 06:02:35 +0000 Subject: hg: jdk7/hotspot-rt/langtools: 8 new changesets Message-ID: <20100723060252.7EC9047BD3@hg.openjdk.java.net> Changeset: f87f1f3e23e1 Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/f87f1f3e23e1 Added tag jdk7-b101 for changeset 20a8fe72ee7b ! .hgtags Changeset: be5cafeb318d Author: darcy Date: 2010-06-23 16:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/be5cafeb318d 6911258: Project Coin: Add essential API support for Automatic Resource Management (ARM) blocks Reviewed-by: darcy, alanb Contributed-by: jjb at google.com ! src/share/classes/javax/lang/model/element/ElementKind.java Changeset: d8a15fda7e3a Author: jjg Date: 2010-06-24 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d8a15fda7e3a 6917288: Unnamed nested class is not generated Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/6917288/GraphicalInstaller.java + test/tools/javac/6917288/GraphicalInstallerTest.java + test/tools/javac/6917288/T6917288.java Changeset: 6386f0fd6205 Author: lana Date: 2010-06-29 12:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/6386f0fd6205 Merge ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.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/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: d2b7ecf33b35 Author: jjg Date: 2010-06-30 18:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d2b7ecf33b35 6964768: need test program to validate javac resource bundles Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/literals/BadUnderscoreLiterals.6.out Changeset: 064468702a8d Author: jjg Date: 2010-07-12 16:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/064468702a8d 6968497: localized text appears in raw diagnostic Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/generics/6946618/T6946618c.java ! test/tools/javac/generics/6946618/T6946618c.out Changeset: eaab979c8b36 Author: lana Date: 2010-07-12 19:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/eaab979c8b36 Merge Changeset: ff9c0a0bf7ed Author: lana Date: 2010-07-20 22:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/ff9c0a0bf7ed Merge From daniel.daugherty at oracle.com Fri Jul 23 17:48:02 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 23 Jul 2010 18:48:02 -0600 Subject: need a code review for a quick test fix (6971847) Message-ID: <4C4A3842.4030103@oracle.com> Greetings, Porting my most recent batch of test fixes to OpenJDK6 revealed two new bugs: 6971847 4/4 jmap '-histo:live' option is necessary for proper leak detection 6971851 4/4 jmap prints an incorrect usage message when SA is not present 6971847 was partially introduced in the original bug that introduced these tests (6942989) and the remainder was introduced by the fix for 6964018 which fixed the tests on Linux. Yes, fixing the tests on Linux broke them for OpenJDK6 on Windows. 6971851 was introduced when then 'jmap -histo:live' option was added back in JDK6. I have a fix in hand for 6971847 and it gets the new AnonLoggerWeakRefLeak and LoggerWeakRefLeak tests working properly on OpenJDK6 on Windows. This should be (knock on wood) the last fix to these tests as the tests have now been checked out via JPRT on all the configs of interest. Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/6971847-webrev/0/ Thanks, in advance, for any reviews. Dan From Alan.Bateman at oracle.com Sat Jul 24 05:14:41 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 24 Jul 2010 13:14:41 +0100 Subject: need a code review for a quick test fix (6971847) In-Reply-To: <4C4A3842.4030103@oracle.com> References: <4C4A3842.4030103@oracle.com> Message-ID: <4C4AD931.2020708@oracle.com> Daniel D. Daugherty wrote: > Greetings, > > Porting my most recent batch of test fixes to OpenJDK6 revealed > two new bugs: > > 6971847 4/4 jmap '-histo:live' option is necessary for proper leak > detection > 6971851 4/4 jmap prints an incorrect usage message when SA is not > present > > 6971847 was partially introduced in the original bug that introduced > these tests (6942989) and the remainder was introduced by the fix > for 6964018 which fixed the tests on Linux. Yes, fixing the tests on > Linux broke them for OpenJDK6 on Windows. 6971851 was introduced when > then 'jmap -histo:live' option was added back in JDK6. > > I have a fix in hand for 6971847 and it gets the new > AnonLoggerWeakRefLeak > and LoggerWeakRefLeak tests working properly on OpenJDK6 on Windows. This > should be (knock on wood) the last fix to these tests as the tests have > now been checked out via JPRT on all the configs of interest. > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/6971847-webrev/0/ > > Thanks, in advance, for any reviews. > > Dan I assume you are running into this because the SA bits weren't shipped with jdk6. For the issue at hand, then the simplest solution may be just remove the check for -histo:live from the tests. It shouldn't be needed anyway because the live sub-option is there since jdk6. -Alan. From daniel.daugherty at oracle.com Sat Jul 24 09:57:33 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 24 Jul 2010 10:57:33 -0600 Subject: need a code review for a quick test fix (6971847) In-Reply-To: <4C4AD931.2020708@oracle.com> References: <4C4A3842.4030103@oracle.com> <4C4AD931.2020708@oracle.com> Message-ID: <4C4B1B7D.7010808@oracle.com> On 7/24/2010 6:14 AM, Alan Bateman wrote: > Daniel D. Daugherty wrote: >> Greetings, >> >> Porting my most recent batch of test fixes to OpenJDK6 revealed >> two new bugs: >> >> 6971847 4/4 jmap '-histo:live' option is necessary for proper leak >> detection >> 6971851 4/4 jmap prints an incorrect usage message when SA is not >> present >> >> 6971847 was partially introduced in the original bug that introduced >> these tests (6942989) and the remainder was introduced by the fix >> for 6964018 which fixed the tests on Linux. Yes, fixing the tests on >> Linux broke them for OpenJDK6 on Windows. 6971851 was introduced when >> then 'jmap -histo:live' option was added back in JDK6. >> >> I have a fix in hand for 6971847 and it gets the new >> AnonLoggerWeakRefLeak >> and LoggerWeakRefLeak tests working properly on OpenJDK6 on Windows. >> This >> should be (knock on wood) the last fix to these tests as the tests have >> now been checked out via JPRT on all the configs of interest. >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/6971847-webrev/0/ >> >> Thanks, in advance, for any reviews. >> >> Dan > I assume you are running into this because the SA bits weren't shipped > with jdk6. Yes and the fact that the jmap usage message is wrong (the other bug). > For the issue at hand, then the simplest solution may be just remove > the check for -histo:live from the tests. It shouldn't be needed > anyway because the live sub-option is there since jdk6. The 'histo:live' check gives me a helpful usage message rather than a vague one. I would prefer to keep the check. Would you be okay with the fix as is? Dan From Alan.Bateman at oracle.com Sat Jul 24 12:14:46 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 24 Jul 2010 20:14:46 +0100 Subject: need a code review for a quick test fix (6971847) In-Reply-To: <4C4B1B7D.7010808@oracle.com> References: <4C4A3842.4030103@oracle.com> <4C4AD931.2020708@oracle.com> <4C4B1B7D.7010808@oracle.com> Message-ID: <4C4B3BA6.7020307@oracle.com> Daniel D. Daugherty wrote: > : > The 'histo:live' check gives me a helpful usage message rather > than a vague one. I would prefer to keep the check. Would you > be okay with the fix as is? I don't have a strong objection to the proposed change but the check seems to be only useful to catch the case where someone is running these jdk6 or jdk7 tests on jdk5. It was useful that it caught the problem with the usage message but I think the simplest fix is to just remove lines 55 and 58-65 from both tests. -Alan. From daniel.daugherty at oracle.com Sat Jul 24 12:33:03 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 24 Jul 2010 13:33:03 -0600 Subject: need a code review for a quick test fix (6971847) In-Reply-To: <4C4B3BA6.7020307@oracle.com> References: <4C4A3842.4030103@oracle.com> <4C4AD931.2020708@oracle.com> <4C4B1B7D.7010808@oracle.com> <4C4B3BA6.7020307@oracle.com> Message-ID: <4C4B3FEF.2090204@oracle.com> On 7/24/2010 1:14 PM, Alan Bateman wrote: > Daniel D. Daugherty wrote: >> : >> The 'histo:live' check gives me a helpful usage message rather >> than a vague one. I would prefer to keep the check. Would you >> be okay with the fix as is? > I don't have a strong objection to the proposed change but the check > seems to be only useful to catch the case where someone is running > these jdk6 or jdk7 tests on jdk5. It was useful that it caught the > problem with the usage message but I think the simplest fix is to just > remove lines 55 and 58-65 from both tests. No argument about simpler. Yes, JDK5 is exactly what I'm worried about. Since the original bug (6942989) is escalated and the original problem goes all the way back to JDK1.4.0, I expect this fix to be backported to earlier releases. Rather than have a vague failure buried in the .jmap file, I would prefer a more clear message that says why the test isn't working. Dan From daniel.daugherty at oracle.com Sun Jul 25 00:06:30 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sun, 25 Jul 2010 01:06:30 -0600 Subject: need a code review for a quick test fix (6971847) In-Reply-To: <4C49C58A.8080404@oracle.com> References: <4C4A3842.4030103@oracle.com> <4C4AD931.2020708@oracle.com> <4C4B1B7D.7010808@oracle.com> <4C4B3BA6.7020307@oracle.com> <4C4B3FEF.2090204@oracle.com> <4C49C58A.8080404@oracle.com> Message-ID: <4C4BE276.9040102@oracle.com> On 7/23/2010 10:38 AM, Joe Darcy wrote: > Daniel D. Daugherty wrote: >> On 7/24/2010 1:14 PM, Alan Bateman wrote: >>> Daniel D. Daugherty wrote: >>>> : >>>> The 'histo:live' check gives me a helpful usage message rather >>>> than a vague one. I would prefer to keep the check. Would you >>>> be okay with the fix as is? >>> I don't have a strong objection to the proposed change but the check >>> seems to be only useful to catch the case where someone is running >>> these jdk6 or jdk7 tests on jdk5. It was useful that it caught the >>> problem with the usage message but I think the simplest fix is to >>> just remove lines 55 and 58-65 from both tests. >> >> No argument about simpler. >> >> Yes, JDK5 is exactly what I'm worried about. Since the original >> bug (6942989) is escalated and the original problem goes all the >> way back to JDK1.4.0, I expect this fix to be backported to >> earlier releases. Rather than have a vague failure buried in >> the .jmap file, I would prefer a more clear message that >> says why the test isn't working. >> > > If you'd like to keep the test code the same across releases, the > current fix is fine for OpenJDK 6. Otherwise, Alan's suggestion could > be followed. Yes, I would prefer that the test code be the same across releases. Thanks for approval for OpenJDK6. Dan From Alan.Bateman at oracle.com Sun Jul 25 03:48:24 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 25 Jul 2010 11:48:24 +0100 Subject: need a code review for a quick test fix (6971847) In-Reply-To: <4C4BE276.9040102@oracle.com> References: <4C4A3842.4030103@oracle.com> <4C4AD931.2020708@oracle.com> <4C4B1B7D.7010808@oracle.com> <4C4B3BA6.7020307@oracle.com> <4C4B3FEF.2090204@oracle.com> <4C49C58A.8080404@oracle.com> <4C4BE276.9040102@oracle.com> Message-ID: <4C4C1678.80108@oracle.com> Daniel D. Daugherty wrote: > : > Yes, I would prefer that the test code be the same across > releases. Thanks for approval for OpenJDK6. It makes sense to use the same test for jdk6 and jdk7 but it's not clear to me that these tests are useful for the older proprietary releases. For starters, we didn't have -histo:live so the test will fail. Also, I think Windows will bite you again because we didn't include jmap on Windows until jdk6. My guess is you'll need a completely different test. Anyway, as I said, I don't have any objection to the proposed test changes and I'm just pointing you that we shouldn't need any of this detection code in the tests checked into the jdk6 and jdk7 repos. -Alan. From daniel.daugherty at oracle.com Sun Jul 25 09:36:08 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sun, 25 Jul 2010 10:36:08 -0600 Subject: need a code review for a quick test fix (6971847) In-Reply-To: <4C4C1678.80108@oracle.com> References: <4C4A3842.4030103@oracle.com> <4C4AD931.2020708@oracle.com> <4C4B1B7D.7010808@oracle.com> <4C4B3BA6.7020307@oracle.com> <4C4B3FEF.2090204@oracle.com> <4C49C58A.8080404@oracle.com> <4C4BE276.9040102@oracle.com> <4C4C1678.80108@oracle.com> Message-ID: <4C4C67F8.5070902@oracle.com> On 7/25/2010 4:48 AM, Alan Bateman wrote: > Daniel D. Daugherty wrote: >> : >> Yes, I would prefer that the test code be the same across >> releases. Thanks for approval for OpenJDK6. > It makes sense to use the same test for jdk6 and jdk7 but it's not > clear to me that these tests are useful for the older proprietary > releases. For starters, we didn't have -histo:live so the test will > fail. Also, I think Windows will bite you again because we didn't > include jmap on Windows until jdk6. My guess is you'll need a > completely different test. Anyway, as I said, I don't have any > objection to the proposed test changes and I'm just pointing you that > we shouldn't need any of this detection code in the tests checked into > the jdk6 and jdk7 repos. Thanks Alan! Dan From andrei.pangin at sun.com Sun Jul 25 11:21:20 2010 From: andrei.pangin at sun.com (andrei.pangin at sun.com) Date: Sun, 25 Jul 2010 18:21:20 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 39 new changesets Message-ID: <20100725182226.BCF4547C6C@hg.openjdk.java.net> Changeset: f56e28f22410 Author: trims Date: 2010-06-03 18:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f56e28f22410 6958458: Bump the HS19 build number to 03 Summary: Update the HS19 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 49242b3df6cd Author: mikejwre Date: 2010-06-03 13:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/49242b3df6cd Added tag jdk7-b96 for changeset 573e8ea5fd68 ! .hgtags Changeset: 5f42499e57ad Author: trims Date: 2010-06-04 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5f42499e57ad Added tag hs19-b02 for changeset 573e8ea5fd68 ! .hgtags Changeset: b0e7cd862748 Author: mikejwre Date: 2010-06-10 13:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b0e7cd862748 Added tag jdk7-b97 for changeset 5f42499e57ad ! .hgtags Changeset: 70191885f707 Author: prr Date: 2010-06-16 09:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/70191885f707 6961079: Build JDK7 for 64 bit Windows using free Windows 7.1 SDK 64 bit compilers Reviewed-by: ohair, jcoomes ! make/windows/makefiles/defs.make Changeset: 8a045b3f5c13 Author: mikejwre Date: 2010-06-16 15:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8a045b3f5c13 Merge Changeset: 695c43156a9a Author: mikejwre Date: 2010-06-17 16:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/695c43156a9a Added tag jdk7-b98 for changeset 8a045b3f5c13 ! .hgtags Changeset: c69846936352 Author: trims Date: 2010-06-17 23:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c69846936352 Merge Changeset: e848dd13e1b6 Author: trims Date: 2010-06-18 00:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e848dd13e1b6 Merge Changeset: 606df121c181 Author: trims Date: 2010-06-04 11:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/606df121c181 Merge Changeset: 6a236384a379 Author: trims Date: 2010-06-18 00:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6a236384a379 Merge Changeset: b34c75c0b6b8 Author: mikejwre Date: 2010-06-24 20:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b34c75c0b6b8 Added tag jdk7-b99 for changeset 6a236384a379 ! .hgtags Changeset: e13a5c0ed5e2 Author: prr Date: 2010-06-29 16:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e13a5c0ed5e2 6964882: 32 bit JDK does not build on 64 bit Windows platforms Reviewed-by: ohair, valeriep ! make/windows/makefiles/defs.make Changeset: ad1977f08c4d Author: mikejwre Date: 2010-06-30 18:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ad1977f08c4d Merge Changeset: 871d2aa321f7 Author: trims Date: 2010-07-02 01:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/871d2aa321f7 Merge Changeset: 7cc68a696c62 Author: trims Date: 2010-07-02 01:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7cc68a696c62 6966252: Bump the HS19 build number to 04 Summary: Update the HS19 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 56cc7e01da2f Author: trims Date: 2010-07-09 00:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/56cc7e01da2f Added tag hs19-b03 for changeset ad1977f08c4d ! .hgtags Changeset: 1dbaff4aa23a Author: trims Date: 2010-07-09 00:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1dbaff4aa23a Merge Changeset: cf647374e044 Author: trims Date: 2010-07-09 00:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/cf647374e044 Merge Changeset: 6c3a919105b6 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6c3a919105b6 Added tag jdk7-b100 for changeset ad1977f08c4d ! .hgtags Changeset: a2b581345549 Author: trims Date: 2010-07-15 19:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a2b581345549 Merge ! .hgtags Changeset: e55900b5c1b8 Author: trims Date: 2010-07-15 19:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e55900b5c1b8 Merge - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp - src/share/vm/runtime/vtune.hpp Changeset: 75b254ea860e Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/75b254ea860e Added tag jdk7-b101 for changeset 6c3a919105b6 ! .hgtags Changeset: c5cadf1a0771 Author: trims Date: 2010-07-20 18:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c5cadf1a0771 Merge ! .hgtags Changeset: e7ec8cd4dd8a Author: tonyp Date: 2010-06-28 14:13 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e7ec8cd4dd8a 6962569: assembler_sparc.cpp:1969: assert(false) failed: error Summary: array_overlap_test() fails when the address range crosses the MSB boundary. Thanks to Tom and Vladimir for their help on this one. Reviewed-by: kvn, never, iveresov ! src/cpu/sparc/vm/stubGenerator_sparc.cpp Changeset: 4e5661ba9d98 Author: tonyp Date: 2010-06-28 14:13 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4e5661ba9d98 6944166: G1: explicit GCs are not always handled correctly Summary: G1 was not handling explicit GCs correctly in many ways. It does now. See the CR for the list of improvements contained in this changeset. Reviewed-by: iveresov, ysr, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/runtime/mutexLocker.cpp Changeset: 1a1ce2076047 Author: ysr Date: 2010-07-16 10:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1a1ce2076047 Merge Changeset: ad7e433e2730 Author: ysr Date: 2010-07-20 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ad7e433e2730 Merge - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp - src/share/vm/runtime/vtune.hpp Changeset: 131ed9a23d48 Author: ysr Date: 2010-07-21 09:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/131ed9a23d48 Merge Changeset: 083fde3b838e Author: jrose Date: 2010-07-15 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/083fde3b838e 6964498: JSR 292 invokedynamic sites need local bootstrap methods Summary: Add JVM_CONSTANT_InvokeDynamic records to constant pool to determine per-instruction BSMs. Reviewed-by: twisti ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 01b172b8cd7c Author: never Date: 2010-07-16 08:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/01b172b8cd7c Merge Changeset: e0ba4e04c839 Author: jrose Date: 2010-07-16 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e0ba4e04c839 6969574: invokedynamic call sites deoptimize instead of executing Reviewed-by: kvn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 7139e81efd2d Author: never Date: 2010-07-22 15:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7139e81efd2d 6970566: runThese fails with SIGSEGV Reviewed-by: kvn ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp Changeset: 5063ce716349 Author: never Date: 2010-07-23 10:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5063ce716349 Merge Changeset: a93a9eda13f7 Author: jcoomes Date: 2010-07-16 21:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a93a9eda13f7 6962947: shared TaskQueue statistics Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 5cbac8938c4c Author: johnc Date: 2010-07-19 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5cbac8938c4c 6956639: G1: assert(cached_ptr != card_ptr) failed: shouldn't be, concurrentG1Refine.cpp:307 Summary: During concurrent refinment, filter cards in young regions after it has been determined that the region has been allocated from and the young type of the region has been set. Reviewed-by: iveresov, tonyp, jcoomes ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 4f1fffe08c63 Author: ysr Date: 2010-07-21 12:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4f1fffe08c63 Merge Changeset: 1890dc9151da Author: ysr Date: 2010-07-23 14:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1890dc9151da Merge Changeset: 7f0fdccac34f Author: apangin Date: 2010-07-25 07:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7f0fdccac34f Merge ! src/share/vm/classfile/verifier.cpp From joe.darcy at oracle.com Fri Jul 23 09:38:34 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 23 Jul 2010 09:38:34 -0700 Subject: need a code review for a quick test fix (6971847) In-Reply-To: <4C4B3FEF.2090204@oracle.com> References: <4C4A3842.4030103@oracle.com> <4C4AD931.2020708@oracle.com> <4C4B1B7D.7010808@oracle.com> <4C4B3BA6.7020307@oracle.com> <4C4B3FEF.2090204@oracle.com> Message-ID: <4C49C58A.8080404@oracle.com> Daniel D. Daugherty wrote: > On 7/24/2010 1:14 PM, Alan Bateman wrote: >> Daniel D. Daugherty wrote: >>> : >>> The 'histo:live' check gives me a helpful usage message rather >>> than a vague one. I would prefer to keep the check. Would you >>> be okay with the fix as is? >> I don't have a strong objection to the proposed change but the check >> seems to be only useful to catch the case where someone is running >> these jdk6 or jdk7 tests on jdk5. It was useful that it caught the >> problem with the usage message but I think the simplest fix is to >> just remove lines 55 and 58-65 from both tests. > > No argument about simpler. > > Yes, JDK5 is exactly what I'm worried about. Since the original > bug (6942989) is escalated and the original problem goes all the > way back to JDK1.4.0, I expect this fix to be backported to > earlier releases. Rather than have a vague failure buried in > the .jmap file, I would prefer a more clear message that > says why the test isn't working. > If you'd like to keep the test code the same across releases, the current fix is fine for OpenJDK 6. Otherwise, Alan's suggestion could be followed. -Joe From aph at redhat.com Wed Jul 28 09:40:02 2010 From: aph at redhat.com (aph at redhat.com) Date: Wed, 28 Jul 2010 16:40:02 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6888526: Linux getCurrentThreadCpuTime is drastically slower than Windows Message-ID: <20100728164004.5FD2947D09@hg.openjdk.java.net> Changeset: 3d90023429ec Author: aph Date: 2010-07-28 17:38 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3d90023429ec 6888526: Linux getCurrentThreadCpuTime is drastically slower than Windows Reviewed-by: dcubed, dholmes ! src/os/linux/vm/globals_linux.hpp ! src/share/vm/runtime/arguments.cpp From coleen.phillimore at oracle.com Wed Jul 28 13:40:48 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 28 Jul 2010 16:40:48 -0400 Subject: Please review 6958465: Sparc aten build24.0: openjdk-7.ea-b96 failed Error: Formal argument ... requires an lvalue Message-ID: <4C5095D0.2020802@oracle.com> Summary: Fix compilation errors. Made non-const references const so can be assigned with lvalue. open webrev at http://cr.openjdk.java.net/~coleenp/6958465/ bug link at http://bugs.sun.com/view_bug.do?bug_id=6958465 Thanks, Coleen From john.r.rose at oracle.com Wed Jul 28 15:24:15 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 28 Jul 2010 15:24:15 -0700 Subject: Please review 6958465: Sparc aten build24.0: openjdk-7.ea-b96 failed Error: Formal argument ... requires an lvalue In-Reply-To: <4C5095D0.2020802@oracle.com> References: <4C5095D0.2020802@oracle.com> Message-ID: <345196D5-9009-40D5-9D42-BCB3D55386DB@oracle.com> Thanks, Coleen. Reviewed. -- John On Jul 28, 2010, at 1:40 PM, Coleen Phillimore wrote: > Summary: Fix compilation errors. Made non-const references const so can be assigned with lvalue. > > open webrev at http://cr.openjdk.java.net/~coleenp/6958465/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6958465 > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Jul 28 17:57:00 2010 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 29 Jul 2010 00:57:00 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6958465: Sparc aten build24.0: openjdk-7.ea-b96 failed Error: Formal argument ... requires an lvalue Message-ID: <20100729005703.DC90F47D1F@hg.openjdk.java.net> Changeset: a64438a2b7e8 Author: coleenp Date: 2010-07-28 17:57 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a64438a2b7e8 6958465: Sparc aten build24.0: openjdk-7.ea-b96 failed Error: Formal argument ... requires an lvalue Summary: Fix compilation errors. Made non-const references const so can be assigned with lvalue. Reviewed-by: phh, xlu ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp From guanxiaohua at gmail.com Thu Jul 29 14:29:11 2010 From: guanxiaohua at gmail.com (Tony Guan) Date: Thu, 29 Jul 2010 16:29:11 -0500 Subject: how to bring jvm to safepoint Message-ID: Dear all, I want to invoke the GC at a certain time, for example, when a certain method is called at runtime, so I created a new subtype of VM_GC_Operation class, and initialized it with an object op, finally, executed using:VMThread::execute(&op) then I got the following error message: # Internal Error (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), pid=29652, tid=1096460624 # Error: Possible safepoint reached by thread that does not allow it The reason for the fail is that Thread::check_for_valid_safepoint_state() didn't pass because the currentThread is not a VMThread. My question is: how do I bring the current thread to a safepoint? or how do I call a GC operation properly? is there any prerequisite for doing so? Thanks! Tony (Xiaohua Guan) From John.Coomes at oracle.com Thu Jul 29 16:38:49 2010 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 29 Jul 2010 16:38:49 -0700 Subject: hg: jdk7/hotspot-rt/hotspot: 6888526: Linux getCurrentThreadCpuTime is drastically slower than Windows In-Reply-To: <20100728164004.5FD2947D09@hg.openjdk.java.net> References: <20100728164004.5FD2947D09@hg.openjdk.java.net> Message-ID: <19538.4361.332053.908362@oracle.com> aph at redhat.com (aph at redhat.com) wrote: > Changeset: 3d90023429ec > Author: aph > Date: 2010-07-28 17:38 +0100 > URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3d90023429ec > > 6888526: Linux getCurrentThreadCpuTime is drastically slower than Windows > Reviewed-by: dcubed, dholmes > > ! src/os/linux/vm/globals_linux.hpp > ! src/share/vm/runtime/arguments.cpp Hi Andrew, First, thanks for the fix. I also want to make sure you're aware of our requirements for pushing to hotspot, since this looks like something you pushed directly. All hotspot changes (even trivial ones) have to go through an automated build and test system that we call JPRT, which pushes your change only if all builds and test pass on all platforms. As of now that system is only available internally, so in the future when you have a hotspot change ready, ask on the appropriate hotspot-*-dev list and someone will submit the changeset for you. It's worth noting that all hotspot pushes from oracle engineers go through JPRT. I realize it's a slight inconvenience, but we had much too frequent build and test breakage before we required everyone to use JPRT. -John From daniel.daugherty at oracle.com Thu Jul 29 17:28:46 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 29 Jul 2010 18:28:46 -0600 Subject: hg: jdk7/hotspot-rt/hotspot: 6888526: Linux getCurrentThreadCpuTime is drastically slower than Windows In-Reply-To: <19538.4361.332053.908362@oracle.com> References: <20100728164004.5FD2947D09@hg.openjdk.java.net> <19538.4361.332053.908362@oracle.com> Message-ID: <4C521CBE.4050601@oracle.com> On 7/29/2010 5:38 PM, John Coomes wrote: > aph at redhat.com (aph at redhat.com) wrote: > >> Changeset: 3d90023429ec >> Author: aph >> Date: 2010-07-28 17:38 +0100 >> URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3d90023429ec >> >> 6888526: Linux getCurrentThreadCpuTime is drastically slower than Windows >> Reviewed-by: dcubed, dholmes >> >> ! src/os/linux/vm/globals_linux.hpp >> ! src/share/vm/runtime/arguments.cpp >> > > Hi Andrew, > > First, thanks for the fix. > > I also want to make sure you're aware of our requirements for pushing > to hotspot, since this looks like something you pushed directly. All > hotspot changes (even trivial ones) have to go through an automated > build and test system that we call JPRT, which pushes your change only > if all builds and test pass on all platforms. As of now that system > is only available internally, so in the future when you have a hotspot > change ready, ask on the appropriate hotspot-*-dev list and someone > will submit the changeset for you. It's worth noting that all hotspot > pushes from oracle engineers go through JPRT. > > I realize it's a slight inconvenience, but we had much too frequent > build and test breakage before we required everyone to use JPRT. > > -John > That's my fault. I gave Andrew permission to push the change to RT_Baseline. I guess I've spent too much time in T&L lately where external pushes happen without going thru JPRT. In any case, Coleen pushed a subsequent job through JPRT after Andrew's and I've thoroughly checked the nightly test results. In the future, I'll shepherd changes through JPRT (as I did for the stuff that AMD contributed)... Dan From David.Holmes at oracle.com Thu Jul 29 18:07:09 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 30 Jul 2010 11:07:09 +1000 Subject: how to bring jvm to safepoint In-Reply-To: References: Message-ID: <4C5225BD.4020909@oracle.com> Tony, I don't see anything obviously wrong with what you attempted. Can you show the full stack dump from the error. David Holmes Tony Guan said the following on 07/30/10 07:29: > Dear all, > > I want to invoke the GC at a certain time, for example, when a certain > method is called at runtime, so I created a new subtype of > VM_GC_Operation class, and initialized it with an object op, finally, > executed using:VMThread::execute(&op) > > then I got the following error message: > > # Internal Error > (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), > pid=29652, tid=1096460624 > # Error: Possible safepoint reached by thread that does not allow it > > The reason for the fail is that > Thread::check_for_valid_safepoint_state() didn't pass because the > currentThread is not a VMThread. > > My question is: how do I bring the current thread to a safepoint? or > how do I call a GC operation properly? is there any prerequisite for > doing so? > > Thanks! > > Tony (Xiaohua Guan) From John.Coomes at oracle.com Thu Jul 29 22:11:39 2010 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 29 Jul 2010 22:11:39 -0700 Subject: hg: jdk7/hotspot-rt/hotspot: 6888526: Linux getCurrentThreadCpuTime is drastically slower than Windows In-Reply-To: <4C521CBE.4050601@oracle.com> References: <20100728164004.5FD2947D09@hg.openjdk.java.net> <19538.4361.332053.908362@oracle.com> <4C521CBE.4050601@oracle.com> Message-ID: <19538.24331.131605.628012@oracle.com> Daniel D. Daugherty (daniel.daugherty at oracle.com) wrote: > > > On 7/29/2010 5:38 PM, John Coomes wrote: > > aph at redhat.com (aph at redhat.com) wrote: > > > >> Changeset: 3d90023429ec > >> Author: aph > >> Date: 2010-07-28 17:38 +0100 > >> URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3d90023429ec > >> > >> 6888526: Linux getCurrentThreadCpuTime is drastically slower than Windows > >> Reviewed-by: dcubed, dholmes > >> > >> ! src/os/linux/vm/globals_linux.hpp > >> ! src/share/vm/runtime/arguments.cpp > > > > Hi Andrew, > > > > First, thanks for the fix. > > > > I also want to make sure you're aware of our requirements for pushing > > to hotspot, since this looks like something you pushed directly. All > > hotspot changes (even trivial ones) have to go through an automated > > build and test system that we call JPRT, which pushes your change only > > if all builds and test pass on all platforms. As of now that system > > is only available internally, so in the future when you have a hotspot > > change ready, ask on the appropriate hotspot-*-dev list and someone > > will submit the changeset for you. It's worth noting that all hotspot > > pushes from oracle engineers go through JPRT. > > > > I realize it's a slight inconvenience, but we had much too frequent > > build and test breakage before we required everyone to use JPRT. > > That's my fault. I gave Andrew permission to push the change to > RT_Baseline. I guess I've spent too much time in T&L lately where > external pushes happen without going thru JPRT. In any case, > Coleen pushed a subsequent job through JPRT after Andrew's and > I've thoroughly checked the nightly test results. > > In the future, I'll shepherd changes through JPRT (as I did for > the stuff that AMD contributed)... Sounds good. And thanks for checking the nightlies; good to know that all's well. -John From guanxiaohua at gmail.com Thu Jul 29 22:58:52 2010 From: guanxiaohua at gmail.com (Tony Guan) Date: Fri, 30 Jul 2010 00:58:52 -0500 Subject: how to bring jvm to safepoint In-Reply-To: <4C5225BD.4020909@oracle.com> References: <4C5225BD.4020909@oracle.com> Message-ID: Hi David, Thanks a lot! I am copying the content to below, and for convenience, the full log file is attached. cat hs_err_pid30894.log # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), pid=30894, tid=1082374480 # Error: Possible safepoint reached by thread that does not allow it # # JRE version: 7.0 # Java VM: OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug mixed mode linux-amd64 ) # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00000000012ed000): JavaThread "RMI TCP Connection(idle)" daemon [_thread_in_Java, id=30929, stack(0x000000004073b000,0x000000004083c000)] Stack: [0x000000004073b000,0x000000004083c000], sp=0x0000000040839d60, free space=3fb0000000000000000k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x8cad18] V [libjvm.so+0x8cbe38] V [libjvm.so+0x4039f1] V [libjvm.so+0x87a183] V [libjvm.so+0x8e1127] V [libjvm.so+0x4d52ab] V [libjvm.so+0x7ee63d] j sun.misc.Unsafe.park(ZJ)V+0 j java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 j java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 j java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 j java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 j java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 j java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub V [libjvm.so+0x555ecc] V [libjvm.so+0x747a34] V [libjvm.so+0x554b55] V [libjvm.so+0x5551f0] V [libjvm.so+0x5553cc] V [libjvm.so+0x5be6cd] V [libjvm.so+0x879869] V [libjvm.so+0x87c1b5] V [libjvm.so+0x750455] .... (above is the stack, please see the attachment for more information) Tony (Xiaohua Guan) On Thu, Jul 29, 2010 at 8:07 PM, David Holmes wrote: > Tony, > > I don't see anything obviously wrong with what you attempted. Can you show > the full stack dump from the error. > > David Holmes > > Tony Guan said the following on 07/30/10 07:29: >> >> Dear all, >> >> I want to invoke the GC at a certain time, for example, when a certain >> method is called at runtime, so I created a new subtype of >> VM_GC_Operation class, and initialized it with an object op, finally, >> executed using:VMThread::execute(&op) >> >> then I got the following error message: >> >> # ?Internal Error >> >> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >> pid=29652, tid=1096460624 >> # ?Error: Possible safepoint reached by thread that does not allow it >> >> The reason for the fail is that >> Thread::check_for_valid_safepoint_state() didn't pass because the >> currentThread is not a VMThread. >> >> My question is: how do I bring the current thread to a safepoint? or >> how do I call a GC operation properly? is there any prerequisite for >> doing so? >> >> Thanks! >> >> Tony (Xiaohua Guan) > -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid30894.log Type: application/octet-stream Size: 17808 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100730/56944ecd/attachment-0001.obj From David.Holmes at oracle.com Fri Jul 30 00:04:27 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 30 Jul 2010 17:04:27 +1000 Subject: how to bring jvm to safepoint In-Reply-To: References: <4C5225BD.4020909@oracle.com> Message-ID: <4C52797B.1080303@oracle.com> Sorry Tony I keep forgetting that I don't have a way to decode a crash log from a VM that you built yourself. :( However you may be able to decode it yourself please see: http://blogs.sun.com/dave/entry/a_tool_to_decode_hs for a perl script. That said looking at the actual assertion failure I am guessing that you initiated the VM operation from code where a No_Safepoint_verifier is active. David Tony Guan said the following on 07/30/10 15:58: > Hi David, > > Thanks a lot! > > I am copying the content to below, and for convenience, the full log > file is attached. > > cat hs_err_pid30894.log > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), > pid=30894, tid=1082374480 > # Error: Possible safepoint reached by thread that does not allow it > # > # JRE version: 7.0 > # Java VM: OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug > mixed mode linux-amd64 ) > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00000000012ed000): JavaThread "RMI TCP > Connection(idle)" daemon [_thread_in_Java, id=30929, > stack(0x000000004073b000,0x000000004083c000)] > > Stack: [0x000000004073b000,0x000000004083c000], > sp=0x0000000040839d60, free space=3fb0000000000000000k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x8cad18] > V [libjvm.so+0x8cbe38] > V [libjvm.so+0x4039f1] > V [libjvm.so+0x87a183] > V [libjvm.so+0x8e1127] > V [libjvm.so+0x4d52ab] > V [libjvm.so+0x7ee63d] > j sun.misc.Unsafe.park(ZJ)V+0 > j java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 > j java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 > j java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 > j java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 > j java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 > j java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 > j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 > j java.lang.Thread.run()V+11 > v ~StubRoutines::call_stub > V [libjvm.so+0x555ecc] > V [libjvm.so+0x747a34] > V [libjvm.so+0x554b55] > V [libjvm.so+0x5551f0] > V [libjvm.so+0x5553cc] > V [libjvm.so+0x5be6cd] > V [libjvm.so+0x879869] > V [libjvm.so+0x87c1b5] > V [libjvm.so+0x750455] > .... > (above is the stack, please see the attachment for more information) > > Tony (Xiaohua Guan) > > > > On Thu, Jul 29, 2010 at 8:07 PM, David Holmes wrote: >> Tony, >> >> I don't see anything obviously wrong with what you attempted. Can you show >> the full stack dump from the error. >> >> David Holmes >> >> Tony Guan said the following on 07/30/10 07:29: >>> Dear all, >>> >>> I want to invoke the GC at a certain time, for example, when a certain >>> method is called at runtime, so I created a new subtype of >>> VM_GC_Operation class, and initialized it with an object op, finally, >>> executed using:VMThread::execute(&op) >>> >>> then I got the following error message: >>> >>> # Internal Error >>> >>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>> pid=29652, tid=1096460624 >>> # Error: Possible safepoint reached by thread that does not allow it >>> >>> The reason for the fail is that >>> Thread::check_for_valid_safepoint_state() didn't pass because the >>> currentThread is not a VMThread. >>> >>> My question is: how do I bring the current thread to a safepoint? or >>> how do I call a GC operation properly? is there any prerequisite for >>> doing so? >>> >>> Thanks! >>> >>> Tony (Xiaohua Guan) >> From guanxiaohua at gmail.com Fri Jul 30 03:52:56 2010 From: guanxiaohua at gmail.com (Tony Guan) Date: Fri, 30 Jul 2010 05:52:56 -0500 Subject: how to bring jvm to safepoint In-Reply-To: <4C52797B.1080303@oracle.com> References: <4C5225BD.4020909@oracle.com> <4C52797B.1080303@oracle.com> Message-ID: Hi David, Thanks for the tool, I will try it definitely. If "initiating the VM operation from code where a No_Safepoint_verifier is active", can we do something to make it right? Is there a way that we can just delay the execution of the VM operation until it's safe to do so? Thanks again! Tony (Xiaohua Guan) On Fri, Jul 30, 2010 at 2:04 AM, David Holmes wrote: > Sorry Tony I keep forgetting that I don't have a way to decode a crash log > from a VM that you built yourself. :( However you may be able to decode it > yourself please see: > > http://blogs.sun.com/dave/entry/a_tool_to_decode_hs > > for a perl script. > > That said looking at the actual assertion failure I am guessing that you > initiated the VM operation from code where a No_Safepoint_verifier is > active. > > David > > Tony Guan said the following on 07/30/10 15:58: >> >> Hi David, >> >> Thanks a lot! >> >> I am copying the content to below, and for convenience, the full log >> file is attached. >> >> cat hs_err_pid30894.log >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # ?Internal Error >> >> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >> pid=30894, tid=1082374480 >> # ?Error: Possible safepoint reached by thread that does not allow it >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug >> mixed mode linux-amd64 ) >> # If you would like to submit a bug report, please visit: >> # ? http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> --------------- ?T H R E A D ?--------------- >> >> Current thread (0x00000000012ed000): ?JavaThread "RMI TCP >> Connection(idle)" daemon [_thread_in_Java, id=30929, >> stack(0x000000004073b000,0x000000004083c000)] >> >> Stack: [0x000000004073b000,0x000000004083c000], >> sp=0x0000000040839d60, ?free space=3fb0000000000000000k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> V ?[libjvm.so+0x8cad18] >> V ?[libjvm.so+0x8cbe38] >> V ?[libjvm.so+0x4039f1] >> V ?[libjvm.so+0x87a183] >> V ?[libjvm.so+0x8e1127] >> V ?[libjvm.so+0x4d52ab] >> V ?[libjvm.so+0x7ee63d] >> j ?sun.misc.Unsafe.park(ZJ)V+0 >> j >> ?java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >> j >> ?java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >> j >> ?java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >> j >> ?java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >> j >> ?java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >> j >> ?java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >> j ?java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 >> j ?java.lang.Thread.run()V+11 >> v ?~StubRoutines::call_stub >> V ?[libjvm.so+0x555ecc] >> V ?[libjvm.so+0x747a34] >> V ?[libjvm.so+0x554b55] >> V ?[libjvm.so+0x5551f0] >> V ?[libjvm.so+0x5553cc] >> V ?[libjvm.so+0x5be6cd] >> V ?[libjvm.so+0x879869] >> V ?[libjvm.so+0x87c1b5] >> V ?[libjvm.so+0x750455] >> .... >> (above is the stack, please see the attachment for more information) >> >> Tony (Xiaohua Guan) >> >> >> >> On Thu, Jul 29, 2010 at 8:07 PM, David Holmes >> wrote: >>> >>> Tony, >>> >>> I don't see anything obviously wrong with what you attempted. Can you >>> show >>> the full stack dump from the error. >>> >>> David Holmes >>> >>> Tony Guan said the following on 07/30/10 07:29: >>>> >>>> Dear all, >>>> >>>> I want to invoke the GC at a certain time, for example, when a certain >>>> method is called at runtime, so I created a new subtype of >>>> VM_GC_Operation class, and initialized it with an object op, finally, >>>> executed using:VMThread::execute(&op) >>>> >>>> then I got the following error message: >>>> >>>> # ?Internal Error >>>> >>>> >>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>> pid=29652, tid=1096460624 >>>> # ?Error: Possible safepoint reached by thread that does not allow it >>>> >>>> The reason for the fail is that >>>> Thread::check_for_valid_safepoint_state() didn't pass because the >>>> currentThread is not a VMThread. >>>> >>>> My question is: how do I bring the current thread to a safepoint? or >>>> how do I call a GC operation properly? is there any prerequisite for >>>> doing so? >>>> >>>> Thanks! >>>> >>>> Tony (Xiaohua Guan) >>> > From tom.rodriguez at oracle.com Fri Jul 30 12:01:34 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 30 Jul 2010 12:01:34 -0700 Subject: how to bring jvm to safepoint In-Reply-To: <4C52797B.1080303@oracle.com> References: <4C5225BD.4020909@oracle.com> <4C52797B.1080303@oracle.com> Message-ID: <8E940C36-8120-496D-8425-36E3314F90D8@oracle.com> Actually I think the problem is that the thread is in thread_in_Java state. I don't believe you can safepoint from that state, only thread_in_vm. tom On Jul 30, 2010, at 12:04 AM, David Holmes wrote: > Sorry Tony I keep forgetting that I don't have a way to decode a crash log from a VM that you built yourself. :( However you may be able to decode it yourself please see: > > http://blogs.sun.com/dave/entry/a_tool_to_decode_hs > > for a perl script. > > That said looking at the actual assertion failure I am guessing that you initiated the VM operation from code where a No_Safepoint_verifier is active. > > David > > Tony Guan said the following on 07/30/10 15:58: >> Hi David, >> Thanks a lot! >> I am copying the content to below, and for convenience, the full log >> file is attached. >> cat hs_err_pid30894.log >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error >> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >> pid=30894, tid=1082374480 >> # Error: Possible safepoint reached by thread that does not allow it >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug >> mixed mode linux-amd64 ) >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> --------------- T H R E A D --------------- >> Current thread (0x00000000012ed000): JavaThread "RMI TCP >> Connection(idle)" daemon [_thread_in_Java, id=30929, >> stack(0x000000004073b000,0x000000004083c000)] >> Stack: [0x000000004073b000,0x000000004083c000], >> sp=0x0000000040839d60, free space=3fb0000000000000000k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x8cad18] >> V [libjvm.so+0x8cbe38] >> V [libjvm.so+0x4039f1] >> V [libjvm.so+0x87a183] >> V [libjvm.so+0x8e1127] >> V [libjvm.so+0x4d52ab] >> V [libjvm.so+0x7ee63d] >> j sun.misc.Unsafe.park(ZJ)V+0 >> j java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >> j java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >> j java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >> j java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >> j java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >> j java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >> j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 >> j java.lang.Thread.run()V+11 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x555ecc] >> V [libjvm.so+0x747a34] >> V [libjvm.so+0x554b55] >> V [libjvm.so+0x5551f0] >> V [libjvm.so+0x5553cc] >> V [libjvm.so+0x5be6cd] >> V [libjvm.so+0x879869] >> V [libjvm.so+0x87c1b5] >> V [libjvm.so+0x750455] >> .... >> (above is the stack, please see the attachment for more information) >> Tony (Xiaohua Guan) >> On Thu, Jul 29, 2010 at 8:07 PM, David Holmes wrote: >>> Tony, >>> >>> I don't see anything obviously wrong with what you attempted. Can you show >>> the full stack dump from the error. >>> >>> David Holmes >>> >>> Tony Guan said the following on 07/30/10 07:29: >>>> Dear all, >>>> >>>> I want to invoke the GC at a certain time, for example, when a certain >>>> method is called at runtime, so I created a new subtype of >>>> VM_GC_Operation class, and initialized it with an object op, finally, >>>> executed using:VMThread::execute(&op) >>>> >>>> then I got the following error message: >>>> >>>> # Internal Error >>>> >>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>> pid=29652, tid=1096460624 >>>> # Error: Possible safepoint reached by thread that does not allow it >>>> >>>> The reason for the fail is that >>>> Thread::check_for_valid_safepoint_state() didn't pass because the >>>> currentThread is not a VMThread. >>>> >>>> My question is: how do I bring the current thread to a safepoint? or >>>> how do I call a GC operation properly? is there any prerequisite for >>>> doing so? >>>> >>>> Thanks! >>>> >>>> Tony (Xiaohua Guan) >>> From David.Holmes at oracle.com Fri Jul 30 22:56:46 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 31 Jul 2010 15:56:46 +1000 Subject: how to bring jvm to safepoint In-Reply-To: <8E940C36-8120-496D-8425-36E3314F90D8@oracle.com> References: <4C5225BD.4020909@oracle.com> <4C52797B.1080303@oracle.com> <8E940C36-8120-496D-8425-36E3314F90D8@oracle.com> Message-ID: <4C53BB1E.9070401@oracle.com> Tom Rodriguez said the following on 07/31/10 05:01: > Actually I think the problem is that the thread is in thread_in_Java > state. I don't believe you can safepoint from that state, only > thread_in_vm. The reported failure: # Error: Possible safepoint reached by thread that does not allow it is here: void Thread::check_for_valid_safepoint_state(bool potential_vm_operation) { // Check if current thread is allowed to block at a safepoint if (!(_allow_safepoint_count == 0)) fatal("Possible safepoint reached by thread that does not allow it"); as far as I can see the only code that touches _allow_safepoint_count are the No_Safepoint_Verifier classes. Also the stack shows: V [libjvm.so+0x7ee63d] j sun.misc.Unsafe.park(ZJ)V+0 and so we should have transitioned to _thread_in_vm here. That said, Tony also stated: > The reason for the fail is that > Thread::check_for_valid_safepoint_state() didn't pass because > the currentThread is not a VMThread. But that is not supported by the error produced. Tony: why did you make the above comment? Either way we need to see a decoded stack to get an idea of what is going wrong. Cheers, David > > tom > > On Jul 30, 2010, at 12:04 AM, David Holmes > wrote: > >> Sorry Tony I keep forgetting that I don't have a way to decode a >> crash log from a VM that you built yourself. :( However you may be >> able to decode it yourself please see: >> >> http://blogs.sun.com/dave/entry/a_tool_to_decode_hs >> >> for a perl script. >> >> That said looking at the actual assertion failure I am guessing >> that you initiated the VM operation from code where a >> No_Safepoint_verifier is active. >> >> David >> >> Tony Guan said the following on 07/30/10 15:58: >>> Hi David, Thanks a lot! I am copying the content to below, and >>> for convenience, the full log file is attached. cat >>> hs_err_pid30894.log # # A fatal error has been detected by the >>> Java Runtime Environment: # # Internal Error >>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>> pid=30894, tid=1082374480 # Error: Possible safepoint reached >>> by thread that does not allow it # # JRE version: 7.0 # Java VM: >>> OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug mixed >>> mode linux-amd64 ) # If you would like to submit a bug report, >>> please visit: # http://java.sun.com/webapps/bugreport/crash.jsp >>> # --------------- T H R E A D --------------- Current thread >>> (0x00000000012ed000): JavaThread "RMI TCP Connection(idle)" >>> daemon [_thread_in_Java, id=30929, >>> stack(0x000000004073b000,0x000000004083c000)] Stack: >>> [0x000000004073b000,0x000000004083c000], sp=0x0000000040839d60, >>> free space=3fb0000000000000000k Native frames: (J=compiled Java >>> code, j=interpreted, Vv=VM code, C=native code) V >>> [libjvm.so+0x8cad18] V [libjvm.so+0x8cbe38] V >>> [libjvm.so+0x4039f1] V [libjvm.so+0x87a183] V >>> [libjvm.so+0x8e1127] V [libjvm.so+0x4d52ab] V >>> [libjvm.so+0x7ee63d] j sun.misc.Unsafe.park(ZJ)V+0 j >>> java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >>> j >>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >>> j >>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >>> j >>> java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >>> j >>> java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >>> j >>> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >>> j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j >>> java.lang.Thread.run()V+11 v ~StubRoutines::call_stub V >>> [libjvm.so+0x555ecc] V [libjvm.so+0x747a34] V >>> [libjvm.so+0x554b55] V [libjvm.so+0x5551f0] V >>> [libjvm.so+0x5553cc] V [libjvm.so+0x5be6cd] V >>> [libjvm.so+0x879869] V [libjvm.so+0x87c1b5] V >>> [libjvm.so+0x750455] .... (above is the stack, please see the >>> attachment for more information) Tony (Xiaohua Guan) On Thu, Jul >>> 29, 2010 at 8:07 PM, David Holmes >>> wrote: >>>> Tony, >>>> >>>> I don't see anything obviously wrong with what you attempted. >>>> Can you show the full stack dump from the error. >>>> >>>> David Holmes >>>> >>>> Tony Guan said the following on 07/30/10 07:29: >>>>> Dear all, >>>>> >>>>> I want to invoke the GC at a certain time, for example, when >>>>> a certain method is called at runtime, so I created a new >>>>> subtype of VM_GC_Operation class, and initialized it with an >>>>> object op, finally, executed using:VMThread::execute(&op) >>>>> >>>>> then I got the following error message: >>>>> >>>>> # Internal Error >>>>> >>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>> pid=29652, tid=1096460624 # Error: Possible safepoint >>>>> reached by thread that does not allow it >>>>> >>>>> The reason for the fail is that >>>>> Thread::check_for_valid_safepoint_state() didn't pass because >>>>> the currentThread is not a VMThread. >>>>> >>>>> My question is: how do I bring the current thread to a >>>>> safepoint? or how do I call a GC operation properly? is there >>>>> any prerequisite for doing so? >>>>> >>>>> Thanks! >>>>> >>>>> Tony (Xiaohua Guan) From guanxiaohua at gmail.com Sat Jul 31 15:10:38 2010 From: guanxiaohua at gmail.com (Tony Guan) Date: Sat, 31 Jul 2010 17:10:38 -0500 Subject: how to bring jvm to safepoint In-Reply-To: <4C53BB1E.9070401@oracle.com> References: <4C5225BD.4020909@oracle.com> <4C52797B.1080303@oracle.com> <8E940C36-8120-496D-8425-36E3314F90D8@oracle.com> <4C53BB1E.9070401@oracle.com> Message-ID: Hi David & Tom, Please see the decoded stack below(also full decoded log is attached): " Current thread (0x00000000012ed000): JavaThread "RMI TCP Connection(idle)" daemon [_thread_in_Java, id=30929, stack(0x000000004073b000,0x000000004083c000)] Stack: [0x000000004073b000,0x000000004083c000], sp=0x0000000040839d60, free space=3fb0000000000000000k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x8cad18];; _ZN7VMError6reportEP12outputStream+0xb72 V [libjvm.so+0x8cbe38];; _ZN7VMError14report_and_dieEv+0x5f6 V [libjvm.so+0x4039f1];; _Z12report_fatalPKciS0_+0x6b V [libjvm.so+0x87a183];; _ZN6Thread31check_for_valid_safepoint_stateEb+0x33 V [libjvm.so+0x8e1127];; _ZN8VMThread7executeEP12VM_Operation+0x49 V [libjvm.so+0x4d52ab];; _ZN16GenCollectedHeap27invoke_transEden_collectionEi+0x33 V [libjvm.so+0x7ee63d];; _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 j sun.misc.Unsafe.park(ZJ)V+0 j java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 j java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 j java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 j java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 j java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 j java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub V [libjvm.so+0x555ecc];; _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread+0x474 V [libjvm.so+0x747a34];; _ZN2os20os_exception_wrapperEPFvP9JavaValueP12methodHandleP17JavaCallArgumentsP6ThreadES1_S3_S5_S7_+0x32 V [libjvm.so+0x554b55];; _ZN9JavaCalls4callEP9JavaValue12methodHandleP17JavaCallArgumentsP6Thread+0x6f V [libjvm.so+0x5551f0];; _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandle12symbolHandleS3_P17JavaCallArgumentsP6Thread+0x158 V [libjvm.so+0x5553cc];; _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandle12symbolHandleS4_P6Thread+0x86 V [libjvm.so+0x5be6cd];; _Z12thread_entryP10JavaThreadP6Thread+0x9f V [libjvm.so+0x879869];; _ZN10JavaThread17thread_main_innerEv+0xc9 V [libjvm.so+0x87c1b5];; _ZN10JavaThread3runEv+0x2c1 V [libjvm.so+0x750455];; _Z10java_startP6Thread+0x16f " It's exactly how the error occurred, I am monitoring the sun.misc.Unsafe.park() method call with dtrace(no dtrace agent, just intercepting inside jvm implementation), once this method gets called, I will call GenCollectedHeap::invoke_transEden_collection() to start a GC using VMThread::Execute(&op). At the beginning of VMTHread::Execute(), check_for_valid_safepoint_state is called like this: void VMThread::execute(VM_Operation* op) { Thread* t = Thread::current(); if (!t->is_VM_thread()) { // JavaThread or WatcherThread t->check_for_valid_safepoint_state(true); //And we failed here!! // New request from Java thread, evaluate prologue if (!op->doit_prologue()) { return; // op was cancelled } ... } That's why I said the current thread is not a VM_thread. I think I can make a workaround by invoking the GC at the next allocation request, which should be in the safepoint. But would be great if I can learn more about hotspot solving this problem. Thanks a lot! Tony (Xiaohua Guan) On Sat, Jul 31, 2010 at 12:56 AM, David Holmes wrote: > Tom Rodriguez said the following on 07/31/10 05:01: >> >> Actually I think the problem is that the thread is in thread_in_Java >> state. I don't believe you can safepoint from that state, only >> thread_in_vm. > > The reported failure: > > # ?Error: Possible safepoint reached by thread that does not allow it > > is here: > > void Thread::check_for_valid_safepoint_state(bool potential_vm_operation) { > ? ?// Check if current thread is allowed to block at a safepoint > ? ?if (!(_allow_safepoint_count == 0)) > ? ? ?fatal("Possible safepoint reached by thread that does not allow it"); > > as far as I can see the only code that touches _allow_safepoint_count are > the No_Safepoint_Verifier classes. > > Also the stack shows: > > V ?[libjvm.so+0x7ee63d] > j ?sun.misc.Unsafe.park(ZJ)V+0 > > and so we should have transitioned to _thread_in_vm here. > > That said, Tony also stated: > >> The reason for the fail is that >> Thread::check_for_valid_safepoint_state() didn't pass because >> the currentThread is not a VMThread. > > But that is not supported by the error produced. > > Tony: why did you make the above comment? > > Either way we need to see a decoded stack to get an idea of what is going > wrong. > > Cheers, > David > >> >> tom >> >> On Jul 30, 2010, at 12:04 AM, David Holmes >> wrote: >> >>> Sorry Tony I keep forgetting that I don't have a way to decode a >>> crash log from a VM that you built yourself. :( However you may be >>> able to decode it yourself please see: >>> >>> http://blogs.sun.com/dave/entry/a_tool_to_decode_hs >>> >>> for a perl script. >>> >>> That said looking at the actual assertion failure I am guessing >>> that you initiated the VM operation from code where a >>> No_Safepoint_verifier is active. >>> >>> David >>> >>> Tony Guan said the following on 07/30/10 15:58: >>>> >>>> Hi David, Thanks a lot! I am copying the content to below, and >>>> for convenience, the full log file is attached. cat >>>> hs_err_pid30894.log # # A fatal error has been detected by the >>>> Java Runtime Environment: # # ?Internal Error >>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>> ?pid=30894, tid=1082374480 # ?Error: Possible safepoint reached >>>> by thread that does not allow it # # JRE version: 7.0 # Java VM: >>>> OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug mixed >>>> mode linux-amd64 ) # If you would like to submit a bug report, >>>> please visit: # ? http://java.sun.com/webapps/bugreport/crash.jsp >>>> ?# --------------- ?T H R E A D ?--------------- Current thread >>>> (0x00000000012ed000): ?JavaThread "RMI TCP Connection(idle)" >>>> daemon [_thread_in_Java, id=30929, >>>> stack(0x000000004073b000,0x000000004083c000)] Stack: >>>> [0x000000004073b000,0x000000004083c000], sp=0x0000000040839d60, >>>> free space=3fb0000000000000000k Native frames: (J=compiled Java >>>> code, j=interpreted, Vv=VM code, C=native code) V >>>> [libjvm.so+0x8cad18] V ?[libjvm.so+0x8cbe38] V >>>> [libjvm.so+0x4039f1] V ?[libjvm.so+0x87a183] V >>>> [libjvm.so+0x8e1127] V ?[libjvm.so+0x4d52ab] V >>>> [libjvm.so+0x7ee63d] j ?sun.misc.Unsafe.park(ZJ)V+0 j >>>> >>>> java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >>>> ?j >>>> >>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >>>> ?j >>>> >>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >>>> ?j >>>> >>>> java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >>>> ?j >>>> >>>> java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >>>> ?j >>>> >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >>>> ?j ?java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j >>>> java.lang.Thread.run()V+11 v ?~StubRoutines::call_stub V >>>> [libjvm.so+0x555ecc] V ?[libjvm.so+0x747a34] V >>>> [libjvm.so+0x554b55] V ?[libjvm.so+0x5551f0] V >>>> [libjvm.so+0x5553cc] V ?[libjvm.so+0x5be6cd] V >>>> [libjvm.so+0x879869] V ?[libjvm.so+0x87c1b5] V >>>> [libjvm.so+0x750455] .... (above is the stack, please see the >>>> attachment for more information) Tony (Xiaohua Guan) On Thu, Jul >>>> 29, 2010 at 8:07 PM, David Holmes >>>> wrote: >>>>> >>>>> Tony, >>>>> >>>>> I don't see anything obviously wrong with what you attempted. >>>>> Can you show the full stack dump from the error. >>>>> >>>>> David Holmes >>>>> >>>>> Tony Guan said the following on 07/30/10 07:29: >>>>>> >>>>>> Dear all, >>>>>> >>>>>> I want to invoke the GC at a certain time, for example, when >>>>>> a certain method is called at runtime, so I created a new >>>>>> subtype of VM_GC_Operation class, and initialized it with an >>>>>> object op, finally, executed using:VMThread::execute(&op) >>>>>> >>>>>> then I got the following error message: >>>>>> >>>>>> # ?Internal Error >>>>>> >>>>>> >>>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>>> ?pid=29652, tid=1096460624 # ?Error: Possible safepoint >>>>>> reached by thread that does not allow it >>>>>> >>>>>> The reason for the fail is that >>>>>> Thread::check_for_valid_safepoint_state() didn't pass because >>>>>> the currentThread is not a VMThread. >>>>>> >>>>>> My question is: how do I bring the current thread to a >>>>>> safepoint? or how do I call a GC operation properly? is there >>>>>> any prerequisite for doing so? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Tony (Xiaohua Guan) > -------------- next part -------------- # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), pid=30894, tid=1082374480 # Error: Possible safepoint reached by thread that does not allow it # # JRE version: 7.0 # Java VM: OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug mixed mode linux-amd64 ) # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00000000012ed000): JavaThread "RMI TCP Connection(idle)" daemon [_thread_in_Java, id=30929, stack(0x000000004073b000,0x000000004083c000)] Stack: [0x000000004073b000,0x000000004083c000], sp=0x0000000040839d60, free space=3fb0000000000000000k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x8cad18];; _ZN7VMError6reportEP12outputStream+0xb72 V [libjvm.so+0x8cbe38];; _ZN7VMError14report_and_dieEv+0x5f6 V [libjvm.so+0x4039f1];; _Z12report_fatalPKciS0_+0x6b V [libjvm.so+0x87a183];; _ZN6Thread31check_for_valid_safepoint_stateEb+0x33 V [libjvm.so+0x8e1127];; _ZN8VMThread7executeEP12VM_Operation+0x49 V [libjvm.so+0x4d52ab];; _ZN16GenCollectedHeap27invoke_transEden_collectionEi+0x33 V [libjvm.so+0x7ee63d];; _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 j sun.misc.Unsafe.park(ZJ)V+0 j java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 j java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 j java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 j java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 j java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 j java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub V [libjvm.so+0x555ecc];; _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread+0x474 V [libjvm.so+0x747a34];; _ZN2os20os_exception_wrapperEPFvP9JavaValueP12methodHandleP17JavaCallArgumentsP6ThreadES1_S3_S5_S7_+0x32 V [libjvm.so+0x554b55];; _ZN9JavaCalls4callEP9JavaValue12methodHandleP17JavaCallArgumentsP6Thread+0x6f V [libjvm.so+0x5551f0];; _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandle12symbolHandleS3_P17JavaCallArgumentsP6Thread+0x158 V [libjvm.so+0x5553cc];; _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandle12symbolHandleS4_P6Thread+0x86 V [libjvm.so+0x5be6cd];; _Z12thread_entryP10JavaThreadP6Thread+0x9f V [libjvm.so+0x879869];; _ZN10JavaThread17thread_main_innerEv+0xc9 V [libjvm.so+0x87c1b5];; _ZN10JavaThread3runEv+0x2c1 V [libjvm.so+0x750455];; _Z10java_startP6Thread+0x16f --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x00007ff4ec061000 JavaThread "DestroyJavaVM" [_thread_blocked, id=30897, stack(0x0000000000401000,0x0000000000502000)] =>0x00000000012ed000 JavaThread "RMI TCP Connection(idle)" daemon [_thread_in_Java, id=30929, stack(0x000000004073b000,0x000000004083c000)] 0x00007ff4ec05f000 JavaThread "RMI Scheduler(0)" daemon [_thread_blocked, id=30928, stack(0x0000000041e36000,0x0000000041f37000)] 0x00007ff4ec041800 JavaThread "GC Daemon" daemon [_thread_blocked, id=30925, stack(0x000000004036a000,0x000000004046b000)] 0x00007ff4ec03c000 JavaThread "RMI Reaper" [_thread_blocked, id=30924, stack(0x000000004063a000,0x000000004073b000)] 0x00007ff4ec030000 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=30923, stack(0x000000004052b000,0x000000004062c000)] 0x00000000011d7000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=30921, stack(0x0000000041b66000,0x0000000041c67000)] 0x00000000011d3000 JavaThread "CompilerThread1" daemon [_thread_blocked, id=30920, stack(0x0000000041a65000,0x0000000041b66000)] 0x00000000011cf000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=30919, stack(0x0000000041964000,0x0000000041a65000)] 0x00000000011cc800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=30918, stack(0x0000000040ce6000,0x0000000040de7000)] 0x00000000011a5800 JavaThread "Finalizer" daemon [_thread_blocked, id=30917, stack(0x000000004097b000,0x0000000040a7c000)] 0x000000000119d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=30916, stack(0x0000000041422000,0x0000000041523000)] Other Threads: 0x0000000001193800 VMThread [stack: 0x0000000041d35000,0x0000000041e36000] [id=30915] 0x00000000011da800 WatcherThread [stack: 0x0000000040269000,0x000000004036a000] [id=30922] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 1152K, used 416K [0x00007ff4f4f20000, 0x00007ff4f5060000, 0x00007ff4f5070000) eden space 1024K, 40% used [0x00007ff4f4f20000, 0x00007ff4f4f88330, 0x00007ff4f5020000) from space 128K, 0% used [0x00007ff4f5020000, 0x00007ff4f5020000, 0x00007ff4f5040000) to space 128K, 0% used [0x00007ff4f5040000, 0x00007ff4f5040000, 0x00007ff4f5060000) tenured generation total 1472K, used 273K [0x00007ff4f51c0000, 0x00007ff4f5330000, 0x00007ff4f5720000) the space 1472K, 18% used [0x00007ff4f51c0000, 0x00007ff4f5204670, 0x00007ff4f5204800, 0x00007ff4f5330000) compacting perm gen total 21248K, used 5707K [0x00007ff4f5720000, 0x00007ff4f6be0000, 0x00007ff4fab20000) the space 21248K, 26% used [0x00007ff4f5720000, 0x00007ff4f5cb2f00, 0x00007ff4f5cb3000, 0x00007ff4f6be0000) No shared spaces configured. Dynamic libraries: 00110000-00120000 r-xp 00000000 fd:00 103449070 /opt/java7_debug/jre/lib/amd64/jli/libjli.so 00120000-00320000 ---p 00010000 fd:00 103449070 /opt/java7_debug/jre/lib/amd64/jli/libjli.so 00320000-00322000 rw-p 00010000 fd:00 103449070 /opt/java7_debug/jre/lib/amd64/jli/libjli.so 00400000-00401000 r-xp 00000000 fd:00 103449769 /opt/java7_debug/bin/java 00401000-00404000 ---p 00401000 00:00 0 00404000-00502000 rwxp 00404000 00:00 0 00600000-00601000 rw-p 00000000 fd:00 103449769 /opt/java7_debug/bin/java 00601000-0060f000 r-xp 00000000 fd:00 103449085 /opt/java7_debug/jre/lib/amd64/libverify.so 0060f000-0080e000 ---p 0000e000 fd:00 103449085 /opt/java7_debug/jre/lib/amd64/libverify.so 0080e000-00810000 rw-p 0000d000 fd:00 103449085 /opt/java7_debug/jre/lib/amd64/libverify.so 00810000-0083d000 r-xp 00000000 fd:00 103449083 /opt/java7_debug/jre/lib/amd64/libjava.so 0083d000-00a3c000 ---p 0002d000 fd:00 103449083 /opt/java7_debug/jre/lib/amd64/libjava.so 00a3c000-00a40000 rw-p 0002c000 fd:00 103449083 /opt/java7_debug/jre/lib/amd64/libjava.so 00a40000-00a48000 r-xp 00000000 fd:00 103449094 /opt/java7_debug/jre/lib/amd64/native_threads/libhpi.so 00a48000-00c47000 ---p 00008000 fd:00 103449094 /opt/java7_debug/jre/lib/amd64/native_threads/libhpi.so 00c47000-00c49000 rw-p 00007000 fd:00 103449094 /opt/java7_debug/jre/lib/amd64/native_threads/libhpi.so 00c49000-00c53000 r-xp 00000000 fd:00 3244060 /lib64/libnss_files-2.7.so 00c53000-00e52000 ---p 0000a000 fd:00 3244060 /lib64/libnss_files-2.7.so 00e52000-00e53000 r--p 00009000 fd:00 3244060 /lib64/libnss_files-2.7.so 00e53000-00e54000 rw-p 0000a000 fd:00 3244060 /lib64/libnss_files-2.7.so 00e54000-00e64000 r-xp 00000000 fd:00 103449078 /opt/java7_debug/jre/lib/amd64/libzip.so 00e64000-01063000 ---p 00010000 fd:00 103449078 /opt/java7_debug/jre/lib/amd64/libzip.so 01063000-01065000 rw-p 0000f000 fd:00 103449078 /opt/java7_debug/jre/lib/amd64/libzip.so 010fb000-0136c000 rw-p 010fb000 00:00 0 [heap] 40269000-4026a000 ---p 40269000 00:00 0 4026a000-4036a000 rwxp 4026a000 00:00 0 4036a000-4036d000 ---p 4036a000 00:00 0 4036d000-4046b000 rwxp 4036d000 00:00 0 4052b000-4052e000 ---p 4052b000 00:00 0 4052e000-4062c000 rwxp 4052e000 00:00 0 4063a000-4063d000 ---p 4063a000 00:00 0 4063d000-4073b000 rwxp 4063d000 00:00 0 4073b000-4073e000 ---p 4073b000 00:00 0 4073e000-4083c000 rwxp 4073e000 00:00 0 4097b000-4097e000 ---p 4097b000 00:00 0 4097e000-40a7c000 rwxp 4097e000 00:00 0 40ce6000-40ce9000 ---p 40ce6000 00:00 0 40ce9000-40de7000 rwxp 40ce9000 00:00 0 41422000-41425000 ---p 41422000 00:00 0 41425000-41523000 rwxp 41425000 00:00 0 41964000-41967000 ---p 41964000 00:00 0 41967000-41a65000 rwxp 41967000 00:00 0 41a65000-41a68000 ---p 41a65000 00:00 0 41a68000-41b66000 rwxp 41a68000 00:00 0 41b66000-41b69000 ---p 41b66000 00:00 0 41b69000-41c67000 rwxp 41b69000 00:00 0 41d35000-41d36000 ---p 41d35000 00:00 0 41d36000-41e36000 rwxp 41d36000 00:00 0 41e36000-41e39000 ---p 41e36000 00:00 0 41e39000-41f37000 rwxp 41e39000 00:00 0 3d0d800000-3d0d81b000 r-xp 00000000 fd:00 3244343 /lib64/ld-2.7.so 3d0da1a000-3d0da1b000 r--p 0001a000 fd:00 3244343 /lib64/ld-2.7.so 3d0da1b000-3d0da1c000 rw-p 0001b000 fd:00 3244343 /lib64/ld-2.7.so 3d0dc00000-3d0dd4d000 r-xp 00000000 fd:00 3244344 /lib64/libc-2.7.so 3d0dd4d000-3d0df4d000 ---p 0014d000 fd:00 3244344 /lib64/libc-2.7.so 3d0df4d000-3d0df51000 r--p 0014d000 fd:00 3244344 /lib64/libc-2.7.so 3d0df51000-3d0df52000 rw-p 00151000 fd:00 3244344 /lib64/libc-2.7.so 3d0df52000-3d0df57000 rw-p 3d0df52000 00:00 0 3d0e000000-3d0e082000 r-xp 00000000 fd:00 3244348 /lib64/libm-2.7.so 3d0e082000-3d0e281000 ---p 00082000 fd:00 3244348 /lib64/libm-2.7.so 3d0e281000-3d0e282000 r--p 00081000 fd:00 3244348 /lib64/libm-2.7.so 3d0e282000-3d0e283000 rw-p 00082000 fd:00 3244348 /lib64/libm-2.7.so 3d0e400000-3d0e402000 r-xp 00000000 fd:00 3244138 /lib64/libdl-2.7.so 3d0e402000-3d0e602000 ---p 00002000 fd:00 3244138 /lib64/libdl-2.7.so 3d0e602000-3d0e603000 r--p 00002000 fd:00 3244138 /lib64/libdl-2.7.so 3d0e603000-3d0e604000 rw-p 00003000 fd:00 3244138 /lib64/libdl-2.7.so 3d0e800000-3d0e816000 r-xp 00000000 fd:00 3244346 /lib64/libpthread-2.7.so 3d0e816000-3d0ea15000 ---p 00016000 fd:00 3244346 /lib64/libpthread-2.7.so 3d0ea15000-3d0ea16000 r--p 00015000 fd:00 3244346 /lib64/libpthread-2.7.so 3d0ea16000-3d0ea17000 rw-p 00016000 fd:00 3244346 /lib64/libpthread-2.7.so 3d0ea17000-3d0ea1b000 rw-p 3d0ea17000 00:00 0 3d0f400000-3d0f408000 r-xp 00000000 fd:00 3244353 /lib64/librt-2.7.so 3d0f408000-3d0f607000 ---p 00008000 fd:00 3244353 /lib64/librt-2.7.so 3d0f607000-3d0f608000 r--p 00007000 fd:00 3244353 /lib64/librt-2.7.so 3d0f608000-3d0f609000 rw-p 00008000 fd:00 3244353 /lib64/librt-2.7.so 3d12c00000-3d12c15000 r-xp 00000000 fd:00 3244357 /lib64/libnsl-2.7.so 3d12c15000-3d12e14000 ---p 00015000 fd:00 3244357 /lib64/libnsl-2.7.so 3d12e14000-3d12e15000 r--p 00014000 fd:00 3244357 /lib64/libnsl-2.7.so 3d12e15000-3d12e16000 rw-p 00015000 fd:00 3244357 /lib64/libnsl-2.7.so 3d12e16000-3d12e18000 rw-p 3d12e16000 00:00 0 3d16000000-3d16011000 r-xp 00000000 fd:00 3244359 /lib64/libresolv-2.7.so 3d16011000-3d16211000 ---p 00011000 fd:00 3244359 /lib64/libresolv-2.7.so 3d16211000-3d16212000 r--p 00011000 fd:00 3244359 /lib64/libresolv-2.7.so 3d16212000-3d16213000 rw-p 00012000 fd:00 3244359 /lib64/libresolv-2.7.so 3d16213000-3d16215000 rw-p 3d16213000 00:00 0 7ff4eb8dc000-7ff4eb8dd000 r-xp 00000000 fd:00 103449073 /opt/java7_debug/jre/lib/amd64/librmi.so 7ff4eb8dd000-7ff4ebadc000 ---p 00001000 fd:00 103449073 /opt/java7_debug/jre/lib/amd64/librmi.so 7ff4ebadc000-7ff4ebadd000 rw-p 00000000 fd:00 103449073 /opt/java7_debug/jre/lib/amd64/librmi.so 7ff4ebadd000-7ff4ebae1000 r-xp 00000000 fd:00 3244058 /lib64/libnss_dns-2.7.so 7ff4ebae1000-7ff4ebce0000 ---p 00004000 fd:00 3244058 /lib64/libnss_dns-2.7.so 7ff4ebce0000-7ff4ebce1000 r--p 00003000 fd:00 3244058 /lib64/libnss_dns-2.7.so 7ff4ebce1000-7ff4ebce2000 rw-p 00004000 fd:00 3244058 /lib64/libnss_dns-2.7.so 7ff4ebd00000-7ff4ec063000 rw-p 7ff4ebd00000 00:00 0 7ff4ec063000-7ff4f0000000 ---p 7ff4ec063000 00:00 0 7ff4f0001000-7ff4f0015000 r-xp 00000000 fd:00 103449075 /opt/java7_debug/jre/lib/amd64/libnet.so 7ff4f0015000-7ff4f0215000 ---p 00014000 fd:00 103449075 /opt/java7_debug/jre/lib/amd64/libnet.so 7ff4f0215000-7ff4f0216000 rw-p 00014000 fd:00 103449075 /opt/java7_debug/jre/lib/amd64/libnet.so 7ff4f0216000-7ff4f4c70000 r--p 00000000 fd:00 50203956 /usr/lib/locale/locale-archive 7ff4f4c70000-7ff4f4cd9000 rw-p 7ff4f4c70000 00:00 0 7ff4f4cd9000-7ff4f4e77000 r--s 02fed000 fd:00 103449059 /opt/java7_debug/jre/lib/rt.jar 7ff4f4e77000-7ff4f4ed1000 rw-p 7ff4f4e77000 00:00 0 7ff4f4ed1000-7ff4f4ef1000 rw-p 7ff4f4ed1000 00:00 0 7ff4f4ef1000-7ff4f4ef4000 rw-p 7ff4f4ef1000 00:00 0 7ff4f4ef4000-7ff4f4ef5000 rw-p 7ff4f4ef4000 00:00 0 7ff4f4ef5000-7ff4f4f00000 rw-p 7ff4f4ef5000 00:00 0 7ff4f4f00000-7ff4f4f1f000 rw-p 7ff4f4f00000 00:00 0 7ff4f4f1f000-7ff4f5060000 rw-p 7ff4f4f1f000 00:00 0 7ff4f5060000-7ff4f5070000 rw-p 7ff4f5060000 00:00 0 7ff4f5070000-7ff4f5330000 rw-p 7ff4f5070000 00:00 0 7ff4f5330000-7ff4f5720000 rw-p 7ff4f5330000 00:00 0 7ff4f5720000-7ff4f6be0000 rw-p 7ff4f5720000 00:00 0 7ff4f6be0000-7ff4fab20000 rw-p 7ff4f6be0000 00:00 0 7ff4fab22000-7ff4fab2c000 rw-p 7ff4fab22000 00:00 0 7ff4fab2c000-7ff4fabe2000 rw-p 7ff4fab2c000 00:00 0 7ff4fabe2000-7ff4fae52000 rwxp 7ff4fabe2000 00:00 0 7ff4fae52000-7ff4fdbe2000 rw-p 7ff4fae52000 00:00 0 7ff4fdbe2000-7ff4fe828000 r-xp 00000000 fd:00 103449082 /opt/java7_debug/jre/lib/amd64/server/libjvm.so 7ff4fe828000-7ff4fea27000 ---p 00c46000 fd:00 103449082 /opt/java7_debug/jre/lib/amd64/server/libjvm.so 7ff4fea27000-7ff4feaca000 rw-p 00c45000 fd:00 103449082 /opt/java7_debug/jre/lib/amd64/server/libjvm.so 7ff4feaca000-7ff4feb57000 rw-p 7ff4feaca000 00:00 0 7ff4feb61000-7ff4feb62000 r--s 00000000 fd:00 101384207 /home/tony/software/OpenJDK/jdk7/hotspot/make/linux/rmi/src/compute.jar 7ff4feb62000-7ff4feb65000 r--s 00068000 fd:00 103449134 /opt/java7_debug/jre/lib/jsse.jar 7ff4feb65000-7ff4feb66000 rw-p 7ff4feb65000 00:00 0 7ff4feb66000-7ff4feb68000 rw-p 7ff4feb66000 00:00 0 7ff4feb68000-7ff4feb69000 rw-p 7ff4feb68000 00:00 0 7ff4feb69000-7ff4feb71000 rw-s 00000000 fd:00 39813129 /tmp/hsperfdata_tony/30894 7ff4feb71000-7ff4feb72000 rw-p 7ff4feb71000 00:00 0 7ff4feb72000-7ff4feb73000 r--p 7ff4feb72000 00:00 0 7ff4feb73000-7ff4feb77000 rw-p 7ff4feb73000 00:00 0 7fff06b61000-7fff06b74000 rwxp 7ffffffea000 00:00 0 [stack] 7fff06b74000-7fff06b76000 rw-p 7fffffffd000 00:00 0 7fff06bfe000-7fff06bff000 r-xp 7fff06bfe000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] VM Arguments: jvm_args: -Xmx4m -Xms4m -XX:MAX_TRANSEDEN=6 -XX:-ShowMessageBoxOnError -XX:-TraceThreadEvents -XX:-PrintRemoteMethodNames -XX:-PrintAllMethodNames -XX:+ForceSlowPath -XX:+CollectRemote -XX:-UseTLAB -XX:-UseParallelGC -XX:+DebugTypeGenGC -XX:+PrintHeapAtGC -XX:+PrintGCDetails -XX:+PrintGC -XX:+Verbose -XX:+ExtendedDTraceProbes -XX:+TransGC -XX:+UseTypeGenGC -XX:+PrintCommandLineFlags -XX:NewRatio=2 -Xloggc:gcrmi.log -Djava.rmi.server.codebase=http://cse.unl.edu/~xguan/download/compute.jar -Djava.rmi.server.hostname=localhost -Djava.security.policy=server.policy java_command: engine.ComputeEngine Launcher Type: SUN_STANDARD Environment Variables: JAVA_HOME=/opt/java7_debug PATH=/home/tony/software/apache-maven-2.2.0/bin:/home/tony/software/OpenJDK/apache-ant-1.7.0/bin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/home/tony/bin LD_LIBRARY_PATH=/opt/java7_debug/jre/lib/amd64/server:/opt/java7_debug/jre/lib/amd64:/opt/java7_debug/jre/../lib/amd64 SHELL=/bin/bash Signal Handlers: SIGSEGV: [libjvm.so+0x8cc4f4], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGBUS: [libjvm.so+0x8cc4f4], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGFPE: [libjvm.so+0x74bebc], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGPIPE: [libjvm.so+0x74bebc], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGXFSZ: [libjvm.so+0x74bebc], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGILL: [libjvm.so+0x74bebc], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 SIGUSR2: [libjvm.so+0x74b482], sa_mask[0]=0x00000000, sa_flags=0x10000004 SIGHUP: [libjvm.so+0x74f430], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGINT: [libjvm.so+0x74f430], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGTERM: [libjvm.so+0x74f430], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGQUIT: [libjvm.so+0x74f430], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 --------------- S Y S T E M --------------- OS:Fedora release 8 (Werewolf) uname:Linux 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 18:59:49 EST 2008 x86_64 libc:glibc 2.7 NPTL 2.7 rlimit: STACK 10240k, CORE 0k, NPROC 137216, NOFILE 65535, AS infinity load average:0.06 0.02 0.00 CPU:total 8 (4 cores per cpu, 1 threads per core) family 6 model 23 stepping 6, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1 Memory: 4k page, physical 16472412k(7940608k free), swap 2031608k(2031608k free) vm_info: OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug) for linux-amd64 JRE (1.7.0), built on Jul 29 2010 15:06:19 by "tony" with gcc 4.1.2 20070925 (Red Hat 4.1.2-33) time: Fri Jul 30 00:41:15 2010 elapsed time: 18 seconds From David.Holmes at oracle.com Sat Jul 31 20:43:57 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sun, 01 Aug 2010 13:43:57 +1000 Subject: how to bring jvm to safepoint In-Reply-To: References: <4C5225BD.4020909@oracle.com> <4C52797B.1080303@oracle.com> <8E940C36-8120-496D-8425-36E3314F90D8@oracle.com> <4C53BB1E.9070401@oracle.com> Message-ID: <4C54ED7D.50202@oracle.com> Hi Tony, Now it is all clear :) > It's exactly how the error occurred, I am monitoring the > sun.misc.Unsafe.park() method call with dtrace(no dtrace agent, just > intercepting inside jvm implementation), once this method gets called, > I will call GenCollectedHeap::invoke_transEden_collection() to start a > GC using VMThread::Execute(&op). Right, you are using: _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 but dtrace_method_exit is defined as a runtime "leaf" method (JRT_LEAF). "leaf" methods are not allowed to perform certain actions and in debug mode we have JRT_Leaf_Verifier that is used to check those actions. A JRT_Leaf_Verifier is a No_Safepoint_Verifier - hence as I said before you get the assertion failure due to this. When you do the VMThread::execute to initiate the safepoint operation for your GC action, the current thread will block waiting for it to complete. Part of that blocking involves a safepoint check and hence the system finds that the thread is attempting to enter a safepoint from a "leaf" method - and that is not allowed. You might just try changing the definition of dtrace_method_exit to be JRT_ENTRY rather than JRT_LEAF, but I don't know if that will have unexpected side-effects. There are lots of rules (not necessarily clearly documented) that control how you can call into the VM runtime and how different parts of the VM runtime can call other parts of the runtime. Cheers, David Holmes Tony Guan said the following on 08/01/10 08:10: > Hi David & Tom, > > Please see the decoded stack below(also full decoded log is attached): > > " > Current thread (0x00000000012ed000): JavaThread "RMI TCP > Connection(idle)" daemon [_thread_in_Java, id=30929, > stack(0x000000004073b000,0x000000004083c000)] > > Stack: [0x000000004073b000,0x000000004083c000], > sp=0x0000000040839d60, free space=3fb0000000000000000k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x8cad18];; _ZN7VMError6reportEP12outputStream+0xb72 > V [libjvm.so+0x8cbe38];; _ZN7VMError14report_and_dieEv+0x5f6 > V [libjvm.so+0x4039f1];; _Z12report_fatalPKciS0_+0x6b > V [libjvm.so+0x87a183];; _ZN6Thread31check_for_valid_safepoint_stateEb+0x33 > V [libjvm.so+0x8e1127];; _ZN8VMThread7executeEP12VM_Operation+0x49 > V [libjvm.so+0x4d52ab];; > _ZN16GenCollectedHeap27invoke_transEden_collectionEi+0x33 > V [libjvm.so+0x7ee63d];; > _ZN13SharedRuntime18dtrace_method_exitEP10JavaThreadP13methodOopDesc+0x255 > j sun.misc.Unsafe.park(ZJ)V+0 > j java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 > j java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 > j java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 > j java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 > j java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 > j java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 > j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 > j java.lang.Thread.run()V+11 > v ~StubRoutines::call_stub > V [libjvm.so+0x555ecc];; > _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread+0x474 > V [libjvm.so+0x747a34];; > _ZN2os20os_exception_wrapperEPFvP9JavaValueP12methodHandleP17JavaCallArgumentsP6ThreadES1_S3_S5_S7_+0x32 > V [libjvm.so+0x554b55];; > _ZN9JavaCalls4callEP9JavaValue12methodHandleP17JavaCallArgumentsP6Thread+0x6f > V [libjvm.so+0x5551f0];; > _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandle12symbolHandleS3_P17JavaCallArgumentsP6Thread+0x158 > V [libjvm.so+0x5553cc];; > _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandle12symbolHandleS4_P6Thread+0x86 > V [libjvm.so+0x5be6cd];; _Z12thread_entryP10JavaThreadP6Thread+0x9f > V [libjvm.so+0x879869];; _ZN10JavaThread17thread_main_innerEv+0xc9 > V [libjvm.so+0x87c1b5];; _ZN10JavaThread3runEv+0x2c1 > V [libjvm.so+0x750455];; _Z10java_startP6Thread+0x16f > " > > It's exactly how the error occurred, I am monitoring the > sun.misc.Unsafe.park() method call with dtrace(no dtrace agent, just > intercepting inside jvm implementation), once this method gets called, > I will call GenCollectedHeap::invoke_transEden_collection() to start a > GC using VMThread::Execute(&op). > > At the beginning of VMTHread::Execute(), > check_for_valid_safepoint_state is called like this: > > void VMThread::execute(VM_Operation* op) { > Thread* t = Thread::current(); > if (!t->is_VM_thread()) { > // JavaThread or WatcherThread > t->check_for_valid_safepoint_state(true); //And we failed here!! > // New request from Java thread, evaluate prologue > if (!op->doit_prologue()) { > return; // op was cancelled > } > ... > } > > That's why I said the current thread is not a VM_thread. I think I can > make a workaround by invoking the GC at the next allocation request, > which should be in the safepoint. But would be great if I can learn > more about hotspot solving this problem. > > Thanks a lot! > > Tony (Xiaohua Guan) > > > > On Sat, Jul 31, 2010 at 12:56 AM, David Holmes wrote: >> Tom Rodriguez said the following on 07/31/10 05:01: >>> Actually I think the problem is that the thread is in thread_in_Java >>> state. I don't believe you can safepoint from that state, only >>> thread_in_vm. >> The reported failure: >> >> # Error: Possible safepoint reached by thread that does not allow it >> >> is here: >> >> void Thread::check_for_valid_safepoint_state(bool potential_vm_operation) { >> // Check if current thread is allowed to block at a safepoint >> if (!(_allow_safepoint_count == 0)) >> fatal("Possible safepoint reached by thread that does not allow it"); >> >> as far as I can see the only code that touches _allow_safepoint_count are >> the No_Safepoint_Verifier classes. >> >> Also the stack shows: >> >> V [libjvm.so+0x7ee63d] >> j sun.misc.Unsafe.park(ZJ)V+0 >> >> and so we should have transitioned to _thread_in_vm here. >> >> That said, Tony also stated: >> >>> The reason for the fail is that >>> Thread::check_for_valid_safepoint_state() didn't pass because >>> the currentThread is not a VMThread. >> But that is not supported by the error produced. >> >> Tony: why did you make the above comment? >> >> Either way we need to see a decoded stack to get an idea of what is going >> wrong. >> >> Cheers, >> David >> >>> tom >>> >>> On Jul 30, 2010, at 12:04 AM, David Holmes >>> wrote: >>> >>>> Sorry Tony I keep forgetting that I don't have a way to decode a >>>> crash log from a VM that you built yourself. :( However you may be >>>> able to decode it yourself please see: >>>> >>>> http://blogs.sun.com/dave/entry/a_tool_to_decode_hs >>>> >>>> for a perl script. >>>> >>>> That said looking at the actual assertion failure I am guessing >>>> that you initiated the VM operation from code where a >>>> No_Safepoint_verifier is active. >>>> >>>> David >>>> >>>> Tony Guan said the following on 07/30/10 15:58: >>>>> Hi David, Thanks a lot! I am copying the content to below, and >>>>> for convenience, the full log file is attached. cat >>>>> hs_err_pid30894.log # # A fatal error has been detected by the >>>>> Java Runtime Environment: # # Internal Error >>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>> pid=30894, tid=1082374480 # Error: Possible safepoint reached >>>>> by thread that does not allow it # # JRE version: 7.0 # Java VM: >>>>> OpenJDK 64-Bit Server VM (17.0-b07291505-internal-debug mixed >>>>> mode linux-amd64 ) # If you would like to submit a bug report, >>>>> please visit: # http://java.sun.com/webapps/bugreport/crash.jsp >>>>> # --------------- T H R E A D --------------- Current thread >>>>> (0x00000000012ed000): JavaThread "RMI TCP Connection(idle)" >>>>> daemon [_thread_in_Java, id=30929, >>>>> stack(0x000000004073b000,0x000000004083c000)] Stack: >>>>> [0x000000004073b000,0x000000004083c000], sp=0x0000000040839d60, >>>>> free space=3fb0000000000000000k Native frames: (J=compiled Java >>>>> code, j=interpreted, Vv=VM code, C=native code) V >>>>> [libjvm.so+0x8cad18] V [libjvm.so+0x8cbe38] V >>>>> [libjvm.so+0x4039f1] V [libjvm.so+0x87a183] V >>>>> [libjvm.so+0x8e1127] V [libjvm.so+0x4d52ab] V >>>>> [libjvm.so+0x7ee63d] j sun.misc.Unsafe.park(ZJ)V+0 j >>>>> >>>>> java.util.concurrent.locks.LockSupport.parkNanos(Ljava/lang/Object;J)V+20 >>>>> j >>>>> >>>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;ZJ)Ljava/util/concurrent/SynchronousQueue$TransferStack$SNode;+174 >>>>> j >>>>> >>>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;+102 >>>>> j >>>>> >>>>> java.util.concurrent.SynchronousQueue.poll(JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;+11 >>>>> j >>>>> >>>>> java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable;+141 >>>>> j >>>>> >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+17 >>>>> j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j >>>>> java.lang.Thread.run()V+11 v ~StubRoutines::call_stub V >>>>> [libjvm.so+0x555ecc] V [libjvm.so+0x747a34] V >>>>> [libjvm.so+0x554b55] V [libjvm.so+0x5551f0] V >>>>> [libjvm.so+0x5553cc] V [libjvm.so+0x5be6cd] V >>>>> [libjvm.so+0x879869] V [libjvm.so+0x87c1b5] V >>>>> [libjvm.so+0x750455] .... (above is the stack, please see the >>>>> attachment for more information) Tony (Xiaohua Guan) On Thu, Jul >>>>> 29, 2010 at 8:07 PM, David Holmes >>>>> wrote: >>>>>> Tony, >>>>>> >>>>>> I don't see anything obviously wrong with what you attempted. >>>>>> Can you show the full stack dump from the error. >>>>>> >>>>>> David Holmes >>>>>> >>>>>> Tony Guan said the following on 07/30/10 07:29: >>>>>>> Dear all, >>>>>>> >>>>>>> I want to invoke the GC at a certain time, for example, when >>>>>>> a certain method is called at runtime, so I created a new >>>>>>> subtype of VM_GC_Operation class, and initialized it with an >>>>>>> object op, finally, executed using:VMThread::execute(&op) >>>>>>> >>>>>>> then I got the following error message: >>>>>>> >>>>>>> # Internal Error >>>>>>> >>>>>>> >>>>>>> (/home/tony/software/OpenJDK/jdk7/hotspot/src/share/vm/runtime/thread.cpp:777), >>>>>>> pid=29652, tid=1096460624 # Error: Possible safepoint >>>>>>> reached by thread that does not allow it >>>>>>> >>>>>>> The reason for the fail is that >>>>>>> Thread::check_for_valid_safepoint_state() didn't pass because >>>>>>> the currentThread is not a VMThread. >>>>>>> >>>>>>> My question is: how do I bring the current thread to a >>>>>>> safepoint? or how do I call a GC operation properly? is there >>>>>>> any prerequisite for doing so? >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Tony (Xiaohua Guan)