From lana.steuck at oracle.com Tue Jan 1 21:31:25 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:25 +0000 Subject: hg: jdk8/tl: 10 new changesets Message-ID: <20130102053126.5650B4749D@hg.openjdk.java.net> Changeset: 8e36a0fabf58 Author: ohrstrom Date: 2012-12-18 09:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8e36a0fabf58 8004145: New improved hgforest.sh, ctrl-c now properly terminates mercurial processes. Reviewed-by: ohair, erikj + common/bin/hgforest.sh ! get_source.sh Changeset: 51d3b65b8093 Author: erikj Date: 2012-12-18 17:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/51d3b65b8093 8001901: build-infra: Fix "misbehaving" which command on Solaris Summary: Removed all uses of which in configure on solaris. Reviewed-by: ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: 6ee8080a6efe Author: katleman Date: 2012-12-19 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6ee8080a6efe Merge Changeset: 32148e971ac8 Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/32148e971ac8 Added tag jdk8-b69 for changeset 6ee8080a6efe ! .hgtags Changeset: 6b93e7a4401d Author: dholmes Date: 2012-12-20 01:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6b93e7a4401d 7190137: Add support for JVM_VARIANT minimal1 Summary: Allow configuration of minimal1 as a target VM along with client and server Reviewed-by: ohair, erikj ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: cd06b2ea58dd Author: katleman Date: 2012-12-20 16:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cd06b2ea58dd 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! common/makefiles/RMICompilation.gmk Changeset: 105a25ffa4a4 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/105a25ffa4a4 Merge Changeset: 3fb32a5a2388 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3fb32a5a2388 Added tag jdk8-b70 for changeset 105a25ffa4a4 ! .hgtags Changeset: 51ad2a343420 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/51ad2a343420 Merge Changeset: b845a2494261 Author: lana Date: 2013-01-01 12:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b845a2494261 Merge From lana.steuck at oracle.com Tue Jan 1 21:31:24 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:24 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130102053127.70EEC4749E@hg.openjdk.java.net> Changeset: 603cceb495c8 Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/603cceb495c8 Added tag jdk8-b69 for changeset 22ddcac208a8 ! .hgtags Changeset: 8171d23e914d Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/8171d23e914d Added tag jdk8-b70 for changeset 603cceb495c8 ! .hgtags From lana.steuck at oracle.com Tue Jan 1 21:31:25 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:25 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130102053130.DFAE54749F@hg.openjdk.java.net> Changeset: 3b1c2733d47e Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/3b1c2733d47e Added tag jdk8-b69 for changeset 756323c99011 ! .hgtags Changeset: f577a39c9fb3 Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f577a39c9fb3 Added tag jdk8-b70 for changeset 3b1c2733d47e ! .hgtags From lana.steuck at oracle.com Tue Jan 1 21:31:27 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:27 +0000 Subject: hg: jdk8/tl/jaxp: 5 new changesets Message-ID: <20130102053141.B1FB7474A0@hg.openjdk.java.net> Changeset: 27421008f050 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/27421008f050 Added tag jdk8-b69 for changeset 789a855de959 ! .hgtags Changeset: a72c8391cdd6 Author: katleman Date: 2012-12-20 16:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a72c8391cdd6 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/FactoryImpl.java Changeset: 6ec9edffc286 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6ec9edffc286 Merge Changeset: 63815efd132f Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/63815efd132f Added tag jdk8-b70 for changeset 6ec9edffc286 ! .hgtags Changeset: 499be952a291 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/499be952a291 Merge From lana.steuck at oracle.com Tue Jan 1 21:31:35 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:35 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20130102053153.F32DA474A1@hg.openjdk.java.net> Changeset: 2001991b1b40 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2001991b1b40 Added tag jdk8-b69 for changeset d7360bf35ee1 ! .hgtags Changeset: 7d34e91f66bb Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d34e91f66bb 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! make/Makefile-classic ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! test/tools/javac/StringsInSwitch/StringSwitches.java ! test/tools/javac/api/T6395981.java ! test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java ! test/tools/javac/diags/examples/DuplicateAnnotation.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase1.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase2.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase4.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/AttributeInjector.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFile.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFilePreprocessor.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassToInterfaceConverter.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/DirectedClassLoader.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java ! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 47f71d7c124f Author: katleman Date: 2012-12-26 14:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/47f71d7c124f Merge Changeset: 7d5032c2d747 Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d5032c2d747 Added tag jdk8-b70 for changeset 47f71d7c124f ! .hgtags Changeset: 467e4d9281bc Author: lana Date: 2012-12-28 18:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/467e4d9281bc Merge ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 1d8438db45f2 Author: lana Date: 2013-01-01 17:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1d8438db45f2 Merge From lana.steuck at oracle.com Tue Jan 1 21:31:45 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:45 +0000 Subject: hg: jdk8/tl/hotspot: 47 new changesets Message-ID: <20130102053316.55C33474A2@hg.openjdk.java.net> Changeset: 4a2ed49abd51 Author: amurillo Date: 2012-12-07 10:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4a2ed49abd51 8004724: new hotspot build - hs25-b13 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 442f942757c0 Author: johnc Date: 2012-10-01 09:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/442f942757c0 8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack Summary: Set the value of MarkStackSize to a value based on the number of parallel marking threads with a reasonable minimum. Expand the marking stack if we have to restart marking due to an overflow up to a reasonable maximum. Allocate the underlying space for the marking stack from virtual memory. Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a14c5698a162 Author: johnc Date: 2012-12-07 16:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a14c5698a162 Merge Changeset: 2aa953165ade Author: brutisso Date: 2012-12-13 10:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2aa953165ade 8004661: Comment and function name java_lang_String::toHash is wrong Summary: renamed to hash_code Reviewed-by: dholmes, coleenp, brutisso Contributed-by: erik.helin at oracle.com ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp Changeset: db8a7163c682 Author: stefank Date: 2012-12-13 09:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db8a7163c682 8004674: Add necessary .inline.hpp files to fix non-PCH build Reviewed-by: stefank, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp ! src/share/vm/gc_implementation/shared/gcStats.cpp Changeset: 4459ef2189f5 Author: stefank Date: 2012-12-13 09:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4459ef2189f5 Merge Changeset: fd74228fd5ca Author: jiangli Date: 2012-12-11 12:41 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd74228fd5ca 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing. Summary: Move _max_locals and _size_of_parameters to ConstMethod for better sharing. Reviewed-by: coleenp, minqi, jrose ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 807f1d348f7b Author: collins Date: 2012-12-14 11:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/807f1d348f7b Merge Changeset: b6c9c0109a60 Author: amurillo Date: 2012-12-14 14:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b6c9c0109a60 Merge Changeset: cb8a4e04bc8c Author: amurillo Date: 2012-12-14 14:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cb8a4e04bc8c Added tag hs25-b13 for changeset b6c9c0109a60 ! .hgtags Changeset: 8b4810c80f5d Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b4810c80f5d Added tag jdk8-b69 for changeset cb8a4e04bc8c ! .hgtags Changeset: 1f323009c3ea Author: amurillo Date: 2012-12-14 14:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f323009c3ea 8005036: new hotspot build - hs25-b14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 892acf0431ef Author: dcubed Date: 2012-12-14 10:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/892acf0431ef 7153050: remove crufty '_g' support from HotSpot repo makefiles Summary: Phase 1 is removing '_g' support from the Makefiles. Reviewed-by: dcubed, sspitsyn, coleenp, tbell Contributed-by: ron.durbin at oracle.com ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/debug.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/fastdebug.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/jvmg.make ! make/bsd/makefiles/optimized.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/vm.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/debug.make ! make/linux/makefiles/fastdebug.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/jvmg.make ! make/linux/makefiles/optimized.make ! make/linux/makefiles/product.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/debug.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/jvmg.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/projectfiles/compiler2/ADLCompiler.dsp ! make/windows/projectfiles/tiered/ADLCompiler.dsp Changeset: 30866cd626b0 Author: coleenp Date: 2012-12-12 11:39 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/30866cd626b0 8004883: NPG: clean up anonymous class fix Summary: Add klass_holder() to return either mirror or class_loader depending on if the class is anonymous or not. Reviewed-by: stefank, jrose ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp Changeset: 18712b1caf7a Author: rkennke Date: 2012-12-12 21:40 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/18712b1caf7a 8004898: library_call.cpp build error after 7172640 with GCC 4.7.2 Summary: fix opto/library_call.cpp compilation errors Reviewed-by: twisti, coleenp ! src/share/vm/opto/library_call.cpp Changeset: 8580f22db905 Author: coleenp Date: 2012-12-14 16:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8580f22db905 Merge Changeset: 3f84e17b6bca Author: zgu Date: 2012-12-17 13:14 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f84e17b6bca 8004802: jcmd VM.native_memory baseline=false crashes VM Summary: NMT has to check option's value also to determine which command to execute Reviewed-by: acorn, coleenp, hseigel ! src/share/vm/services/nmtDCmd.cpp Changeset: 805aa223d540 Author: zgu Date: 2012-12-17 10:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/805aa223d540 Merge Changeset: 594b9b2119ed Author: minqi Date: 2012-12-19 16:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/594b9b2119ed Merge Changeset: 0c535211ef13 Author: bharadwaj Date: 2012-12-07 18:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c535211ef13 8004668: Build failure for Zero target Summary: fixed build failure for Zero target Reviewed-by: twisti, kvn ! src/cpu/zero/vm/assembler_zero.cpp Changeset: a70c88896791 Author: kvn Date: 2012-12-13 17:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a70c88896791 8004713: Stackoverflowerror thrown when thread stack straddles 0x80000000 Summary: use unsigned comparison when checking for stack overflow Reviewed-by: kvn, twisti Contributed-by: paul.nauman at oracle.com ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp Changeset: 1b1e16471e46 Author: stefank Date: 2012-12-12 22:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b1e16471e46 8005002: Crash because of a raw oop in ClassLoaderData::add_dependency Summary: Move the handelization of 'last' to a point before the GC might enter. Reviewed-by: dholmes, sspitsyn, coleenp ! src/share/vm/classfile/classLoaderData.cpp Changeset: 5c0931d15474 Author: twisti Date: 2012-12-14 12:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c0931d15474 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java Reviewed-by: jrose, kvn ! src/share/vm/prims/methodHandles.cpp Changeset: 3c433d080bae Author: twisti Date: 2012-12-14 12:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c433d080bae Merge Changeset: 18d56ca3e901 Author: twisti Date: 2012-12-17 11:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/18d56ca3e901 8004548: remove unused AbstractAssembler::print(Label&) Reviewed-by: kvn, twisti Contributed-by: Bharadwaj Yadavalli ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: ad5dd04754ee Author: roland Date: 2012-12-18 14:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ad5dd04754ee 8005031: Some cleanup in c2 to prepare for incremental inlining support Summary: collection of small changes to prepare for incremental inlining. Reviewed-by: twisti, kvn ! src/share/vm/ci/ciField.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/stringopts.cpp Changeset: eb409f2f146e Author: vlivanov Date: 2012-12-18 06:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eb409f2f146e 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop Summary: Make the load of TLS._osthread._interrupted flag in Thread.isInterrupted(Z)Z intrinsic effectively volatile. Reviewed-by: kvn, jrose ! src/share/vm/opto/library_call.cpp Changeset: 620e502e3f47 Author: vlivanov Date: 2012-12-18 08:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/620e502e3f47 Merge ! src/share/vm/opto/library_call.cpp Changeset: c4bd2eccea46 Author: twisti Date: 2012-12-18 10:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c4bd2eccea46 8004536: replace AbstractAssembler emit_word with emit_int16 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.hpp Changeset: 1e41b0bc58a0 Author: kvn Date: 2012-12-18 17:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e41b0bc58a0 8004318: JEP-171: Support Unsafe fences intrinsics Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class. Reviewed-by: twisti, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 65c8342f726a Author: twisti Date: 2012-12-19 14:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65c8342f726a 8005033: clear high word for integer pop count on SPARC Reviewed-by: kvn, twisti Contributed-by: Richard Reingruber ! src/cpu/sparc/vm/sparc.ad + test/compiler/8005033/Test8005033.java Changeset: 2c7f594145dc Author: kvn Date: 2012-12-19 15:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c7f594145dc 8004835: Improve AES intrinsics on x86 Summary: Enable AES intrinsics on non-AVX cpus, group together aes instructions in crypto stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! test/compiler/7184394/TestAESBase.java ! test/compiler/7184394/TestAESMain.java Changeset: 2d6c433b1f38 Author: kvn Date: 2012-12-19 19:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2d6c433b1f38 8004741: Missing compiled exception handle table entry for multidimensional array allocation Summary: Added missing exception path for multidimensional array allocation and use Throwable type instead of OutOfMemoryError for allocation's exception. Reviewed-by: twisti ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + test/compiler/8004741/Test8004741.java Changeset: a46457045d66 Author: kvn Date: 2012-12-20 14:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a46457045d66 8004330: Add missing Unsafe entry points for addAndGet() family Summary: Fix java names for getAndSet intrinsics Reviewed-by: kvn Contributed-by: aleksey.shipilev at oracle.com ! src/share/vm/classfile/vmSymbols.hpp Changeset: d02120b7a34f Author: twisti Date: 2012-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d02120b7a34f 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: c52660592f37 Author: roland Date: 2012-12-21 01:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c52660592f37 Merge ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/opto/library_call.cpp Changeset: 0b3d19153cc6 Author: johnc Date: 2012-12-12 12:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b3d19153cc6 8001028: Improve GC option handling Summary: If there are not enough native resources to create the ReferenceHandler or Finalizer Java threads, the VM will attempt to throw an OOME before the java.lang.Class class has been initialized. This can result in assertion failures and other crashes. Move the initialization of the java.lang.Class class to just before the initialization of the java.lang.ref.Finalizer class. Reviewed-by: jwilhelm, dholmes, coleenp ! src/share/vm/runtime/thread.cpp Changeset: 730cc4ddd550 Author: brutisso Date: 2012-12-17 08:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/730cc4ddd550 7173959: Jvm crashed during coherence exabus (tmb) testing Summary: Mapping of aligned memory needs to be MT safe. Also reviewed by: vitalyd at gmail.com Reviewed-by: dholmes, coleenp, zgu ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp Changeset: 32164d89fe9c Author: brutisso Date: 2012-12-17 15:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/32164d89fe9c 8004845: Catch incorrect usage of new and delete during compile time for value objects and stack objects Summary: Makes the "new" and "delete" operator of _ValueObj and StackObj private Reviewed-by: dholmes, coleenp Contributed-by: erik.helin at oracle.com ! src/share/vm/memory/allocation.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: c71879335291 Author: stefank Date: 2012-12-18 10:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c71879335291 8005108: NPG: MetaspaceAux::used_in_bytes(), capacity_in_bytes() and reserved_in_bytes() return inconsistent numbers Summary: Reverted the changes to these functions from JDK-8000662 Reviewed-by: brutisso, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 345bd97a77be Author: brutisso Date: 2012-12-20 05:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/345bd97a77be 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag Reviewed-by: stefank, brutisso, kvn, ctornqvi Contributed-by: erik.helin at oracle.com + test/sanity/ExecuteInternalVMTests.java Changeset: 69627aa9ab10 Author: jwilhelm Date: 2012-12-21 16:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69627aa9ab10 Merge ! src/share/vm/runtime/thread.cpp Changeset: 990bbd393c23 Author: amurillo Date: 2012-12-21 10:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/990bbd393c23 Merge Changeset: 6a1fc440b396 Author: amurillo Date: 2012-12-21 10:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6a1fc440b396 Added tag hs25-b14 for changeset 990bbd393c23 ! .hgtags Changeset: 79f492f184d0 Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79f492f184d0 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciField.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstance.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMetadata.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/BitData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/RetData.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallDynamicJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java ! agent/src/share/classes/sun/jvm/hotspot/opto/HaltNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java ! agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java ! agent/src/share/classes/sun/jvm/hotspot/opto/LoopNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachIfNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachReturnNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachSafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MultiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Phase.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseRegAlloc.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/ProjNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RegionNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RootNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/SafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/TypeNode.java ! agent/src/share/classes/sun/jvm/hotspot/prims/JvmtiExport.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GrowableArray.java ! agent/src/share/native/sadis.c ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/runtime/os_ext.hpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! test/runtime/7158804/Test7158804.sh Changeset: e94068d4ff52 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e94068d4ff52 Merge ! src/share/vm/classfile/classLoaderData.hpp Changeset: 0847210f8548 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0847210f8548 Added tag jdk8-b70 for changeset e94068d4ff52 ! .hgtags From lana.steuck at oracle.com Tue Jan 1 21:33:15 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:33:15 +0000 Subject: hg: jdk8/tl/jdk: 26 new changesets Message-ID: <20130102053807.24DCB474A5@hg.openjdk.java.net> Changeset: 4ea0ac8e02d2 Author: erikj Date: 2012-12-19 09:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ea0ac8e02d2 8004803: build-infra: Cannot use icedtea as boot for closed build. Summary: Set bootclasspath to javac and not the running jvm Reviewed-by: ohair ! makefiles/CreateJars.gmk Changeset: a8012d8d7e9c Author: katleman Date: 2012-12-19 13:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8012d8d7e9c Merge Changeset: 4d5db5c038b4 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d5db5c038b4 Added tag jdk8-b69 for changeset a8012d8d7e9c ! .hgtags Changeset: ad6097d547e1 Author: kvn Date: 2012-12-18 17:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad6097d547e1 8004318: JEP-171: Support Unsafe fences intrinsics Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class. Reviewed-by: twisti, kvn Contributed-by: Aleksey Shipilev ! src/share/classes/sun/misc/Unsafe.java Changeset: 12fa4d7ecaf5 Author: twisti Date: 2012-12-20 11:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12fa4d7ecaf5 8005345: JSR 292: JDK performance tweaks Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/sun/invoke/util/ValueConversions.java Changeset: 8cf5b18488d1 Author: dl Date: 2012-12-20 12:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8cf5b18488d1 8004330: Add missing Unsafe entry points for addAndGet() family Summary: Add Unsafe addAndGet() methods which have intrinsics in Hotspot (7023898) Reviewed-by: alanb, kvn ! src/share/classes/sun/misc/Unsafe.java Changeset: 6b41b40526c6 Author: amurillo Date: 2012-12-21 10:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b41b40526c6 Merge Changeset: 1ad29569d6e9 Author: erikj Date: 2012-12-20 13:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ad29569d6e9 8005178: build-infra: Dependency on libfdlibm on mac is broken Reviewed-by: tbell, ohair ! makefiles/CompileNativeLibraries.gmk Changeset: a68090f0dc1a Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a68090f0dc1a 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! src/macosx/native/sun/font/CCharToGlyphMapper.m ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/sun/java2d/pipe/ParallelogramPipe.java ! src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/native/java/util/zip/zlib-1.2.5/gzlib.c ! src/solaris/native/common/jdk_util_md.h ! src/solaris/native/sun/tools/attach/BsdVirtualMachine.c ! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/windows/native/common/jdk_util_md.h ! test/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI/7089914/bug7089914.java ! test/java/awt/Focus/6981400/Test1.java ! test/java/awt/Focus/6981400/Test2.java ! test/java/awt/Focus/6981400/Test3.java ! test/java/awt/Frame/ResizeAfterSetFont/ResizeAfterSetFont.java ! test/java/awt/JAWT/JAWT.sh ! test/java/awt/JAWT/Makefile.cygwin ! test/java/awt/JAWT/Makefile.unix ! test/java/awt/JAWT/Makefile.win ! test/java/awt/JAWT/MyCanvas.java ! test/java/awt/JAWT/myfile.c ! test/java/awt/JAWT/myfile.cpp ! test/java/awt/TextArea/DisposeTest/TestDispose.java ! test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java ! test/java/awt/TextField/DisposeTest/TestDispose.java ! test/java/lang/Integer/Unsigned.java ! test/java/lang/Long/Unsigned.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Tests.java ! test/java/lang/StringBuffer/TestSynchronization.java ! test/java/lang/invoke/remote/RemoteExample.java ! test/java/math/BigDecimal/FloatDoubleValueTests.java ! test/java/math/BigDecimal/StrippingZerosTest.java ! test/java/net/Inet4Address/PingThis.java ! test/java/net/ProxySelector/MultiThreadedSystemProxies.java ! test/java/security/Signature/VerifyRangeCheckOverflow.java ! test/java/util/AbstractCollection/ToArrayTest.java ! test/java/util/Map/EntryHashCode.java ! test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java ! test/java/util/logging/LoggerResourceBundleRace.java ! test/java/util/logging/LoggingDeadlock2.java ! test/java/util/logging/LoggingDeadlock3.java ! test/java/util/logging/SimpleFormatterFormat.java ! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB.xml ! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB_ja.xml ! test/javax/swing/JComponent/7154030/bug7154030.java ! test/javax/swing/JTabbedPane/4310381/bug4310381.java ! test/javax/swing/JTable/4235420/bug4235420.java ! test/javax/swing/JTable/6788484/bug6788484.java ! test/javax/swing/JTable/7055065/bug7055065.java ! test/javax/swing/JTable/7188612/JTableAccessibleGetLocationOnScreen.java ! test/javax/swing/JTextArea/7049024/bug7049024.java ! test/javax/swing/border/Test7022041.java ! test/javax/swing/text/DefaultCaret/6938583/bug6938583.java ! test/sun/management/AgentCMETest.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/nio/ch/SelProvider.java ! test/sun/rmi/rmic/classpath/RMICClassPathTest.java ! test/sun/security/krb5/auto/ReplayCache.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java ! test/sun/tools/jps/jps-V_2.sh ! test/tools/jar/JarBackSlash.java ! test/tools/launcher/UnicodeTest.java Changeset: 9dc1990c7d90 Author: yhuang Date: 2012-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9dc1990c7d90 7195759: ISO 4217 Amendment 154 Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/CurrencyNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: cbf255324369 Author: yhuang Date: 2012-12-23 19:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cbf255324369 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: a996b57e5541 Author: katleman Date: 2012-12-26 14:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a996b57e5541 Merge Changeset: 8d7651351cfe Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d7651351cfe Added tag jdk8-b70 for changeset a996b57e5541 ! .hgtags Changeset: a988c23b8553 Author: jgodinez Date: 2012-12-20 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a988c23b8553 7180359: Assertion in awt_Win32GraphicsDevice.cpp when running specjbb in jprt Reviewed-by: bae, prr ! src/windows/native/sun/windows/awt_Debug.cpp Changeset: 2cf07dbdee64 Author: bae Date: 2012-12-24 14:03 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cf07dbdee64 7124245: [lcms] ColorConvertOp to color space CS_GRAY apparently converts orange to 244,244,0 Reviewed-by: prr ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c + test/sun/java2d/cmm/ColorConvertOp/GrayTest.java Changeset: 3c1c0b7abe51 Author: bae Date: 2012-12-24 14:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c1c0b7abe51 8005402: Need to provide benchmarks for color management Reviewed-by: jgodinez, prr ! src/share/demo/java2d/J2DBench/build.xml ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/CMMTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConvertOpTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/DataConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ProfileTests.java Changeset: 1316d6d0900e Author: lana Date: 2012-12-28 18:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1316d6d0900e Merge Changeset: c25ea633b4de Author: malenkov Date: 2012-12-17 16:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c25ea633b4de 8005065: [findbugs] reference to mutable array in JavaBeans Reviewed-by: alexsch ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/Statement.java + test/java/beans/Introspector/Test8005065.java Changeset: a78cb3c5d434 Author: neugens Date: 2012-12-17 17:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a78cb3c5d434 8005018: X11: focus problems with openjdk 1.7.0 under gnome3 when selected keyboard is not the first in keyboard list Summary: Don't consider extraenous bits when checking button mask, so that grabWindowRef on the window is not confused and released correctly Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java Changeset: 985b523712c8 Author: kshefov Date: 2012-12-18 15:17 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/985b523712c8 7104594: [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default Reviewed-by: yan, alexsch + test/javax/swing/JFrame/4962534/bug4962534.html + test/javax/swing/JFrame/4962534/bug4962534.java Changeset: 90ad9e922042 Author: lana Date: 2012-12-18 16:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90ad9e922042 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: 7082a96c02d2 Author: alexp Date: 2012-12-21 19:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7082a96c02d2 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx Reviewed-by: anthony, alexsch ! test/javax/swing/AncestorNotifier/7193219/bug7193219.java Changeset: 14269f504837 Author: dcherepanov Date: 2012-12-27 16:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/14269f504837 8001161: mac: EmbeddedFrame doesn't become active window Reviewed-by: ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: cf2bcb293f0b Author: lana Date: 2012-12-28 18:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf2bcb293f0b Merge Changeset: 2a5af0f766d0 Author: lana Date: 2012-12-28 18:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a5af0f766d0 Merge - make/jdk/asm/Makefile ! makefiles/CreateJars.gmk ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: 38b9a7646093 Author: lana Date: 2013-01-01 17:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38b9a7646093 Merge ! makefiles/CreateJars.gmk From stuart.marks at oracle.com Wed Jan 2 14:21:21 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Wed, 02 Jan 2013 22:21:21 +0000 Subject: hg: jdk8/tl/jdk: 8005118: Javadoc styles are inconsistent Message-ID: <20130102222134.1A575474D1@hg.openjdk.java.net> Changeset: cc78ceb99284 Author: jgish Date: 2012-12-28 16:56 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc78ceb99284 8005118: Javadoc styles are inconsistent Summary: use a common javadoc style in the String classes Reviewed-by: darcy ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java ! src/share/classes/java/lang/StringIndexOutOfBoundsException.java From chris.hegarty at oracle.com Thu Jan 3 02:01:53 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 03 Jan 2013 10:01:53 +0000 Subject: hg: jdk8/tl/jdk: 8005634: tools/launcher/VersionCheck.java fails version check on jdeps Message-ID: <20130103100231.C1768474E8@hg.openjdk.java.net> Changeset: 21708d15553b Author: chegar Date: 2013-01-03 10:00 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21708d15553b 8005634: tools/launcher/VersionCheck.java fails version check on jdeps Summary: add jdeps to the list of tools that do not support '-version' Reviewed-by: mchung ! test/tools/launcher/VersionCheck.java From coleen.phillimore at oracle.com Thu Jan 3 08:29:57 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 03 Jan 2013 16:29:57 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with CompressedOops and KlassPtrs Message-ID: <20130103163001.0E352474F8@hg.openjdk.java.net> Changeset: cc6a617fffd2 Author: coleenp Date: 2013-01-02 20:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cc6a617fffd2 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with CompressedOops and KlassPtrs Summary: Relocate functions with jsr's when rewriting so not repeated after reading shared archive Reviewed-by: twisti, jrose ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.inline.hpp From john.coomes at oracle.com Thu Jan 3 21:56:12 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:56:12 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b71 for changeset f577a39c9fb3 Message-ID: <20130104055617.C7E1A47543@hg.openjdk.java.net> Changeset: d9707230294d Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/d9707230294d Added tag jdk8-b71 for changeset f577a39c9fb3 ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:55:35 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:55:35 +0000 Subject: hg: hsx/hotspot-rt: 5 new changesets Message-ID: <20130104055535.A88C247540@hg.openjdk.java.net> Changeset: 2ed5be3dd506 Author: lana Date: 2012-12-16 22:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/2ed5be3dd506 Merge Changeset: a0779b1e9a4d Author: jjg Date: 2012-12-17 08:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/a0779b1e9a4d 8005090: Include com.sun.source.doctree in Tree API docs Reviewed-by: erikj ! common/makefiles/javadoc/NON_CORE_PKGS.gmk Changeset: 68a81db3ceb1 Author: lana Date: 2012-12-18 17:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/68a81db3ceb1 Merge Changeset: 51ad2a343420 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/51ad2a343420 Merge Changeset: c1be681d80a1 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/c1be681d80a1 Added tag jdk8-b71 for changeset 51ad2a343420 ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:55:39 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:55:39 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b71 for changeset 8171d23e914d Message-ID: <20130104055541.A0F4E47541@hg.openjdk.java.net> Changeset: cb40427f4714 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/cb40427f4714 Added tag jdk8-b71 for changeset 8171d23e914d ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:55:46 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:55:46 +0000 Subject: hg: hsx/hotspot-rt/jaxp: 6 new changesets Message-ID: <20130104055607.E199947542@hg.openjdk.java.net> Changeset: b1fdb101c82e Author: joehw Date: 2012-12-14 13:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/b1fdb101c82e 8003260: [findbug] some fields should be package protected Summary: change public or protected mutable static fields to private or package private. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java Changeset: 8a20e948b806 Author: lana Date: 2012-12-16 22:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/8a20e948b806 Merge Changeset: 15b32367b23c Author: joehw Date: 2012-12-18 21:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/15b32367b23c 8003261: static field is public but not final Summary: add final to fVersion field, and make it a non-compile time constant. Reviewed-by: hawtin, lancea, dholmes, chegar ! src/com/sun/org/apache/xerces/internal/impl/Version.java Changeset: d4aea0225e80 Author: joehw Date: 2012-12-27 18:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/d4aea0225e80 8005473: Warnings compiling jaxp Summary: clean up compiling warnings. Reviewed-by: weijun, chegar, forax ! src/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java ! src/javax/xml/transform/FactoryFinder.java ! src/javax/xml/validation/SchemaFactoryFinder.java ! src/javax/xml/xpath/XPathFactoryFinder.java Changeset: 499be952a291 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/499be952a291 Merge Changeset: bdf2af722a6b Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/bdf2af722a6b Added tag jdk8-b71 for changeset 499be952a291 ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:57:57 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:57:57 +0000 Subject: hg: hsx/hotspot-rt/jdk: 53 new changesets Message-ID: <20130104060820.E713647544@hg.openjdk.java.net> Changeset: a988c23b8553 Author: jgodinez Date: 2012-12-20 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a988c23b8553 7180359: Assertion in awt_Win32GraphicsDevice.cpp when running specjbb in jprt Reviewed-by: bae, prr ! src/windows/native/sun/windows/awt_Debug.cpp Changeset: 2cf07dbdee64 Author: bae Date: 2012-12-24 14:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2cf07dbdee64 7124245: [lcms] ColorConvertOp to color space CS_GRAY apparently converts orange to 244,244,0 Reviewed-by: prr ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c + test/sun/java2d/cmm/ColorConvertOp/GrayTest.java Changeset: 3c1c0b7abe51 Author: bae Date: 2012-12-24 14:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3c1c0b7abe51 8005402: Need to provide benchmarks for color management Reviewed-by: jgodinez, prr ! src/share/demo/java2d/J2DBench/build.xml ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/CMMTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConvertOpTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/DataConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ProfileTests.java Changeset: 1316d6d0900e Author: lana Date: 2012-12-28 18:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1316d6d0900e Merge Changeset: c25ea633b4de Author: malenkov Date: 2012-12-17 16:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c25ea633b4de 8005065: [findbugs] reference to mutable array in JavaBeans Reviewed-by: alexsch ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/Statement.java + test/java/beans/Introspector/Test8005065.java Changeset: a78cb3c5d434 Author: neugens Date: 2012-12-17 17:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a78cb3c5d434 8005018: X11: focus problems with openjdk 1.7.0 under gnome3 when selected keyboard is not the first in keyboard list Summary: Don't consider extraenous bits when checking button mask, so that grabWindowRef on the window is not confused and released correctly Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java Changeset: 985b523712c8 Author: kshefov Date: 2012-12-18 15:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/985b523712c8 7104594: [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default Reviewed-by: yan, alexsch + test/javax/swing/JFrame/4962534/bug4962534.html + test/javax/swing/JFrame/4962534/bug4962534.java Changeset: 90ad9e922042 Author: lana Date: 2012-12-18 16:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/90ad9e922042 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: 7082a96c02d2 Author: alexp Date: 2012-12-21 19:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7082a96c02d2 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx Reviewed-by: anthony, alexsch ! test/javax/swing/AncestorNotifier/7193219/bug7193219.java Changeset: 14269f504837 Author: dcherepanov Date: 2012-12-27 16:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/14269f504837 8001161: mac: EmbeddedFrame doesn't become active window Reviewed-by: ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: cf2bcb293f0b Author: lana Date: 2012-12-28 18:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cf2bcb293f0b Merge Changeset: 69fd3f3d20c1 Author: alanb Date: 2012-12-15 15:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/69fd3f3d20c1 8004963: URLConnection, downgrade normative reference to ${java.home}/lib/content-types.properties Reviewed-by: chegar ! src/share/classes/java/net/URLConnection.java Changeset: eaaec81aa974 Author: weijun Date: 2012-12-17 12:18 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eaaec81aa974 7197159: accept different kvno if there no match Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/EncryptionKey.java ! test/sun/security/krb5/auto/DynamicKeytab.java + test/sun/security/krb5/auto/KvnoNA.java ! test/sun/security/krb5/auto/MoreKvno.java Changeset: f959e0cc8766 Author: lana Date: 2012-12-16 22:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f959e0cc8766 Merge ! makefiles/CompileNativeLibraries.gmk - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: a02212de8db6 Author: uta Date: 2012-12-17 14:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a02212de8db6 8004928: TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem Summary: the tests were refactored to drop AWT dependence where it was possible. Reviewed-by: alanb, mchung ! test/java/io/Serializable/resolveProxyClass/NonPublicInterface.java ! test/java/lang/Throwable/LegacyChainedExceptionSerialization.java ! test/java/lang/management/CompilationMXBean/Basic.java ! test/java/lang/reflect/Generics/Probe.java ! test/java/lang/reflect/Proxy/ClassRestrictions.java ! test/java/util/Collections/EmptyIterator.java ! test/java/util/logging/LoggingDeadlock4.java ! test/sun/tools/jrunscript/common.sh Changeset: e4d88a7352c6 Author: mullan Date: 2012-12-17 08:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e4d88a7352c6 8004234: Downgrade normative references to ${java.home}/lib/security/krb5.conf Reviewed-by: alanb, weijun ! src/share/classes/javax/security/auth/kerberos/package.html Changeset: 4a21f818ebb1 Author: mullan Date: 2012-12-17 08:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4a21f818ebb1 Merge - src/share/classes/sun/awt/TextureSizeConstraining.java - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: bcf79e6f52a0 Author: chegar Date: 2012-12-17 16:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bcf79e6f52a0 8005081: java/util/prefs/PrefsSpi.sh fails on macos-x Reviewed-by: alanb ! test/java/util/prefs/PrefsSpi.sh Changeset: 9f1b516cd9cb Author: jjg Date: 2012-12-17 08:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9f1b516cd9cb 8005090: Include com.sun.source.doctree in Tree API docs Reviewed-by: erikj ! make/docs/NON_CORE_PKGS.gmk Changeset: bac477d67867 Author: jjg Date: 2012-12-17 10:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bac477d67867 8004832: Add new doclint package Reviewed-by: erikj, ohair ! make/common/Release.gmk ! make/common/internal/Defs-langtools.gmk ! makefiles/CreateJars.gmk Changeset: 0fabdf676395 Author: martin Date: 2012-12-17 18:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0fabdf676395 8004863: Infinite Loop in KeepAliveStream Reviewed-by: chegar ! src/share/classes/sun/net/www/http/KeepAliveStream.java + test/sun/net/www/http/KeepAliveStream/InfiniteLoop.java Changeset: 0a1398021c7c Author: darcy Date: 2012-12-18 14:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0a1398021c7c 8005042: Add Method.isDefault to core reflection Reviewed-by: alanb, forax, mduigou, jgish, mchung ! src/share/classes/java/lang/reflect/Method.java + test/java/lang/reflect/Method/IsDefaultTest.java Changeset: 6d977f61af5e Author: darcy Date: 2012-12-18 14:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6d977f61af5e 8004699: Add type annotation storage to Constructor, Field and Method Reviewed-by: darcy, dholmes Contributed-by: joel.franck at oracle.com ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java Changeset: e515956879cd Author: lana Date: 2012-12-18 18:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e515956879cd Merge Changeset: c79b26b8efe0 Author: sjiang Date: 2012-12-19 11:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c79b26b8efe0 7158614: JMXStartStopTest.sh failing intermittently Summary: fixed 3 problems here: 1) checked the lock file too eary 2) never got the process id of a java test 3) some shell commands were not supported in some Solaris machines. Reviewed-by: dsamersoff, alanb ! test/ProblemList.txt ! test/sun/management/jmxremote/startstop/JMXStartStopDoSomething.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: 3fd3bcc8bd42 Author: joehw Date: 2012-12-19 12:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3fd3bcc8bd42 8004371: (props) Properties.loadFromXML needs small footprint XML parser as fallback when JAXP is not present Reviewed-by: alanb, mchung, psandoz + src/share/classes/jdk/internal/org/xml/sax/Attributes.java + src/share/classes/jdk/internal/org/xml/sax/ContentHandler.java + src/share/classes/jdk/internal/org/xml/sax/DTDHandler.java + src/share/classes/jdk/internal/org/xml/sax/EntityResolver.java + src/share/classes/jdk/internal/org/xml/sax/ErrorHandler.java + src/share/classes/jdk/internal/org/xml/sax/InputSource.java + src/share/classes/jdk/internal/org/xml/sax/Locator.java + src/share/classes/jdk/internal/org/xml/sax/SAXException.java + src/share/classes/jdk/internal/org/xml/sax/SAXNotRecognizedException.java + src/share/classes/jdk/internal/org/xml/sax/SAXNotSupportedException.java + src/share/classes/jdk/internal/org/xml/sax/SAXParseException.java + src/share/classes/jdk/internal/org/xml/sax/XMLReader.java + src/share/classes/jdk/internal/org/xml/sax/helpers/DefaultHandler.java + src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java + src/share/classes/jdk/internal/util/xml/SAXParser.java + src/share/classes/jdk/internal/util/xml/XMLStreamException.java + src/share/classes/jdk/internal/util/xml/XMLStreamWriter.java + src/share/classes/jdk/internal/util/xml/impl/Attrs.java + src/share/classes/jdk/internal/util/xml/impl/Input.java + src/share/classes/jdk/internal/util/xml/impl/Pair.java + src/share/classes/jdk/internal/util/xml/impl/Parser.java + src/share/classes/jdk/internal/util/xml/impl/ParserSAX.java + src/share/classes/jdk/internal/util/xml/impl/ReaderUTF16.java + src/share/classes/jdk/internal/util/xml/impl/ReaderUTF8.java + src/share/classes/jdk/internal/util/xml/impl/SAXParserImpl.java + src/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java + src/share/classes/jdk/internal/util/xml/impl/XMLWriter.java Changeset: cf15abdcdf88 Author: alanb Date: 2012-12-19 14:53 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cf15abdcdf88 8005248: (props) Integrate small footprint parser into Properties Reviewed-by: joehw, mchung, psandoz, erikj ! make/jdk/Makefile - make/jdk/asm/Makefile ! src/share/classes/java/util/Properties.java + src/share/classes/jdk/internal/util/xml/BasicXmlPropertiesProvider.java ! test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/invalidxml/BadCase.xml + test/java/util/Properties/invalidxml/BadDocType.xml.excluded + test/java/util/Properties/invalidxml/NoClosingTag.xml + test/java/util/Properties/invalidxml/NoDocType.xml.excluded + test/java/util/Properties/invalidxml/NoRoot.xml + test/java/util/Properties/invalidxml/NotQuoted.xml + test/java/util/Properties/invalidxml/README.txt Changeset: 1f9c19741285 Author: darcy Date: 2012-12-19 11:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1f9c19741285 8005097: Tie isSynthetic javadoc to the JLS Reviewed-by: mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Member.java ! src/share/classes/java/lang/reflect/Method.java Changeset: b600d490dc57 Author: dsamersoff Date: 2012-12-20 16:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b600d490dc57 6783290: MBeanInfo/MBeanFeatureInfo has inconsistent readObject/writeObject Summary: call readObject in all cases Reviewed-by: emcmanus Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/MBeanFeatureInfo.java ! src/share/classes/javax/management/MBeanInfo.java Changeset: e43f90d5af11 Author: dsamersoff Date: 2012-12-20 16:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e43f90d5af11 6937053: RMI unmarshalling errors in ClientNotifForwarder cause silent failure Summary: the catch block in the fetchNotifs() method is extended to expect UnmarshalException Reviewed-by: emcmanus Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java Changeset: 3f014bc09297 Author: dsamersoff Date: 2012-12-20 17:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3f014bc09297 7009998: JMX synchronization during connection restart is faulty Summary: add a return statement after the re-connecting has finished and the state is CONNECTED Reviewed-by: sjiang Contributed-by: jaroslav.bachorik at oracle.com ! make/netbeans/jmx/build.properties ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java Changeset: d01a810798e0 Author: dl Date: 2012-12-20 13:44 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d01a810798e0 8002356: Add ForkJoin common pool and CountedCompleter Reviewed-by: chegar, mduigou ! make/java/java/FILES_java.gmk + src/share/classes/java/util/concurrent/CountedCompleter.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java Changeset: 31d2f9995d6c Author: chegar Date: 2012-12-20 15:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/31d2f9995d6c 8005306: Redundant cast warning in KeepAliveStream.java Reviewed-by: alanb ! src/share/classes/sun/net/www/http/KeepAliveStream.java Changeset: c1a55ee9618e Author: dsamersoff Date: 2012-12-20 20:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c1a55ee9618e 8005309: Missed tests for 6783290,6937053,7009998 Summary: Missed tests for 6783290,6937053,7009998 Reviewed-by: sjiang, emcmanus Contributed-by: jaroslav.bachorik at oracle.com + test/com/sun/jmx/remote/CCAdminReconnectTest.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Client/Client.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Client/ConfigKey.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Client/TestNotification.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/ConfigKey.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Server.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Ste.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/SteMBean.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/TestNotification.java + test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh + test/javax/management/MBeanInfo/SerializationTest1.java Changeset: edb71a37fcb7 Author: alanb Date: 2012-12-20 20:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/edb71a37fcb7 8001048: JSR-160: Allow IIOP transport to be optional Reviewed-by: dsamersoff, dfuchs, mchung ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/share/classes/javax/management/remote/JMXConnectorServerFactory.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/package.html ! test/javax/management/remote/mandatory/connection/AddressableTest.java ! test/javax/management/remote/mandatory/connection/CloseableTest.java ! test/javax/management/remote/mandatory/connection/ConnectionListenerNullTest.java ! test/javax/management/remote/mandatory/connection/IIOPURLTest.java ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java ! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java ! test/javax/management/remote/mandatory/connectorServer/SetMBeanServerForwarder.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/serverError/JMXServerErrorTest.java Changeset: eeda18683ddc Author: alanb Date: 2012-12-20 20:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eeda18683ddc 8005281: (props) loadFromXML/storeToXML with small parser is not thread safe Reviewed-by: mchung ! src/share/classes/jdk/internal/util/xml/BasicXmlPropertiesProvider.java + test/java/util/Properties/ConcurrentLoadAndStoreXML.java Changeset: 60adb69bf043 Author: smarks Date: 2012-12-20 20:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/60adb69bf043 8005290: remove -showversion from RMI test library subprocess mechanism Reviewed-by: jgish, chegar, dmocek ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java Changeset: 42ee6b6ad373 Author: jbachorik Date: 2012-12-21 09:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/42ee6b6ad373 7146162: javax/management/remote/mandatory/connection/BrokenConnectionTest.java failing intermittently Summary: ClientCommunicatorAdmin should call gotIOException((IOException)e) instead of restart((IOException)e) when detecting a communication error, because the method gotIOException will send a failure notification if necessary. Reviewed-by: emcmanus, sjiang Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java Changeset: 86c10d1484e9 Author: sjiang Date: 2012-12-21 10:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/86c10d1484e9 8005325: The script should use TESTVMOPTS Summary: Put back TESTVMOPTS which was removed by mistake. Reviewed-by: smarks ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: c1227b872a12 Author: joehw Date: 2012-12-21 17:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c1227b872a12 8005280: (props) Improve test coverage for small XML parser Summary: added a few more invalid XML files, international characters to LoadAndStore test, and a behavior compatibility test. Reviewed-by: alanb, lancea + test/java/util/Properties/Compatibility.xml + test/java/util/Properties/CompatibilityTest.java ! test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/invalidxml/BadDocType.xml - test/java/util/Properties/invalidxml/BadDocType.xml.excluded + test/java/util/Properties/invalidxml/DTDRootNotMatch.xml + test/java/util/Properties/invalidxml/IllegalComment.xml + test/java/util/Properties/invalidxml/IllegalEntry.xml + test/java/util/Properties/invalidxml/IllegalEntry1.xml + test/java/util/Properties/invalidxml/IllegalKeyAttribute.xml + test/java/util/Properties/invalidxml/NoDocType.xml - test/java/util/Properties/invalidxml/NoDocType.xml.excluded + test/java/util/Properties/invalidxml/NoNamespaceSupport.xml Changeset: 4d28776d7007 Author: mullan Date: 2012-12-26 10:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4d28776d7007 8005117: Eliminate dependency from ConfigSpiFile to com.sun.security.auth.login.ConfigFile Reviewed-by: alanb, mchung, weijun ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/sun/security/provider/ConfigSpiFile.java Changeset: d9cab18f326a Author: mullan Date: 2012-12-26 10:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d9cab18f326a Merge - make/jdk/asm/Makefile Changeset: 9d984ccd17fc Author: chegar Date: 2012-12-27 21:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9d984ccd17fc 8003981: Support Parallel Array Sorting - JEP 103 Reviewed-by: chegar, forax, dholmes, dl Contributed-by: david.holmes at oracle.com, dl at cs.oswego.edu, chris.hegarty at oracle.com ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/Arrays.java + src/share/classes/java/util/ArraysParallelSortHelpers.java + test/java/util/Arrays/ParallelSorting.java Changeset: 4ad38db38fff Author: okutsu Date: 2012-12-28 14:13 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4ad38db38fff 8005471: DateFormat: Time zone info is not localized when adapter is CLDR Reviewed-by: peytoia ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java + test/java/util/TimeZone/CLDRDisplayNamesTest.java Changeset: 1da019e7999a Author: peytoia Date: 2012-12-28 15:07 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1da019e7999a 8005277: Regression in JDK 7 in Bidi implementation Reviewed-by: okutsu ! src/share/classes/sun/text/bidi/BidiBase.java ! test/java/text/Bidi/BidiConformance.java + test/java/text/Bidi/Bug8005277.java Changeset: f3ac419e2bf0 Author: okutsu Date: 2012-12-28 16:39 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f3ac419e2bf0 8005561: typo in Calendar Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java Changeset: 645d774b683a Author: xuelei Date: 2012-12-28 00:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/645d774b683a 7109274: Restrict the use of certificates with RSA keys less than 1024 bits Summary: This restriction is applied via the Java Security property, "jdk.certpath.disabledAlgorithms". This will impact providers that adhere to this security property. Reviewed-by: mullan ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java ! test/java/security/cert/pkix/policyChanges/TestPolicy.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java + test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh Changeset: 4472a641b4dc Author: xuelei Date: 2012-12-28 03:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4472a641b4dc 8003265: Need to clone array of input/output parameters Reviewed-by: mullan ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: 46675076f753 Author: sjiang Date: 2012-12-28 16:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/46675076f753 7120365: DiffHBTest.java fails due to ConcurrentModificationException Summary: The problem is from the server notification forwarder, it should use a copy of listener set to do iterate. Reviewed-by: alanb ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! test/ProblemList.txt + test/javax/management/remote/mandatory/notif/ConcurrentModificationTest.java Changeset: 0cfcba56cfa7 Author: jgish Date: 2012-12-28 18:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0cfcba56cfa7 8005594: Fix to 8003265 breaks build Summary: backout changeset 4472a641b4dc Reviewed-by: smarks, wetmore ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: ac5e29b62288 Author: smarks Date: 2012-12-28 17:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ac5e29b62288 Merge Changeset: 2a5af0f766d0 Author: lana Date: 2012-12-28 18:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2a5af0f766d0 Merge - make/jdk/asm/Makefile ! makefiles/CreateJars.gmk ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: 32a57e645e01 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/32a57e645e01 Added tag jdk8-b71 for changeset 2a5af0f766d0 ! .hgtags From john.coomes at oracle.com Thu Jan 3 22:10:31 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 06:10:31 +0000 Subject: hg: hsx/hotspot-rt/langtools: 20 new changesets Message-ID: <20130104061123.1BADE47545@hg.openjdk.java.net> Changeset: 37a5d7eccb87 Author: vromero Date: 2012-12-14 11:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/37a5d7eccb87 8004976: test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java can fail Reviewed-by: jjg, mcimadamore ! test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java Changeset: de1ec6fc93fe Author: vromero Date: 2012-12-15 13:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/de1ec6fc93fe 8000518: Javac generates duplicate name_and_type constant pool entry for class BinaryOpValueExp.java Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.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/Pool.java ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java + test/tools/javac/8000518/DuplicateConstantPoolEntry.java ! test/tools/javac/lambda/TestInvokeDynamic.java Changeset: f72dc656a306 Author: lana Date: 2012-12-16 22:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f72dc656a306 Merge Changeset: 02a18f209ab3 Author: vromero Date: 2012-12-17 14:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/02a18f209ab3 8004814: javadoc should be able to detect default methods Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/javadoc/ClassDoc.java ! src/share/classes/com/sun/javadoc/MethodDoc.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java Changeset: 75ab654b5cd5 Author: jjg Date: 2012-12-17 07:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/75ab654b5cd5 8004832: Add new doclint package Reviewed-by: mcimadamore ! make/build.properties ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/TreePath.java + src/share/classes/com/sun/tools/doclint/Checker.java + src/share/classes/com/sun/tools/doclint/DocLint.java + src/share/classes/com/sun/tools/doclint/Entity.java + src/share/classes/com/sun/tools/doclint/Env.java + src/share/classes/com/sun/tools/doclint/HtmlTag.java + src/share/classes/com/sun/tools/doclint/Messages.java + src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/share/classes/com/sun/tools/javac/tree/DocPretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/doclint/AccessTest.java + test/tools/doclint/AccessTest.package.out + test/tools/doclint/AccessTest.private.out + test/tools/doclint/AccessTest.protected.out + test/tools/doclint/AccessTest.public.out + test/tools/doclint/AccessibilityTest.java + test/tools/doclint/AccessibilityTest.out + test/tools/doclint/DocLintTester.java + test/tools/doclint/EmptyAuthorTest.java + test/tools/doclint/EmptyAuthorTest.out + test/tools/doclint/EmptyExceptionTest.java + test/tools/doclint/EmptyExceptionTest.out + test/tools/doclint/EmptyParamTest.java + test/tools/doclint/EmptyParamTest.out + test/tools/doclint/EmptyReturnTest.java + test/tools/doclint/EmptyReturnTest.out + test/tools/doclint/EmptySerialDataTest.java + test/tools/doclint/EmptySerialDataTest.out + test/tools/doclint/EmptySerialFieldTest.java + test/tools/doclint/EmptySerialFieldTest.out + test/tools/doclint/EmptySinceTest.java + test/tools/doclint/EmptySinceTest.out + test/tools/doclint/EmptyVersionTest.java + test/tools/doclint/EmptyVersionTest.out + test/tools/doclint/HtmlAttrsTest.java + test/tools/doclint/HtmlAttrsTest.out + test/tools/doclint/HtmlTagsTest.java + test/tools/doclint/HtmlTagsTest.out + test/tools/doclint/MissingCommentTest.java + test/tools/doclint/MissingCommentTest.out + test/tools/doclint/MissingParamsTest.java + test/tools/doclint/MissingParamsTest.out + test/tools/doclint/MissingReturnTest.java + test/tools/doclint/MissingReturnTest.out + test/tools/doclint/MissingThrowsTest.java + test/tools/doclint/MissingThrowsTest.out + test/tools/doclint/OptionTest.java + test/tools/doclint/OverridesTest.java + test/tools/doclint/ReferenceTest.java + test/tools/doclint/ReferenceTest.out + test/tools/doclint/RunTest.java + test/tools/doclint/SyntaxTest.java + test/tools/doclint/SyntaxTest.out + test/tools/doclint/SyntheticTest.java + test/tools/doclint/ValidTest.java + test/tools/doclint/tidy/AnchorAlreadyDefined.java + test/tools/doclint/tidy/AnchorAlreadyDefined.out + test/tools/doclint/tidy/BadEnd.java + test/tools/doclint/tidy/BadEnd.out + test/tools/doclint/tidy/InsertImplicit.java + test/tools/doclint/tidy/InsertImplicit.out + test/tools/doclint/tidy/InvalidEntity.java + test/tools/doclint/tidy/InvalidEntity.out + test/tools/doclint/tidy/InvalidName.java + test/tools/doclint/tidy/InvalidName.out + test/tools/doclint/tidy/InvalidTag.java + test/tools/doclint/tidy/InvalidTag.out + test/tools/doclint/tidy/InvalidURI.java + test/tools/doclint/tidy/InvalidURI.out + test/tools/doclint/tidy/MissingGT.java + test/tools/doclint/tidy/MissingGT.out + test/tools/doclint/tidy/MissingTag.java + test/tools/doclint/tidy/MissingTag.out + test/tools/doclint/tidy/NestedTag.java + test/tools/doclint/tidy/NestedTag.out + test/tools/doclint/tidy/ParaInPre.java + test/tools/doclint/tidy/ParaInPre.out + test/tools/doclint/tidy/README.txt + test/tools/doclint/tidy/RepeatedAttr.java + test/tools/doclint/tidy/RepeatedAttr.out + test/tools/doclint/tidy/TextNotAllowed.java + test/tools/doclint/tidy/TextNotAllowed.out + test/tools/doclint/tidy/TrimmingEmptyTag.java + test/tools/doclint/tidy/TrimmingEmptyTag.out + test/tools/doclint/tidy/UnescapedOrUnknownEntity.java + test/tools/doclint/tidy/UnescapedOrUnknownEntity.out + test/tools/doclint/tidy/util/Main.java + test/tools/doclint/tidy/util/tidy.sh + test/tools/javac/diags/examples/NoContent.java Changeset: f20568328a57 Author: mcimadamore Date: 2012-12-17 16:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f20568328a57 8004099: Bad compiler diagnostic generated when poly expression is passed to non-existent method Summary: Some code paths in resolve do not use methodArguments to correctly format actuals Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/BadMethodCall2.java + test/tools/javac/lambda/BadMethodCall2.out Changeset: 064e372f273d Author: jjg Date: 2012-12-17 10:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/064e372f273d 8004961: rename Plugin.call to Plugin.init Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! test/tools/javac/plugin/showtype/ShowTypePlugin.java ! test/tools/javac/plugin/showtype/Test.java Changeset: ef537bcc825a Author: mchung Date: 2012-12-17 15:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/ef537bcc825a 8005137: Rename DocLint.call to DocLint.init which overrides Plugin.init Reviewed-by: darcy, jjh ! src/share/classes/com/sun/tools/doclint/DocLint.java Changeset: bc74006c2d8d Author: darcy Date: 2012-12-18 00:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/bc74006c2d8d 8005046: Provide checking for a default method in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java + test/tools/javac/processing/model/element/TestExecutableElement.java Changeset: 92fcf299cd09 Author: ohrstrom Date: 2012-12-18 10:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/92fcf299cd09 8004657: Add hooks to javac to enable reporting dependency information. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 250f0acf880c Author: mcimadamore Date: 2012-12-18 22:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/250f0acf880c 8005193: New regression test test/tools/javac/lambda/BadMethodCall2.java fails Summary: Bad golden file in negative test Reviewed-by: jjh ! test/tools/javac/lambda/BadMethodCall2.out Changeset: 573b38691a74 Author: lana Date: 2012-12-18 18:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/573b38691a74 Merge Changeset: 67b01d295cd2 Author: jjg Date: 2012-12-19 11:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/67b01d295cd2 8004833: Integrate doclint support into javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/doclint/DocLintTest.java Changeset: f72c9c5aeaef Author: jfranck Date: 2012-12-16 11:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f72c9c5aeaef 8005098: Provide isSynthesized() information on Attribute.Compound Reviewed-by: jjg ! make/build.properties ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java Changeset: a22f23fb7abf Author: jjg Date: 2012-12-20 17:59 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a22f23fb7abf 8005307: fix missing @bug tags Reviewed-by: jjh ! test/tools/doclint/AccessTest.java ! test/tools/doclint/AccessTest.package.out ! test/tools/doclint/AccessTest.private.out ! test/tools/doclint/AccessTest.protected.out ! test/tools/doclint/AccessTest.public.out ! test/tools/doclint/AccessibilityTest.java ! test/tools/doclint/AccessibilityTest.out ! test/tools/doclint/EmptyAuthorTest.java ! test/tools/doclint/EmptyAuthorTest.out ! test/tools/doclint/EmptyExceptionTest.java ! test/tools/doclint/EmptyExceptionTest.out ! test/tools/doclint/EmptyParamTest.java ! test/tools/doclint/EmptyParamTest.out ! test/tools/doclint/EmptyReturnTest.java ! test/tools/doclint/EmptyReturnTest.out ! test/tools/doclint/EmptySerialDataTest.java ! test/tools/doclint/EmptySerialDataTest.out ! test/tools/doclint/EmptySerialFieldTest.java ! test/tools/doclint/EmptySerialFieldTest.out ! test/tools/doclint/EmptySinceTest.java ! test/tools/doclint/EmptySinceTest.out ! test/tools/doclint/EmptyVersionTest.java ! test/tools/doclint/EmptyVersionTest.out ! test/tools/doclint/HtmlAttrsTest.java ! test/tools/doclint/HtmlAttrsTest.out ! test/tools/doclint/HtmlTagsTest.java ! test/tools/doclint/HtmlTagsTest.out ! test/tools/doclint/MissingParamsTest.java ! test/tools/doclint/MissingParamsTest.out ! test/tools/doclint/MissingReturnTest.java ! test/tools/doclint/MissingReturnTest.out ! test/tools/doclint/MissingThrowsTest.java ! test/tools/doclint/MissingThrowsTest.out ! test/tools/doclint/OptionTest.java ! test/tools/doclint/OverridesTest.java ! test/tools/doclint/ReferenceTest.java ! test/tools/doclint/ReferenceTest.out ! test/tools/doclint/RunTest.java ! test/tools/doclint/SyntaxTest.java ! test/tools/doclint/SyntaxTest.out ! test/tools/doclint/SyntheticTest.java ! test/tools/doclint/ValidTest.java ! test/tools/doclint/tidy/AnchorAlreadyDefined.java ! test/tools/doclint/tidy/AnchorAlreadyDefined.out ! test/tools/doclint/tidy/BadEnd.java ! test/tools/doclint/tidy/BadEnd.out ! test/tools/doclint/tidy/InsertImplicit.java ! test/tools/doclint/tidy/InsertImplicit.out ! test/tools/doclint/tidy/InvalidEntity.java ! test/tools/doclint/tidy/InvalidEntity.out ! test/tools/doclint/tidy/InvalidName.java ! test/tools/doclint/tidy/InvalidName.out ! test/tools/doclint/tidy/InvalidTag.java ! test/tools/doclint/tidy/InvalidTag.out ! test/tools/doclint/tidy/InvalidURI.java ! test/tools/doclint/tidy/InvalidURI.out ! test/tools/doclint/tidy/MissingGT.java ! test/tools/doclint/tidy/MissingGT.out ! test/tools/doclint/tidy/MissingTag.java ! test/tools/doclint/tidy/MissingTag.out ! test/tools/doclint/tidy/NestedTag.java ! test/tools/doclint/tidy/NestedTag.out ! test/tools/doclint/tidy/ParaInPre.java ! test/tools/doclint/tidy/ParaInPre.out ! test/tools/doclint/tidy/RepeatedAttr.java ! test/tools/doclint/tidy/RepeatedAttr.out ! test/tools/doclint/tidy/TextNotAllowed.java ! test/tools/doclint/tidy/TextNotAllowed.out ! test/tools/doclint/tidy/TrimmingEmptyTag.java ! test/tools/doclint/tidy/TrimmingEmptyTag.out ! test/tools/doclint/tidy/UnescapedOrUnknownEntity.java ! test/tools/doclint/tidy/UnescapedOrUnknownEntity.out Changeset: b52a38d4536c Author: darcy Date: 2012-12-21 08:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b52a38d4536c 8005282: Use @library tag with non-relative path for javac tests Reviewed-by: jjg ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/classreader/T7031108.java ! test/tools/javac/enum/6350057/T6350057.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/file/T7018098.java ! test/tools/javac/multicatch/model/ModelChecker.java ! test/tools/javac/options/T7022337.java ! test/tools/javac/processing/6348499/T6348499.java ! test/tools/javac/processing/6359313/T6359313.java ! test/tools/javac/processing/6365040/T6365040.java ! test/tools/javac/processing/6413690/T6413690.java ! test/tools/javac/processing/6414633/T6414633.java ! test/tools/javac/processing/6430209/T6430209.java ! test/tools/javac/processing/6499119/ClassProcessor.java ! test/tools/javac/processing/6511613/clss41701.java ! test/tools/javac/processing/6512707/T6512707.java ! test/tools/javac/processing/6634138/T6634138.java ! test/tools/javac/processing/6994946/SemanticErrorTest.java ! test/tools/javac/processing/6994946/SyntaxErrorTest.java ! test/tools/javac/processing/T6920317.java ! test/tools/javac/processing/T7196462.java ! test/tools/javac/processing/TestWarnErrorCount.java ! test/tools/javac/processing/environment/TestSourceVersion.java ! test/tools/javac/processing/environment/round/TestContext.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/tools/javac/processing/errors/TestErrorCount.java ! test/tools/javac/processing/errors/TestFatalityOfParseErrors.java ! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java ! test/tools/javac/processing/errors/TestParseErrors/TestParseErrors.java ! test/tools/javac/processing/errors/TestReturnCode.java ! test/tools/javac/processing/filer/TestFilerConstraints.java ! test/tools/javac/processing/filer/TestGetResource.java ! test/tools/javac/processing/filer/TestGetResource2.java ! test/tools/javac/processing/filer/TestInvalidRelativeNames.java ! test/tools/javac/processing/filer/TestLastRound.java ! test/tools/javac/processing/filer/TestPackageInfo.java ! test/tools/javac/processing/filer/TestValidRelativeNames.java ! test/tools/javac/processing/messager/6362067/T6362067.java ! test/tools/javac/processing/messager/MessagerBasics.java ! test/tools/javac/processing/model/6194785/T6194785.java ! test/tools/javac/processing/model/6341534/T6341534.java ! test/tools/javac/processing/model/element/TestAnonClassNames.java ! test/tools/javac/processing/model/element/TestElement.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingClass.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericClass1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericClass2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingInterface.java ! test/tools/javac/processing/model/element/TestNames.java ! test/tools/javac/processing/model/element/TestPackageElement.java ! test/tools/javac/processing/model/element/TestResourceElement.java ! test/tools/javac/processing/model/element/TestResourceVariable.java ! test/tools/javac/processing/model/element/TestTypeParameter.java ! test/tools/javac/processing/model/element/TypeParamBounds.java ! test/tools/javac/processing/model/type/MirroredTypeEx/OverEager.java ! test/tools/javac/processing/model/type/MirroredTypeEx/Plurality.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/model/type/TestUnionType.java ! test/tools/javac/processing/model/util/BinaryName.java ! test/tools/javac/processing/model/util/GetTypeElemBadArg.java ! test/tools/javac/processing/model/util/NoSupers.java ! test/tools/javac/processing/model/util/OverridesSpecEx.java ! test/tools/javac/processing/model/util/TypesBadArg.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java ! test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java ! test/tools/javac/processing/model/util/elements/TestGetPackageOf.java ! test/tools/javac/processing/model/util/filter/TestIterables.java ! test/tools/javac/processing/options/testCommandLineClasses/Test.java ! test/tools/javac/processing/options/testPrintProcessorInfo/Test.java ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java ! test/tools/javac/processing/warnings/UseImplicit/TestProcUseImplicitWarning.java ! test/tools/javac/processing/werror/WError1.java ! test/tools/javac/processing/werror/WErrorGen.java ! test/tools/javac/processing/werror/WErrorLast.java ! test/tools/javac/resolve/ResolveHarness.java ! test/tools/javac/util/T6597678.java ! test/tools/javac/util/context/T7021650.java Changeset: 189b26e3818f Author: vromero Date: 2012-12-21 15:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/189b26e3818f 8003512: javac doesn't work with jar files with >64k entries Reviewed-by: jjg, ksrini Contributed-by: martinrb at google.com ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java + test/tools/javac/file/zip/8003512/LoadClassFromJava6CreatedJarTest.java ! test/tools/javac/file/zip/Utils.java Changeset: 690c41cdab55 Author: bpatel Date: 2012-12-25 17:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/690c41cdab55 8004893: the javadoc/doclet needs to be updated to accommodate lambda changes Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodTypes.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java + test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java + test/com/sun/javadoc/testLambdaFeature/pkg/A.java + test/com/sun/javadoc/testLambdaFeature/pkg/B.java ! test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java Changeset: 467e4d9281bc Author: lana Date: 2012-12-28 18:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/467e4d9281bc Merge ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 6f0986ed9b7e Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6f0986ed9b7e Added tag jdk8-b71 for changeset 467e4d9281bc ! .hgtags From chris.hegarty at oracle.com Fri Jan 4 03:25:38 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 04 Jan 2013 11:25:38 +0000 Subject: hg: jdk8/tl/jdk: 8005659: Add tools/pack200/AttributeTests.java to exclude list (ProblemList.txt) until pack200 updated to support method parameters Message-ID: <20130104112631.13C8B47551@hg.openjdk.java.net> Changeset: 438d37d16417 Author: chegar Date: 2013-01-04 11:18 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/438d37d16417 8005659: Add tools/pack200/AttributeTests.java to exclude list (ProblemList.txt) until pack200 updated to support method parameters Reviewed-by: mchung, ksrini ! test/ProblemList.txt From chris.hegarty at oracle.com Fri Jan 4 03:35:55 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 04 Jan 2013 11:35:55 +0000 Subject: hg: jdk8/tl/jdk: 8005638: Less secure Authentication schemes should work when more secure schemes are not available Message-ID: <20130104113607.6248D47552@hg.openjdk.java.net> Changeset: 6d814b2f9112 Author: chegar Date: 2013-01-04 11:34 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d814b2f9112 8005638: Less secure Authentication schemes should work when more secure schemes are not available Reviewed-by: alanb ! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java From kelly.ohair at oracle.com Fri Jan 4 14:37:46 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 4 Jan 2013 14:37:46 -0800 Subject: [PATCH] JDK-8005472: com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh failed on windows In-Reply-To: <50E16BA8.40203@oracle.com> References: <50E16BA8.40203@oracle.com> Message-ID: <682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com> On Dec 31, 2012, at 2:40 AM, Jaroslav Bachorik wrote: > Looking for a review and a sponsor. > > Webrev at: > http://cr.openjdk.java.net/~jbachorik/8005472/webrev.00/test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh.sdiff.html > > JPRT run on windows targets: > http://sthjprt.se.oracle.com/archives/2012/12/2012-12-28-123054.jbachorik.openjdk8-tl//JobStatus.txt > > The issue is about a new test failing when run on windows machines. It > seems that the cygwin really does not like removing a non-existent file > - to the extent of hanging the script indefinitely. I suspect it is not hanging because it does not exist, but that some other windows process has it's hands on it. This is the stdout file from the server being started up right? Could the server from a previous test run be still running? Maybe a better answer might be to make the filename a bit more unique, like maybe foobar.$$ ??? > > The patch adds a pre-check for the existence of the file to be removed. > It does not change the test in any other way. This test doesn't make much sense to me. rm should never hang on a non existent file. And by the way, it might be a good idea for scripts to always use 'rm -f', which is what the default is for Makefiles with $(RM) -kto > > > Thanks, > > -JB- From jon.masamitsu at oracle.com Fri Jan 4 14:41:12 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 04 Jan 2013 14:41:12 -0800 Subject: request for review - 8004172: Remove display of permanent generation counters from jstat options Message-ID: <50E75A88.1020205@oracle.com> 8004172: Remove display of permanent generation counters from jstat options This change removes from the jstat options the display of permanent generation counters. It also removes entirely the gcpermcapacity option. http://cr.openjdk.java.net/~jmasa/8004172/webrev.00/ The permanent generation has been removed from the hotspot VM. The jstat counters for the permanent generation will be removed. This change is in preparation for that removal. From stuart.marks at oracle.com Fri Jan 4 16:17:57 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Sat, 05 Jan 2013 00:17:57 +0000 Subject: hg: jdk8/tl/jdk: 8005683: ProblemList.txt updates (01/2013) Message-ID: <20130105001818.60DFF4756A@hg.openjdk.java.net> Changeset: 92c3b24a8e9a Author: smarks Date: 2013-01-04 16:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92c3b24a8e9a 8005683: ProblemList.txt updates (01/2013) Reviewed-by: mchung, alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt From bhavesh.x.patel at oracle.com Fri Jan 4 23:07:57 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Sat, 05 Jan 2013 07:07:57 +0000 Subject: hg: jdk8/tl/langtools: 8004891: Check for abstract method in javadoc does not conform to the language model Message-ID: <20130105070802.29B1847575@hg.openjdk.java.net> Changeset: 0e17c3c23e3b Author: bpatel Date: 2013-01-04 23:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0e17c3c23e3b 8004891: Check for abstract method in javadoc does not conform to the language model Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java + test/com/sun/javadoc/testAbstractMethod/TestAbstractMethod.java + test/com/sun/javadoc/testAbstractMethod/pkg/A.java + test/com/sun/javadoc/testAbstractMethod/pkg/B.java + test/com/sun/javadoc/testAbstractMethod/pkg/C.java From bhavesh.x.patel at oracle.com Sat Jan 5 00:56:51 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Sat, 05 Jan 2013 08:56:51 +0000 Subject: hg: jdk8/tl/langtools: 8005092: javadoc should check for synthesized bit on an annotation Message-ID: <20130105085653.85E6B47578@hg.openjdk.java.net> Changeset: 8c0c63a6e3b7 Author: bpatel Date: 2013-01-05 00:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8c0c63a6e3b7 8005092: javadoc should check for synthesized bit on an annotation Reviewed-by: jjg ! src/share/classes/com/sun/javadoc/AnnotationDesc.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java + test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/C.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeRegDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeSynthDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerSynthDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/D.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/NonSynthDocContainer.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegArryDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/C.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeSynthDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerSynthNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValNotDoc.java From chris.hegarty at oracle.com Sat Jan 5 09:08:28 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 05 Jan 2013 17:08:28 +0000 Subject: hg: jdk8/tl/jdk: 8005709: Add at since tags to new FJP getCommonPoolParallelism and commonPool Message-ID: <20130105170901.C712947579@hg.openjdk.java.net> Changeset: 0c89465b656a Author: chegar Date: 2013-01-05 17:06 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c89465b656a 8005709: Add at since tags to new FJP getCommonPoolParallelism and commonPool Reviewed-by: dl ! src/share/classes/java/util/concurrent/ForkJoinPool.java From jaroslav.bachorik at oracle.com Mon Jan 7 03:23:00 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Jan 2013 12:23:00 +0100 Subject: [PATCH] JDK-8005472: com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh failed on windows In-Reply-To: <682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com> References: <50E16BA8.40203@oracle.com> <682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com> Message-ID: <50EAB014.30805@oracle.com> On 01/04/2013 11:37 PM, Kelly O'Hair wrote: > > On Dec 31, 2012, at 2:40 AM, Jaroslav Bachorik wrote: > >> Looking for a review and a sponsor. >> >> Webrev at: >> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.00/test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh.sdiff.html >> >> JPRT run on windows targets: >> http://sthjprt.se.oracle.com/archives/2012/12/2012-12-28-123054.jbachorik.openjdk8-tl//JobStatus.txt >> >> The issue is about a new test failing when run on windows machines. It >> seems that the cygwin really does not like removing a non-existent file >> - to the extent of hanging the script indefinitely. > > I suspect it is not hanging because it does not exist, but that some other windows process has it's hands on it. > This is the stdout file from the server being started up right? > Could the server from a previous test run be still running? Exactly. Amy confirmed this and provided a patch which resolves the hanging problem. The update patch is at http://cr.openjdk.java.net/~jbachorik/8005472/webrev.01 -JB- > > Maybe a better answer might be to make the filename a bit more unique, like maybe foobar.$$ ??? > >> >> The patch adds a pre-check for the existence of the file to be removed. >> It does not change the test in any other way. > > This test doesn't make much sense to me. rm should never hang on a non existent file. > > And by the way, it might be a good idea for scripts to always use 'rm -f', which is what the default is for Makefiles with $(RM) > > > -kto > >> >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Mon Jan 7 04:56:46 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 7 Jan 2013 13:56:46 +0100 Subject: request for review - 8004172: Remove display of permanent generation counters from jstat options In-Reply-To: <50E75A88.1020205@oracle.com> References: <50E75A88.1020205@oracle.com> Message-ID: <5D1B5FF4-6A7A-4CBE-B78E-CB972800F3B6@oracle.com> Looks good to me! Thanks for fixing. On 4 jan 2013, at 23:41, Jon Masamitsu wrote: > 8004172: Remove display of permanent generation counters from jstat options > > This change removes from the jstat options the display of > permanent generation counters. It also removes entirely the > gcpermcapacity option. > > http://cr.openjdk.java.net/~jmasa/8004172/webrev.00/ > > The permanent generation has been removed from the hotspot VM. > The jstat counters for the permanent generation will be removed. > This change is in preparation for that removal. From jaroslav.bachorik at oracle.com Mon Jan 7 05:44:03 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Jan 2013 14:44:03 +0100 Subject: [PATCH] JDK-8005791: Remove java.beans.* imports from com.sun.jmx.mbeanserver.Introspector Message-ID: <50EAD123.7040202@oracle.com> Looking for reviewers and a sponsor. This is a simple patch to remove unused java.beans.* imports from com.sun.jmx.mbeanserver.Introspector. The actual usage of java.beans.* classes was removed from the Introspector only the imports are left dangling. The webrev is at http://cr.openjdk.java.net/~jbachorik/8005791/webrev.00/ Thanks, -JB- From kumar.x.srinivasan at oracle.com Mon Jan 7 11:10:25 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 07 Jan 2013 19:10:25 +0000 Subject: hg: jdk8/tl/jdk: 8004547: Extend JavaFX launcher support to allow full JavaFX launch feature set Message-ID: <20130107191053.8A920470C0@hg.openjdk.java.net> Changeset: 1d9638ba5202 Author: ksrini Date: 2013-01-07 09:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d9638ba5202 8004547: Extend JavaFX launcher support to allow full JavaFX launch feature set Reviewed-by: mchung, kcr, ksrini Contributed-by: david.dehaven at oracle.com ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! test/tools/launcher/FXLauncherTest.java From james.holmlund at oracle.com Mon Jan 7 13:12:56 2013 From: james.holmlund at oracle.com (james.holmlund at oracle.com) Date: Mon, 07 Jan 2013 21:12:56 +0000 Subject: hg: jdk8/tl/langtools: 8005647: langtools/test/tools/javap/MethodParameters.java fails on windows Message-ID: <20130107211301.D1DD5470C7@hg.openjdk.java.net> Changeset: a9cb93cca229 Author: jjh Date: 2013-01-07 17:51 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a9cb93cca229 8005647: langtools/test/tools/javap/MethodParameters.java fails on windows Summary: Fix javap to not output \r\r\n Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! test/tools/javac/MethodParameters.java ! test/tools/javap/MethodParameters.java From naoto.sato at oracle.com Mon Jan 7 13:19:36 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 07 Jan 2013 21:19:36 +0000 Subject: hg: jdk8/tl/jdk: 8003228: (props) sun.jnu.encoding should be set to UTF-8 [macosx] Message-ID: <20130107211949.6CCF7470C8@hg.openjdk.java.net> Changeset: dbc692ea3f0a Author: bchristi Date: 2013-01-07 13:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dbc692ea3f0a 8003228: (props) sun.jnu.encoding should be set to UTF-8 [macosx] Summary: Hard-code sun.jnu.encoding to UTF-8 on Mac Reviewed-by: naoto ! src/share/native/java/lang/System.c ! src/solaris/native/java/lang/java_props_md.c + test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java + test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh From stuart.marks at oracle.com Mon Jan 7 18:10:15 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 08 Jan 2013 02:10:15 +0000 Subject: hg: jdk8/tl/jdk: 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently Message-ID: <20130108021026.D017E470D5@hg.openjdk.java.net> Changeset: 797e8a3dcd51 Author: smarks Date: 2013-01-07 18:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/797e8a3dcd51 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently Summary: Tighten up JavaVM test library API, and adjust tests to match. Reviewed-by: mchung, dmocek ! test/ProblemList.txt ! test/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/java/rmi/registry/checkusage/CheckUsage.java ! test/java/rmi/registry/reexport/Reexport.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/RMID.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java ! test/sun/rmi/runtime/Log/4504153/Test4504153.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/rmi/transport/tcp/DeadCachedConnection.java From weijun.wang at oracle.com Mon Jan 7 22:55:23 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 08 Jan 2013 06:55:23 +0000 Subject: hg: jdk8/tl/jdk: 8005447: default principal should act as anyone Message-ID: <20130108065534.EDCB5470DC@hg.openjdk.java.net> Changeset: 98935c514de4 Author: weijun Date: 2013-01-08 14:54 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98935c514de4 8005447: default principal should act as anyone Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java + src/share/classes/sun/security/jgss/krb5/ServiceCreds.java ! src/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java + test/sun/security/krb5/ServiceCredsCombination.java + test/sun/security/krb5/auto/AcceptPermissions.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/DiffNameSameKey.java ! test/sun/security/krb5/auto/DynamicKeytab.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/KeyTabCompat.java + test/sun/security/krb5/auto/TwoOrThree.java From maurizio.cimadamore at oracle.com Tue Jan 8 01:18:38 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 08 Jan 2013 09:18:38 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130108091845.95809470E1@hg.openjdk.java.net> Changeset: 38d3d1027f5a Author: mcimadamore Date: 2013-01-08 10:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/38d3d1027f5a 8005243: Restructure method check code to allow pluggable checkers Summary: Add interface to perform a method check - to be implemented by helper classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: db91d860156a Author: mcimadamore Date: 2013-01-08 10:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/db91d860156a 8005179: Cleanup Resolve.AmbiguityError Summary: Linearize nested ambiguity errors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/lambda/TargetType21.java ! test/tools/javac/lambda/TargetType21.out Changeset: d07340b61e6a Author: mcimadamore Date: 2013-01-08 10:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d07340b61e6a 8005184: Restructure DeferredAttr to allow pluggable deferred type completers Summary: Add hooks to generalize deferred type completion via custom helper objects Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java From rickard.backman at oracle.com Tue Jan 8 04:14:19 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Tue, 8 Jan 2013 13:14:19 +0100 Subject: [PATCH] JDK-8005791: Remove java.beans.* imports from com.sun.jmx.mbeanserver.Introspector In-Reply-To: <50EAD123.7040202@oracle.com> References: <50EAD123.7040202@oracle.com> Message-ID: <1A3E8969-FE69-442D-8246-79986E494AE7@oracle.com> Jaroslav, the change looks good! /R On Jan 7, 2013, at 2:44 PM, Jaroslav Bachorik wrote: > Looking for reviewers and a sponsor. > > This is a simple patch to remove unused java.beans.* imports from > com.sun.jmx.mbeanserver.Introspector. The actual usage of java.beans.* > classes was removed from the Introspector only the imports are left > dangling. > > The webrev is at http://cr.openjdk.java.net/~jbachorik/8005791/webrev.00/ > > Thanks, > > -JB- From vicente.romero at oracle.com Tue Jan 8 05:53:40 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 08 Jan 2013 13:53:40 +0000 Subject: hg: jdk8/tl/langtools: 8005167: execution time of combo tests in javac should be improved Message-ID: <20130108135342.EC5A5470EC@hg.openjdk.java.net> Changeset: 954541f13717 Author: vromero Date: 2013-01-08 13:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/954541f13717 8005167: execution time of combo tests in javac should be improved Reviewed-by: jjg, jjh ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/T7093325.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java ! test/tools/javac/lambda/LambdaParserTest.java ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java ! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java + test/tools/javac/lib/JavacTestingAbstractThreadedTest.java ! test/tools/javac/multicatch/7030606/DisjunctiveTypeWellFormednessTest.java ! test/tools/javac/varargs/7042566/T7042566.java ! test/tools/javac/varargs/warning/Warn4.java ! test/tools/javac/varargs/warning/Warn5.java From jaroslav.bachorik at oracle.com Tue Jan 8 07:16:32 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 08 Jan 2013 16:16:32 +0100 Subject: [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure Message-ID: <50EC3850.7080508@oracle.com> Looking for review and a sponsor. Webrev at http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 In this issue the timing is the problem. MBeanServer.unregisterMBean() fires the "unregister" notification which is sent to the server asynchronously. Thus it may happen that the "unregister" notification has not been yet processed at the time of invoking removeNotificationListener() and the notification listeners hasn't been cleaned up leading to the test failure. There is no synchronization between the client and the server and such race condition can occur occasionally. Normally, the execution is fast enough to behave like the "unregister" notification is processed synchronously with the unregisterMBean() operation but it seems that using fastdebug Server VM bits with the -Xcomp option strains the CPU enough to make this problem appear. There is no proper fix for this - the only thing that work is waiting a bit longer in the main thread to give the notification processing thread some time to clean up the listeners. Regards, -JB- From harold.seigel at oracle.com Tue Jan 8 07:43:47 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 08 Jan 2013 15:43:47 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8003705: CDS failed on Windows: can not map in the CDS. Message-ID: <20130108154356.BE9EC470F5@hg.openjdk.java.net> Changeset: 6c3f47d964f3 Author: hseigel Date: 2013-01-07 15:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6c3f47d964f3 8003705: CDS failed on Windows: can not map in the CDS. Summary: Map memory only once to prevent 'already mapped' failures. Reviewed-by: acorn, zgu ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspaceShared.cpp From mikael.vidstedt at oracle.com Tue Jan 8 09:50:22 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 08 Jan 2013 09:50:22 -0800 Subject: RFR (S): 8004747: Remove last_entry from VM_STRUCT macros In-Reply-To: <50E1F5E5.7020706@oracle.com> References: <50C64DA8.7020700@oracle.com> <50C80511.6000900@oracle.com> <50DDDB50.70101@oracle.com> <50DE2C89.7050006@oracle.com> <50DE4497.7050501@oracle.com> <50E1DB26.7060904@oracle.com> <50E1F5E5.7020706@oracle.com> Message-ID: <50EC5C5E.5060008@oracle.com> Serguei, Yumin - thanks for the reviews! I will update the test in the assert to mention the name of the array in question! Cheers, Mikael On 12/31/2012 12:30 PM, Yumin Qi wrote: > Looks good. Thanks for the fix, the macros is quite complex to > understand. Agree with Serguei the assertion with better description. > > Thanks > Yumin > > On 12/31/2012 10:36 AM, serguei.spitsyn at oracle.com wrote: >> Mikael, >> >> It looks good. >> It is also a nice simplification! >> >> The only thing I'd suggest is to be more specific in the assert at >> the end of the vmStructs.cpp. >> Instead of "Incorrect last entry" it'd be better to have "Incorrect >> struct last entry", etc. >> >> Also, it'd be useful if Yumin had a chance to surfacely look at the fix. >> >> Thanks, >> Serguei >> >> >> On 12/28/12 5:17 PM, Mikael Vidstedt wrote: >>> >>> Thanks David! >>> >>> Still need a 2nd reviewer! >>> >>> Cheers, >>> Mikael >>> >>> On 12/28/2012 3:34 PM, David Holmes wrote: >>>> Mikael, >>>> >>>> That all sounds fine to me. >>>> >>>> Thanks, >>>> David >>>> >>>> On 29/12/2012 3:48 AM, Mikael Vidstedt wrote: >>>>> >>>>> David, >>>>> >>>>> I did two things (both on linux/x86_64 only): >>>>> >>>>> 1. I compared the pre-processor output manually. Unfortunately >>>>> there are >>>>> line numbers sprinkled around in the pre-processed file which makes >>>>> comparing the output a bit more complex than it should be. Modulo the >>>>> line numbers and some white space changes the outputs matche. >>>>> 2. I wrote a small test which mimics what the SA does - it looks >>>>> up the >>>>> four exported structures dynamically and reads the data. Apart >>>>> from the >>>>> "address" field in the VMStructEntry entries the outputs almost [1] >>>>> match. The address field is expected to vary since it reflects the >>>>> actual placement in memory of various static variables. >>>>> >>>>> Are there other experiments you can think of? >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>> [1] Using this tool I actually found one bug in the table - one entry >>>>> (ClassLoaderDataGraph::_unloading) is declared as nonstatic when >>>>> it is >>>>> indeed static. I'll file a separate bug for that. >>>>> >>>>> On 12/11/2012 8:16 PM, David Holmes wrote: >>>>>> Hi Mikael, >>>>>> >>>>>> This looks okay to me - I like the simplification. However as I >>>>>> don't >>>>>> perform mental macro substitution particularly well (okay, not at >>>>>> all >>>>>> ;-)) I was wondering if there was a simple validation test where we >>>>>> could compare the pre-processed output before and after? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 11/12/2012 7:01 AM, Mikael Vidstedt wrote: >>>>>>> >>>>>>> Please review the following change: >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~mikael/8004747/webrev.00/ >>>>>>> >>>>>>> Background: >>>>>>> >>>>>>> This patch does 3 things (depending on how you count it): >>>>>>> >>>>>>> 1. Move the call to generating the last entry for the VM structures >>>>>>> database >>>>>>> >>>>>>> The vmStructs functionality is a macro based way of creating a >>>>>>> database >>>>>>> of information about VM internal structures, types and constants. >>>>>>> >>>>>>> The database for structures is defined in runtime/vmStructs.cpp >>>>>>> in an >>>>>>> array called localHotSpotVMStructs. The content of the array is >>>>>>> generated with calls to a few different macros (VM_STRUCTS, >>>>>>> VM_STRUCTS_PARALLELGC, VM_STRUCTS_CMS, VM_STRUCTS_G1, >>>>>>> VM_STRUCTS_CPU and >>>>>>> VM_STRUCTS_OS_CPU respectively). Common for all these macros is >>>>>>> the fact >>>>>>> that the last argument passed in is another macro >>>>>>> (GENERATE_VM_STRUCT_LAST_ENTRY) which is a generator for the end >>>>>>> marker/last entry in the database; a special entry which can be >>>>>>> easily >>>>>>> located by an external consumer of the information. >>>>>>> >>>>>>> Even though the end marker generator macro >>>>>>> (GENERATE_VM_STRUCT_LAST_ENTRY) is passed to all the VM_STRUCT* >>>>>>> macros, >>>>>>> the actual end marker must be generated once and only once. The >>>>>>> way this >>>>>>> is currently handled is that only the last VM_STRUCT macro, which >>>>>>> happens to be VM_STRUCTS_OS_CPU, actually makes use of its last >>>>>>> argument >>>>>>> and adds it to the end of the array. >>>>>>> >>>>>>> Not only is this fairly complex to understand, it's also more >>>>>>> fragile >>>>>>> than it needs to be. >>>>>>> >>>>>>> This change removes the last argument for all the VM_STRUCT >>>>>>> macros and >>>>>>> instead explicitly inserts the end marker at the end of the >>>>>>> localHotSpotVMStructs array. >>>>>>> >>>>>>> The same VM_STRUCTS macros are being used in VMStructs::init to >>>>>>> do type >>>>>>> checking. Instead of passing the end marker generator into the >>>>>>> macros >>>>>>> the last parameter is instead CHECK_SENTINEL, which is defined >>>>>>> to expand >>>>>>> to nothing, which means it can be safely removed. >>>>>>> >>>>>>> 2. Move the end marker generating for the VM types, VM int >>>>>>> constants and >>>>>>> VM long constants databases >>>>>>> >>>>>>> Repeat the exact above story, but replace anything called >>>>>>> Structs/STRUCT >>>>>>> with Types/TYPES, IntConstants/INT_CONSTANTS and >>>>>>> LongConstants/LONG_CONSTANTS respectively. >>>>>>> >>>>>>> 3. Minor prettification >>>>>>> >>>>>>> In addition to the above the change also removes some superfluous >>>>>>> backslashes from a few of the VM_STRUCT* macro calls. >>>>>>> >>>>>>> Thanks, >>>>>>> Mikael >>>>>>> >>>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130108/1f3d8176/attachment-0001.html From alan.bateman at oracle.com Tue Jan 8 12:48:41 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 08 Jan 2013 20:48:41 +0000 Subject: hg: jdk8/tl/jdk: 8002306: (se) Selector.open fails if invoked with thread interrupt status set [win] Message-ID: <20130108204915.2507F4710E@hg.openjdk.java.net> Changeset: d29a7ce28189 Author: dxu Date: 2013-01-08 20:37 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d29a7ce28189 8002306: (se) Selector.open fails if invoked with thread interrupt status set [win] Reviewed-by: alanb ! src/windows/classes/sun/nio/ch/PipeImpl.java + test/java/nio/channels/Pipe/PipeInterrupt.java From valerie.peng at oracle.com Tue Jan 8 13:07:27 2013 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Tue, 08 Jan 2013 21:07:27 +0000 Subject: hg: jdk8/tl/jdk: 4 new changesets Message-ID: <20130108210812.56F8A4710F@hg.openjdk.java.net> Changeset: 46e6a4b7ca26 Author: valeriep Date: 2013-01-07 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46e6a4b7ca26 6996769: support AEAD cipher Summary: Added implementation for GCM mode under AES cipher Reviewed-by: weijun ! src/share/classes/com/sun/crypto/provider/AESCipher.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/CipherTextStealing.java ! src/share/classes/com/sun/crypto/provider/FeedbackCipher.java + src/share/classes/com/sun/crypto/provider/GCMParameters.java + src/share/classes/com/sun/crypto/provider/GCTR.java + src/share/classes/com/sun/crypto/provider/GHASH.java + src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/spec/GCMParameterSpec.java ! test/com/sun/crypto/provider/Cipher/AES/Test4512524.java ! test/com/sun/crypto/provider/Cipher/AES/Test4512704.java ! test/com/sun/crypto/provider/Cipher/AES/Test4517355.java ! test/com/sun/crypto/provider/Cipher/AES/Test4626070.java + test/com/sun/crypto/provider/Cipher/AES/TestGCMKeyAndIvCheck.java + test/com/sun/crypto/provider/Cipher/AES/TestKATForGCM.java ! test/javax/crypto/Cipher/GCMAPI.java Changeset: 5333a4c8cade Author: valeriep Date: 2013-01-07 14:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5333a4c8cade Merge Changeset: 3c5a62290939 Author: valeriep Date: 2013-01-08 11:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c5a62290939 8004044: Lazily instantiate SunJCE.RANDOM Summary: Replace the static initialization of SunJCE.RANDOM object w/ lazy initialization Reviewed-by: mchung ! src/share/classes/com/sun/crypto/provider/AESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/BlowfishKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/DESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/ISO10126Padding.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/KeyProtector.java ! src/share/classes/com/sun/crypto/provider/PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/PBES1Core.java ! src/share/classes/com/sun/crypto/provider/PBES2Core.java ! src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java Changeset: 9b6a29cb04ac Author: valeriep Date: 2013-01-08 13:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b6a29cb04ac Merge From john.zavgren at oracle.com Tue Jan 8 13:32:06 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Tue, 8 Jan 2013 13:32:06 -0800 (PST) Subject: RFR JDK-8005120 Message-ID: On 12/28/2012 10:49 AM, John Zavgren wrote: Please consider the following webrev for JDK-8005120. http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.06/ (I apologize for overlooking an error in the windows code that I created in my previous release. ) Thanks! John Zavgren -------------------------------------------------------------- Greetings: I modified windows source code files so they pass size_t for buffer sizes and socklen_t for address structures. http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.03/ Please let me know what you think. Thanks! On 12/26/2012 02:56 PM, John Zavgren wrote: Greetings: I modified the windows code so that it uses socklen_t to specify the lengths of data structures, parameter lengths, etc. instead of ints (which can be negative.) http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.02/ Thanks! John Zavgren On 12/20/2012 05:47 PM, John Zavgren wrote: Greetings: I modified my changes so that windows knows the definition of the POSIX data type: socklen_t, and now all the system calls are using the "doctrinaire" data types. Please consider the following update. http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.01/ Thanks! John Zavgren On 20/12/2012 13:49, John Zavgren wrote: Greetings: I agree that the "correct" way to fix this problem is to use POSIX data types, e.g., socklen_t. However, when I switch to the doctrinaire data type, the build fails on windows machines: ------------- build monologue ----- c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2146: syntax error : missing ')' before identifier 'len' c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2081: 'socklen_t' : name in formal parameter list illegal c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2061: syntax error : identifier 'len' c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2059: syntax error : ';' c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2059: syntax error : ')' .... ------------- build monologue ----- I used alternative types, e.g., uint32_t, etc. as a way to avoid the limitations of windows. What is the recommended way to accommodate this windows limitation? Shall I use a typedef statement to define "socklen_t"? We don't suffer from this issue in the networking native code. The unix and windows implementations are distinct. I see the vm defines socklen_t in a windows specific header, hotspot/src/os/windows/vm/jvm_windows.h, as typedef int socklen_t; ...and it is then used in shared code, like jvm.cpp, and the hpi, by optionally including #ifdef TARGET_OS_FAMILY_windows # include "jvm_windows.h" #endif We could use a similar, but more simplistic, approach here. -Chris. Thanks! ----- Original Message ----- From: chris.hegarty at oracle.com To: david.holmes at oracle.com Cc: Alan.Bateman at oracle.com , serviceability-dev at openjdk.java.net , john.zavgren at oracle.com , net-dev at openjdk.java.net Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8005120 On 19/12/2012 20:52, David Holmes wrote: Real sense of deja-vu here. Didn't we go through this same thing with the HPI socket routines? Yes, and the networking native code too. I think it is best to use socklen_t for the unix code. From what I can see making these changes, to use socklen_t, should be relatively localized. -Chris. Depending on the OS (and version?) we should be using socklen_t not int and not uint32_t. David On 20/12/2012 2:35 AM, Chris Hegarty wrote: John, I grabbed your patch, and with it I now see different warnings. ../../../../src/share/transport/socket/socketTransport.c: In function 'socketTransport_startListening': ../../../../src/share/transport/socket/socketTransport.c:310:40: warning: pointer targets in passing argument 3 of 'dbgsysGetSocketName' differ in signedness [-Wpointer-sign] ../../../../src/share/transport/socket/sysSocket.h:58:5: note: expected 'uint32_t *' but argument is of type 'int *' ../../../../src/share/transport/socket/socketTransport.c: In function 'socketTransport_accept': ../../../../src/share/transport/socket/socketTransport.c:371:33: warning: pointer targets in passing argument 3 of 'dbgsysAccept' differ in signedness [-Wpointer-sign] ../../../../src/share/transport/socket/sysSocket.h:41:5: note: expected 'uint32_t *' but argument is of type 'int *' Do you see these in your build? -Chris. On 12/19/2012 03:42 PM, Alan Bateman wrote: John - this is the debugger socket transport so cc'ing the serviceability-dev list as that is where this code is maintained. On 19/12/2012 15:36, John Zavgren wrote: Greetings: Please consider the following change to the two files: src/share/transport/socket/sysSocket.h src/solaris/transport/socket/socket_md.c that eliminate compiler warnings that stem from the fact that the variables that the native code passes to various system calls were not declared correctly. They were declared as integers, but they must be "unsigned" integers because they are used to define buffer lengths. Were one to supply a negative value as an argument, it would be cast into an unsigned "Martian" value and there'd be (hopefully) a system call error. Thanks! John Zavgren http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/ -- John Zavgren john.zavgren at oracle.com 603-821-0904 US-Burlington-MA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130108/a8375366/attachment.html From harold.seigel at oracle.com Tue Jan 8 13:40:39 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 08 Jan 2013 21:40:39 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8005076: Creating a CDS archive with one alignment and running another causes a crash. Message-ID: <20130108214041.D844647116@hg.openjdk.java.net> Changeset: 561148896559 Author: hseigel Date: 2013-01-08 13:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/561148896559 8005076: Creating a CDS archive with one alignment and running another causes a crash. Summary: Save the alignment when writing the CDS and compare it when reading the CDS. Reviewed-by: kvn, coleenp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From coleen.phillimore at oracle.com Tue Jan 8 15:43:11 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 08 Jan 2013 23:43:11 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130108234315.DB8CF4711B@hg.openjdk.java.net> Changeset: ade95d680b42 Author: coleenp Date: 2013-01-08 14:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 8004728: Add hotspot support for parameter reflection Summary: Add hotspot support for parameter reflection Reviewed-by: acorn, jrose, coleenp Contributed-by: eric.mccorkle at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp Changeset: 185a2c979a0e Author: coleenp Date: 2013-01-08 13:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/185a2c979a0e Merge From joe.darcy at oracle.com Tue Jan 8 16:08:44 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 09 Jan 2013 00:08:44 +0000 Subject: hg: jdk8/tl/jdk: 8005298: Add FunctionalInterface type to the core libraries Message-ID: <20130109000855.ED2ED4711C@hg.openjdk.java.net> Changeset: ac5fd681a7a2 Author: darcy Date: 2013-01-08 16:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac5fd681a7a2 8005298: Add FunctionalInterface type to the core libraries Reviewed-by: mduigou + src/share/classes/java/lang/FunctionalInterface.java From zhengyu.gu at oracle.com Tue Jan 8 18:34:54 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 09 Jan 2013 02:34:54 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20130109023504.4357647123@hg.openjdk.java.net> Changeset: ecd24264898b Author: zgu Date: 2013-01-08 14:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ecd24264898b 8005048: NMT: #loaded classes needs to just show the # defined classes Summary: Count number of instance classes so that it matches class metadata size Reviewed-by: coleenp, acorn ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 37a3e8b7a1e9 Author: zgu Date: 2013-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/37a3e8b7a1e9 Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 0c93d4818214 Author: zgu Date: 2013-01-08 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0c93d4818214 Merge From shanliang.jiang at oracle.com Wed Jan 9 00:40:42 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 09 Jan 2013 09:40:42 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50EC3850.7080508@oracle.com> References: <50EC3850.7080508@oracle.com> Message-ID: <50ED2D0A.5000509@oracle.com> I still have no idea why the test failed, but I do not see why a longer timeout can fix the test. Have you reproduced the problem and tested your fix? if yes then possible the long timeout hided a real problem. The timeout you made longer was used to wait a notification which should never arrive. To remove a listener from a client side, we did: 1) at client side, check whether it was added in the client side 2) at server side, check whether the MBean in question was registered in the MBeanServer (!!!) 3) at server side, check whether the listener was added. So 2) tells that we did not rely on a "unregister" notification. Anyway, if you use a SAME thread to call "unregister" operation to unregister an mbean, then any following call (without any time break) to use the mbean should fail, like "removeNotificationListener", "isRegistered" etc. I do see a bug here, if we remove a listener from a non-existing MBeam, we get "ListenerNotFoundException" at a client side, but get "InstanceNotFoundException" at server side, I think we should create a bug, because both implemented the same interface MBeanServerConnection. Shanliang Jaroslav Bachorik wrote: > Looking for review and a sponsor. > > Webrev at http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 > > In this issue the timing is the problem. MBeanServer.unregisterMBean() > fires the "unregister" notification which is sent to the server > asynchronously. Thus it may happen that the "unregister" notification > has not been yet processed at the time of invoking > removeNotificationListener() and the notification listeners hasn't been > cleaned up leading to the test failure. > > There is no synchronization between the client and the server and such > race condition can occur occasionally. Normally, the execution is fast > enough to behave like the "unregister" notification is processed > synchronously with the unregisterMBean() operation but it seems that > using fastdebug Server VM bits with the -Xcomp option strains the CPU > enough to make this problem appear. > > There is no proper fix for this - the only thing that work is waiting a > bit longer in the main thread to give the notification processing thread > some time to clean up the listeners. > > Regards, > > -JB- > From jaroslav.bachorik at oracle.com Wed Jan 9 01:45:51 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 09 Jan 2013 10:45:51 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50ED2D0A.5000509@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> Message-ID: <50ED3C4F.1070001@oracle.com> On 01/09/2013 09:40 AM, shanliang wrote: > I still have no idea why the test failed, but I do not see why a longer > timeout can fix the test. Have you reproduced the problem and tested > your fix? if yes then possible the long timeout hided a real problem. Yes, I can reproduce the problem (using the fastbuild bits and -Xcomp switch) and verify that the fix makes the test pass. The ClientNotifForwarder scans the notifications for MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the appropriate notification listeners in a separate thread. Thus, calling "removeNotificationListener" on the main thread is prone to racing. > > The timeout you made longer was used to wait a notification which should > never arrive. Well, it can be used to allow more time to process the "unregister" notification, too. When I think more of this I am more inclined to fix the race condition. An updated webrev will follow. > > To remove a listener from a client side, we did: > 1) at client side, check whether it was added in the client side > 2) at server side, check whether the MBean in question was registered in > the MBeanServer (!!!) > 3) at server side, check whether the listener was added. > > So 2) tells that we did not rely on a "unregister" notification. Anyway, > if you use a SAME thread to call "unregister" operation to unregister an > mbean, then any following call (without any time break) to use the mbean > should fail, like "removeNotificationListener", "isRegistered" etc. > > I do see a bug here, if we remove a listener from a non-existing MBeam, > we get "ListenerNotFoundException" at a client side, but get > "InstanceNotFoundException" at server side, I think we should create a > bug, because both implemented the same interface MBeanServerConnection. Yes, it is rather inconsistent. -JB- > > Shanliang > > Jaroslav Bachorik wrote: >> Looking for review and a sponsor. >> >> Webrev at http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >> >> In this issue the timing is the problem. MBeanServer.unregisterMBean() >> fires the "unregister" notification which is sent to the server >> asynchronously. Thus it may happen that the "unregister" notification >> has not been yet processed at the time of invoking >> removeNotificationListener() and the notification listeners hasn't been >> cleaned up leading to the test failure. >> >> There is no synchronization between the client and the server and such >> race condition can occur occasionally. Normally, the execution is fast >> enough to behave like the "unregister" notification is processed >> synchronously with the unregisterMBean() operation but it seems that >> using fastdebug Server VM bits with the -Xcomp option strains the CPU >> enough to make this problem appear. >> >> There is no proper fix for this - the only thing that work is waiting a >> bit longer in the main thread to give the notification processing thread >> some time to clean up the listeners. >> >> Regards, >> >> -JB- >> > From shanliang.jiang at oracle.com Wed Jan 9 02:08:44 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 09 Jan 2013 11:08:44 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50ED3C4F.1070001@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> Message-ID: <50ED41AC.4010007@oracle.com> Jaroslav Bachorik wrote: > On 01/09/2013 09:40 AM, shanliang wrote: > >> I still have no idea why the test failed, but I do not see why a longer >> timeout can fix the test. Have you reproduced the problem and tested >> your fix? if yes then possible the long timeout hided a real problem. >> > > Yes, I can reproduce the problem (using the fastbuild bits and -Xcomp > switch) and verify that the fix makes the test pass. > > The ClientNotifForwarder scans the notifications for > MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the > appropriate notification listeners in a separate thread. Thus, calling > "removeNotificationListener" on the main thread is prone to racing. > It is true that ClientNotifForwarder scans the notifications for MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the appropriate notification listeners in a separate thread. This is for a client connection to do clean if a user never calls removeNotificationListener. But calling directly removeNotificationListener from a client should still get exception if the clean has not been done. As I said, if the client checked and found the listener was still there, then the client sent a request to its server to remove the listener at server side, the server should find that the MBean in question was not registered, so the server should throw an exception. The bug might be here. Shanliang > >> The timeout you made longer was used to wait a notification which should >> never arrive. >> > > Well, it can be used to allow more time to process the "unregister" > notification, too. > > When I think more of this I am more inclined to fix the race condition. > An updated webrev will follow. > > >> To remove a listener from a client side, we did: >> 1) at client side, check whether it was added in the client side >> 2) at server side, check whether the MBean in question was registered in >> the MBeanServer (!!!) >> 3) at server side, check whether the listener was added. >> >> So 2) tells that we did not rely on a "unregister" notification. Anyway, >> if you use a SAME thread to call "unregister" operation to unregister an >> mbean, then any following call (without any time break) to use the mbean >> should fail, like "removeNotificationListener", "isRegistered" etc. >> >> I do see a bug here, if we remove a listener from a non-existing MBeam, >> we get "ListenerNotFoundException" at a client side, but get >> "InstanceNotFoundException" at server side, I think we should create a >> bug, because both implemented the same interface MBeanServerConnection. >> > > Yes, it is rather inconsistent. > > -JB- > > >> Shanliang >> >> Jaroslav Bachorik wrote: >> >>> Looking for review and a sponsor. >>> >>> Webrev at http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>> >>> In this issue the timing is the problem. MBeanServer.unregisterMBean() >>> fires the "unregister" notification which is sent to the server >>> asynchronously. Thus it may happen that the "unregister" notification >>> has not been yet processed at the time of invoking >>> removeNotificationListener() and the notification listeners hasn't been >>> cleaned up leading to the test failure. >>> >>> There is no synchronization between the client and the server and such >>> race condition can occur occasionally. Normally, the execution is fast >>> enough to behave like the "unregister" notification is processed >>> synchronously with the unregisterMBean() operation but it seems that >>> using fastdebug Server VM bits with the -Xcomp option strains the CPU >>> enough to make this problem appear. >>> >>> There is no proper fix for this - the only thing that work is waiting a >>> bit longer in the main thread to give the notification processing thread >>> some time to clean up the listeners. >>> >>> Regards, >>> >>> -JB- >>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130109/72910e24/attachment.html From jaroslav.bachorik at oracle.com Wed Jan 9 05:15:58 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 09 Jan 2013 14:15:58 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50ED41AC.4010007@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> Message-ID: <50ED6D8E.6070404@oracle.com> On 01/09/2013 11:08 AM, shanliang wrote: > Jaroslav Bachorik wrote: >> On 01/09/2013 09:40 AM, shanliang wrote: >> >>> I still have no idea why the test failed, but I do not see why a longer >>> timeout can fix the test. Have you reproduced the problem and tested >>> your fix? if yes then possible the long timeout hided a real problem. >>> >> >> Yes, I can reproduce the problem (using the fastbuild bits and -Xcomp >> switch) and verify that the fix makes the test pass. >> >> The ClientNotifForwarder scans the notifications for >> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >> appropriate notification listeners in a separate thread. Thus, calling >> "removeNotificationListener" on the main thread is prone to racing. >> > It is true that ClientNotifForwarder scans the notifications for > MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the > appropriate notification listeners in a separate thread. This is for a > client connection to do clean if a user never calls > removeNotificationListener. > > But calling directly removeNotificationListener from a client should > still get exception if the clean has not been done. As I said, if the > client checked and found the listener was still there, then the client > sent a request to its server to remove the listener at server side, the > server should find that the MBean in question was not registered, so the > server should throw an exception. The bug might be here. This won't work. The server side listeners are removed upon receiving the "unregistered" notification which is delivered from the ClientNotificationForwarder and it may have not run yet (since it runs in a separate executor thread). The result is that the attempt to remove the notification listener on the server will succeed as well failing the test subsequently. -JB- > > Shanliang >> >>> The timeout you made longer was used to wait a notification which should >>> never arrive. >>> >> >> Well, it can be used to allow more time to process the "unregister" >> notification, too. >> >> When I think more of this I am more inclined to fix the race condition. >> An updated webrev will follow. >> >> >>> To remove a listener from a client side, we did: >>> 1) at client side, check whether it was added in the client side >>> 2) at server side, check whether the MBean in question was registered in >>> the MBeanServer (!!!) >>> 3) at server side, check whether the listener was added. >>> >>> So 2) tells that we did not rely on a "unregister" notification. Anyway, >>> if you use a SAME thread to call "unregister" operation to unregister an >>> mbean, then any following call (without any time break) to use the mbean >>> should fail, like "removeNotificationListener", "isRegistered" etc. >>> >>> I do see a bug here, if we remove a listener from a non-existing MBeam, >>> we get "ListenerNotFoundException" at a client side, but get >>> "InstanceNotFoundException" at server side, I think we should create a >>> bug, because both implemented the same interface MBeanServerConnection. >>> >> >> Yes, it is rather inconsistent. >> >> -JB- >> >> >>> Shanliang >>> >>> Jaroslav Bachorik wrote: >>> >>>> Looking for review and a sponsor. >>>> >>>> Webrev at http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>> >>>> In this issue the timing is the problem. MBeanServer.unregisterMBean() >>>> fires the "unregister" notification which is sent to the server >>>> asynchronously. Thus it may happen that the "unregister" notification >>>> has not been yet processed at the time of invoking >>>> removeNotificationListener() and the notification listeners hasn't been >>>> cleaned up leading to the test failure. >>>> >>>> There is no synchronization between the client and the server and such >>>> race condition can occur occasionally. Normally, the execution is fast >>>> enough to behave like the "unregister" notification is processed >>>> synchronously with the unregisterMBean() operation but it seems that >>>> using fastdebug Server VM bits with the -Xcomp option strains the CPU >>>> enough to make this problem appear. >>>> >>>> There is no proper fix for this - the only thing that work is waiting a >>>> bit longer in the main thread to give the notification processing >>>> thread >>>> some time to clean up the listeners. >>>> >>>> Regards, >>>> >>>> -JB- >>>> >> >> > > From shanliang.jiang at oracle.com Wed Jan 9 05:44:22 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 09 Jan 2013 14:44:22 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50ED6D8E.6070404@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> Message-ID: <50ED7436.1020205@oracle.com> Let's forget the JMX implementation at first. If an MBean is unregistered, a user at client side calls "removeNotificationListener" on the MBean, what should happen? if the user calls "isRegistered" on the MBean, what should happen? I have done 2 tests, I used only one thread: 1) ...... localServer.unregisterMBean(myMBean); boolean isRegistered = remoteClientServer.isRegistered(myMBean)); I got isRegistered = false; 2) ...... localServer.unregisterMBean(myMBean); System.out.println("isRegistered = "+remoteClientServer.sRegistered(myMBean)); remoteClientServer.removeNotificationListener(myMBean, listener); I did not get an exception. The 1) told that the client could know the MBean was unregistered, then the client should throw an exception for the call of "removeNotificationListener" in 2). The test "DeadListenerTest" got passed in some machines because of the timeout for waiting a notification. I think its failure just tells a new bug. To set a longer timeout just hides the real bug, and the test might fail again one day if running condition is changed and you might need longer timeout again. Shanliang Jaroslav Bachorik wrote: > On 01/09/2013 11:08 AM, shanliang wrote: > >> Jaroslav Bachorik wrote: >> >>> On 01/09/2013 09:40 AM, shanliang wrote: >>> >>> >>>> I still have no idea why the test failed, but I do not see why a longer >>>> timeout can fix the test. Have you reproduced the problem and tested >>>> your fix? if yes then possible the long timeout hided a real problem. >>>> >>>> >>> Yes, I can reproduce the problem (using the fastbuild bits and -Xcomp >>> switch) and verify that the fix makes the test pass. >>> >>> The ClientNotifForwarder scans the notifications for >>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>> appropriate notification listeners in a separate thread. Thus, calling >>> "removeNotificationListener" on the main thread is prone to racing. >>> >>> >> It is true that ClientNotifForwarder scans the notifications for >> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >> appropriate notification listeners in a separate thread. This is for a >> client connection to do clean if a user never calls >> removeNotificationListener. >> >> But calling directly removeNotificationListener from a client should >> still get exception if the clean has not been done. As I said, if the >> client checked and found the listener was still there, then the client >> sent a request to its server to remove the listener at server side, the >> server should find that the MBean in question was not registered, so the >> server should throw an exception. The bug might be here. >> > > This won't work. The server side listeners are removed upon receiving > the "unregistered" notification which is delivered from the > ClientNotificationForwarder and it may have not run yet (since it runs > in a separate executor thread). The result is that the attempt to remove > the notification listener on the server will succeed as well failing the > test subsequently. > > -JB- > > >> Shanliang >> >>> >>> >>>> The timeout you made longer was used to wait a notification which should >>>> never arrive. >>>> >>>> >>> Well, it can be used to allow more time to process the "unregister" >>> notification, too. >>> >>> When I think more of this I am more inclined to fix the race condition. >>> An updated webrev will follow. >>> >>> >>> >>>> To remove a listener from a client side, we did: >>>> 1) at client side, check whether it was added in the client side >>>> 2) at server side, check whether the MBean in question was registered in >>>> the MBeanServer (!!!) >>>> 3) at server side, check whether the listener was added. >>>> >>>> So 2) tells that we did not rely on a "unregister" notification. Anyway, >>>> if you use a SAME thread to call "unregister" operation to unregister an >>>> mbean, then any following call (without any time break) to use the mbean >>>> should fail, like "removeNotificationListener", "isRegistered" etc. >>>> >>>> I do see a bug here, if we remove a listener from a non-existing MBeam, >>>> we get "ListenerNotFoundException" at a client side, but get >>>> "InstanceNotFoundException" at server side, I think we should create a >>>> bug, because both implemented the same interface MBeanServerConnection. >>>> >>>> >>> Yes, it is rather inconsistent. >>> >>> -JB- >>> >>> >>> >>>> Shanliang >>>> >>>> Jaroslav Bachorik wrote: >>>> >>>> >>>>> Looking for review and a sponsor. >>>>> >>>>> Webrev at http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>>> >>>>> In this issue the timing is the problem. MBeanServer.unregisterMBean() >>>>> fires the "unregister" notification which is sent to the server >>>>> asynchronously. Thus it may happen that the "unregister" notification >>>>> has not been yet processed at the time of invoking >>>>> removeNotificationListener() and the notification listeners hasn't been >>>>> cleaned up leading to the test failure. >>>>> >>>>> There is no synchronization between the client and the server and such >>>>> race condition can occur occasionally. Normally, the execution is fast >>>>> enough to behave like the "unregister" notification is processed >>>>> synchronously with the unregisterMBean() operation but it seems that >>>>> using fastdebug Server VM bits with the -Xcomp option strains the CPU >>>>> enough to make this problem appear. >>>>> >>>>> There is no proper fix for this - the only thing that work is waiting a >>>>> bit longer in the main thread to give the notification processing >>>>> thread >>>>> some time to clean up the listeners. >>>>> >>>>> Regards, >>>>> >>>>> -JB- >>>>> >>>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130109/77bcd5e4/attachment.html From jaroslav.bachorik at oracle.com Wed Jan 9 06:00:33 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 09 Jan 2013 15:00:33 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50ED7436.1020205@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> <50ED7436.1020205@oracle.com> Message-ID: <50ED7801.8080704@oracle.com> On 01/09/2013 02:44 PM, shanliang wrote: > Let's forget the JMX implementation at first. If an MBean is > unregistered, a user at client side calls "removeNotificationListener" > on the MBean, what should happen? if the user calls "isRegistered" on > the MBean, what should happen? > > I have done 2 tests, I used only one thread: > > 1) > ...... > localServer.unregisterMBean(myMBean); > boolean isRegistered = remoteClientServer.isRegistered(myMBean)); > > I got isRegistered = false; > > 2) > ...... > localServer.unregisterMBean(myMBean); > System.out.println("isRegistered = > "+remoteClientServer.sRegistered(myMBean)); > remoteClientServer.removeNotificationListener(myMBean, listener); > > I did not get an exception. > > The 1) told that the client could know the MBean was unregistered, then > the client should throw an exception for the call of > "removeNotificationListener" in 2). Yes, but then it would not test the listener leakage as it was supposed to test but rather the fact that the client throws the appropriate exception. The fact that the mbean was unregistered does not necessarily mean that the listeners were released. The main problem remains - the listeners are being cleaned-up asynchronously and the clean-up process might race against the other uses of the JMX API. > > The test "DeadListenerTest" got passed in some machines because of the > timeout for waiting a notification. I think its failure just tells a new > bug. > > To set a longer timeout just hides the real bug, and the test might fail > again one day if running condition is changed and you might need longer > timeout again. Yes, I agree with you that extending the timeout just lessens the likelihood of the race condition and does not prevent it. > > Shanliang > > Jaroslav Bachorik wrote: >> On 01/09/2013 11:08 AM, shanliang wrote: >> >>> Jaroslav Bachorik wrote: >>> >>>> On 01/09/2013 09:40 AM, shanliang wrote: >>>> >>>> >>>>> I still have no idea why the test failed, but I do not see why a >>>>> longer >>>>> timeout can fix the test. Have you reproduced the problem and tested >>>>> your fix? if yes then possible the long timeout hided a real problem. >>>>> >>>> Yes, I can reproduce the problem (using the fastbuild bits and -Xcomp >>>> switch) and verify that the fix makes the test pass. >>>> >>>> The ClientNotifForwarder scans the notifications for >>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>>> appropriate notification listeners in a separate thread. Thus, calling >>>> "removeNotificationListener" on the main thread is prone to racing. >>>> >>> It is true that ClientNotifForwarder scans the notifications for >>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>> appropriate notification listeners in a separate thread. This is for a >>> client connection to do clean if a user never calls >>> removeNotificationListener. >>> >>> But calling directly removeNotificationListener from a client should >>> still get exception if the clean has not been done. As I said, if the >>> client checked and found the listener was still there, then the client >>> sent a request to its server to remove the listener at server side, the >>> server should find that the MBean in question was not registered, so the >>> server should throw an exception. The bug might be here. >>> >> >> This won't work. The server side listeners are removed upon receiving >> the "unregistered" notification which is delivered from the >> ClientNotificationForwarder and it may have not run yet (since it runs >> in a separate executor thread). The result is that the attempt to remove >> the notification listener on the server will succeed as well failing the >> test subsequently. >> >> -JB- >> >> >>> Shanliang >>> >>>> >>>> >>>>> The timeout you made longer was used to wait a notification which >>>>> should >>>>> never arrive. >>>>> >>>> Well, it can be used to allow more time to process the "unregister" >>>> notification, too. >>>> >>>> When I think more of this I am more inclined to fix the race condition. >>>> An updated webrev will follow. >>>> >>>> >>>> >>>>> To remove a listener from a client side, we did: >>>>> 1) at client side, check whether it was added in the client side >>>>> 2) at server side, check whether the MBean in question was >>>>> registered in >>>>> the MBeanServer (!!!) >>>>> 3) at server side, check whether the listener was added. >>>>> >>>>> So 2) tells that we did not rely on a "unregister" notification. >>>>> Anyway, >>>>> if you use a SAME thread to call "unregister" operation to >>>>> unregister an >>>>> mbean, then any following call (without any time break) to use the >>>>> mbean >>>>> should fail, like "removeNotificationListener", "isRegistered" etc. >>>>> >>>>> I do see a bug here, if we remove a listener from a non-existing >>>>> MBeam, >>>>> we get "ListenerNotFoundException" at a client side, but get >>>>> "InstanceNotFoundException" at server side, I think we should create a >>>>> bug, because both implemented the same interface >>>>> MBeanServerConnection. >>>>> >>>> Yes, it is rather inconsistent. >>>> >>>> -JB- >>>> >>>> >>>> >>>>> Shanliang >>>>> >>>>> Jaroslav Bachorik wrote: >>>>> >>>>>> Looking for review and a sponsor. >>>>>> >>>>>> Webrev at http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>>>> >>>>>> In this issue the timing is the problem. >>>>>> MBeanServer.unregisterMBean() >>>>>> fires the "unregister" notification which is sent to the server >>>>>> asynchronously. Thus it may happen that the "unregister" notification >>>>>> has not been yet processed at the time of invoking >>>>>> removeNotificationListener() and the notification listeners hasn't >>>>>> been >>>>>> cleaned up leading to the test failure. >>>>>> >>>>>> There is no synchronization between the client and the server and >>>>>> such >>>>>> race condition can occur occasionally. Normally, the execution is >>>>>> fast >>>>>> enough to behave like the "unregister" notification is processed >>>>>> synchronously with the unregisterMBean() operation but it seems that >>>>>> using fastdebug Server VM bits with the -Xcomp option strains the CPU >>>>>> enough to make this problem appear. >>>>>> >>>>>> There is no proper fix for this - the only thing that work is >>>>>> waiting a >>>>>> bit longer in the main thread to give the notification processing >>>>>> thread >>>>>> some time to clean up the listeners. >>>>>> >>>>>> Regards, >>>>>> >>>>>> -JB- >>>>>> >>>> >>> >> >> > > From shanliang.jiang at oracle.com Wed Jan 9 06:25:51 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 09 Jan 2013 15:25:51 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50ED7801.8080704@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> <50ED7436.1020205@oracle.com> <50ED7801.8080704@oracle.com> Message-ID: <50ED7DEF.9020108@oracle.com> Jaroslav Bachorik wrote: > On 01/09/2013 02:44 PM, shanliang wrote: > >> Let's forget the JMX implementation at first. If an MBean is >> unregistered, a user at client side calls "removeNotificationListener" >> on the MBean, what should happen? if the user calls "isRegistered" on >> the MBean, what should happen? >> >> I have done 2 tests, I used only one thread: >> >> 1) >> ...... >> localServer.unregisterMBean(myMBean); >> boolean isRegistered = remoteClientServer.isRegistered(myMBean)); >> >> I got isRegistered = false; >> >> 2) >> ...... >> localServer.unregisterMBean(myMBean); >> System.out.println("isRegistered = >> "+remoteClientServer.sRegistered(myMBean)); >> remoteClientServer.removeNotificationListener(myMBean, listener); >> >> I did not get an exception. >> >> The 1) told that the client could know the MBean was unregistered, then >> the client should throw an exception for the call of >> "removeNotificationListener" in 2). >> > > Yes, but then it would not test the listener leakage as it was supposed > to test but rather the fact that the client throws the appropriate > exception. The fact that the mbean was unregistered does not necessarily > mean that the listeners were released. The main problem remains - the > listeners are being cleaned-up asynchronously and the clean-up process > might race against the other uses of the JMX API. > client.removeNotificationListener is not a right way here to test listener leak, we could use some other ways, for example we keep the listener in a weak reference, then after the mbean is removed, the weak reference should be empty after some time. Another way is like DeadListenerTest does to check whether clean has done at server side: use reflection to get the "listenerMap" at server side and make sure it is empty, but this need to add a private method to the class ClientNotifForwarder. I think we have 3 things to do here: 1) modify the test to not use removeNotificationListener for testing listener leak 2) create a new bug about a client does not throw an exception after an mbean is unregistered 3) create a bug about a client does not throw a same exception as at server side. I will do 2) and 3), if you like you can continue 1), it might need to do fix also in the JMX implementation. Shanliang > >> The test "DeadListenerTest" got passed in some machines because of the >> timeout for waiting a notification. I think its failure just tells a new >> bug. >> >> To set a longer timeout just hides the real bug, and the test might fail >> again one day if running condition is changed and you might need longer >> timeout again. >> > > Yes, I agree with you that extending the timeout just lessens the > likelihood of the race condition and does not prevent it. > > >> Shanliang >> >> Jaroslav Bachorik wrote: >> >>> On 01/09/2013 11:08 AM, shanliang wrote: >>> >>> >>>> Jaroslav Bachorik wrote: >>>> >>>> >>>>> On 01/09/2013 09:40 AM, shanliang wrote: >>>>> >>>>> >>>>> >>>>>> I still have no idea why the test failed, but I do not see why a >>>>>> longer >>>>>> timeout can fix the test. Have you reproduced the problem and tested >>>>>> your fix? if yes then possible the long timeout hided a real problem. >>>>>> >>>>>> >>>>> Yes, I can reproduce the problem (using the fastbuild bits and -Xcomp >>>>> switch) and verify that the fix makes the test pass. >>>>> >>>>> The ClientNotifForwarder scans the notifications for >>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>>>> appropriate notification listeners in a separate thread. Thus, calling >>>>> "removeNotificationListener" on the main thread is prone to racing. >>>>> >>>>> >>>> It is true that ClientNotifForwarder scans the notifications for >>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>>> appropriate notification listeners in a separate thread. This is for a >>>> client connection to do clean if a user never calls >>>> removeNotificationListener. >>>> >>>> But calling directly removeNotificationListener from a client should >>>> still get exception if the clean has not been done. As I said, if the >>>> client checked and found the listener was still there, then the client >>>> sent a request to its server to remove the listener at server side, the >>>> server should find that the MBean in question was not registered, so the >>>> server should throw an exception. The bug might be here. >>>> >>>> >>> This won't work. The server side listeners are removed upon receiving >>> the "unregistered" notification which is delivered from the >>> ClientNotificationForwarder and it may have not run yet (since it runs >>> in a separate executor thread). The result is that the attempt to remove >>> the notification listener on the server will succeed as well failing the >>> test subsequently. >>> >>> -JB- >>> >>> >>> >>>> Shanliang >>>> >>>> >>>>> >>>>> >>>>> >>>>>> The timeout you made longer was used to wait a notification which >>>>>> should >>>>>> never arrive. >>>>>> >>>>>> >>>>> Well, it can be used to allow more time to process the "unregister" >>>>> notification, too. >>>>> >>>>> When I think more of this I am more inclined to fix the race condition. >>>>> An updated webrev will follow. >>>>> >>>>> >>>>> >>>>> >>>>>> To remove a listener from a client side, we did: >>>>>> 1) at client side, check whether it was added in the client side >>>>>> 2) at server side, check whether the MBean in question was >>>>>> registered in >>>>>> the MBeanServer (!!!) >>>>>> 3) at server side, check whether the listener was added. >>>>>> >>>>>> So 2) tells that we did not rely on a "unregister" notification. >>>>>> Anyway, >>>>>> if you use a SAME thread to call "unregister" operation to >>>>>> unregister an >>>>>> mbean, then any following call (without any time break) to use the >>>>>> mbean >>>>>> should fail, like "removeNotificationListener", "isRegistered" etc. >>>>>> >>>>>> I do see a bug here, if we remove a listener from a non-existing >>>>>> MBeam, >>>>>> we get "ListenerNotFoundException" at a client side, but get >>>>>> "InstanceNotFoundException" at server side, I think we should create a >>>>>> bug, because both implemented the same interface >>>>>> MBeanServerConnection. >>>>>> >>>>>> >>>>> Yes, it is rather inconsistent. >>>>> >>>>> -JB- >>>>> >>>>> >>>>> >>>>> >>>>>> Shanliang >>>>>> >>>>>> Jaroslav Bachorik wrote: >>>>>> >>>>>> >>>>>>> Looking for review and a sponsor. >>>>>>> >>>>>>> Webrev at http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>>>>> >>>>>>> In this issue the timing is the problem. >>>>>>> MBeanServer.unregisterMBean() >>>>>>> fires the "unregister" notification which is sent to the server >>>>>>> asynchronously. Thus it may happen that the "unregister" notification >>>>>>> has not been yet processed at the time of invoking >>>>>>> removeNotificationListener() and the notification listeners hasn't >>>>>>> been >>>>>>> cleaned up leading to the test failure. >>>>>>> >>>>>>> There is no synchronization between the client and the server and >>>>>>> such >>>>>>> race condition can occur occasionally. Normally, the execution is >>>>>>> fast >>>>>>> enough to behave like the "unregister" notification is processed >>>>>>> synchronously with the unregisterMBean() operation but it seems that >>>>>>> using fastdebug Server VM bits with the -Xcomp option strains the CPU >>>>>>> enough to make this problem appear. >>>>>>> >>>>>>> There is no proper fix for this - the only thing that work is >>>>>>> waiting a >>>>>>> bit longer in the main thread to give the notification processing >>>>>>> thread >>>>>>> some time to clean up the listeners. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130109/7e0c4d75/attachment-0001.html From shanliang.jiang at oracle.com Wed Jan 9 06:32:12 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 09 Jan 2013 15:32:12 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50ED7DEF.9020108@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> <50ED7436.1020205@oracle.com> <50ED7801.8080704@oracle.com> <50ED7DEF.9020108@oracle.com> Message-ID: <50ED7F6C.4010301@oracle.com> shanliang wrote: > I think we have 3 things to do here: > 1) modify the test to not use removeNotificationListener for testing > listener leak > 2) create a new bug about a client does not throw an exception after > an mbean is unregistered > 3) create a bug about a client does not throw a same exception as at > server side. > > I will do 2) and 3), if you like you can continue 1), it might need to > do fix also in the JMX implementation. Oh, 1) does not need to do fix in JMX implementation, just fix the test. From chris.hegarty at oracle.com Wed Jan 9 06:53:11 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Jan 2013 14:53:11 +0000 Subject: RFR JDK-8005120 In-Reply-To: References: Message-ID: <50ED8457.20003@oracle.com> On 08/01/2013 21:32, John Zavgren wrote: > On 12/28/2012 10:49 AM, John Zavgren wrote: > Please consider the following webrev for JDK-8005120. > http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.06/ > I don't see any difference in this webrev from the previous one. Did you upload the correct version? -Chris. > > (I apologize for overlooking an error in the windows code that I created > in my previous release. ) > > Thanks! > John Zavgren > -------------------------------------------------------------- > > Greetings: > > I modified windows source code files so they pass size_t for buffer > sizes and socklen_t for address structures. > > http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.03/ > > Please let me know what you think. > > Thanks! > > On 12/26/2012 02:56 PM, John Zavgren wrote: > > Greetings: > I modified the windows code so that it uses socklen_t to specify > the lengths of data structures, parameter lengths, etc. instead > of ints (which can be negative.) > > http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.02/ > > > Thanks! > John Zavgren > > On 12/20/2012 05:47 PM, John Zavgren wrote: > > Greetings: > > I modified my changes so that windows knows the definition > of the POSIX data type: socklen_t, and now all the system > calls are using the "doctrinaire" data types. > > Please consider the following update. > > http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.01/ > > > Thanks! > John Zavgren > > > > On 20/12/2012 13:49, John Zavgren wrote: > > Greetings: > > I agree that the "correct" way to fix this problem is to > use POSIX data types, e.g., socklen_t. However, when I > switch to the doctrinaire data type, the build fails on > windows machines: > ------------- build monologue ----- > c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) > : error C2146: syntax error : missing ')' before > identifier 'len' > c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) > : error C2081: 'socklen_t' : name in formal parameter > list illegal > c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) > : error C2061: syntax error : identifier 'len' > c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) > : error C2059: syntax error : ';' > c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) > : error C2059: syntax error : ')' > .... > ------------- build monologue ----- > > I used alternative types, e.g., uint32_t, etc. as a way > to avoid the limitations of windows. > What is the recommended way to accommodate this windows > limitation? Shall I use a typedef statement to define > "socklen_t"? > > We don't suffer from this issue in the networking native > code. The unix > and windows implementations are distinct. > > I see the vm defines socklen_t in a windows specific header, > hotspot/src/os/windows/vm/jvm_windows.h, as > typedef int socklen_t; > > ...and it is then used in shared code, like jvm.cpp, and the > hpi, by > optionally including > > #ifdef TARGET_OS_FAMILY_windows > # include "jvm_windows.h" > #endif > > We could use a similar, but more simplistic, approach here. > > -Chris. > > Thanks! > > > ----- Original Message ----- > From: chris.hegarty at oracle.com > To: david.holmes at oracle.com > Cc: Alan.Bateman at oracle.com, > serviceability-dev at openjdk.java.net, > john.zavgren at oracle.com, net-dev at openjdk.java.net > Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 > US/Canada Eastern > Subject: Re: RFR JDK-8005120 > > On 19/12/2012 20:52, David Holmes wrote: > > Real sense of deja-vu here. Didn't we go through > this same thing with > the HPI socket routines? > > Yes, and the networking native code too. > > I think it is best to use socklen_t for the unix code. > From what I can > see making these changes, to use socklen_t, should be > relatively localized. > > -Chris. > > Depending on the OS (and version?) we should be > using socklen_t not int > and not uint32_t. > > David > > On 20/12/2012 2:35 AM, Chris Hegarty wrote: > > John, > > I grabbed your patch, and with it I now see > different warnings. > > ../../../../src/share/transport/socket/socketTransport.c: > In function > 'socketTransport_startListening': > ../../../../src/share/transport/socket/socketTransport.c:310:40: > > warning: pointer targets in passing argument 3 > of 'dbgsysGetSocketName' > differ in signedness [-Wpointer-sign] > ../../../../src/share/transport/socket/sysSocket.h:58:5: > note: expected > 'uint32_t *' but argument is of type 'int *' > ../../../../src/share/transport/socket/socketTransport.c: > In function > 'socketTransport_accept': > ../../../../src/share/transport/socket/socketTransport.c:371:33: > > warning: pointer targets in passing argument 3 > of 'dbgsysAccept' differ > in signedness [-Wpointer-sign] > ../../../../src/share/transport/socket/sysSocket.h:41:5: > note: expected > 'uint32_t *' but argument is of type 'int *' > > Do you see these in your build? > > -Chris. > > On 12/19/2012 03:42 PM, Alan Bateman wrote: > > John - this is the debugger socket transport > so cc'ing the > serviceability-dev list as that is where > this code is maintained. > > On 19/12/2012 15:36, John Zavgren wrote: > > Greetings: > Please consider the following change to > the two files: > src/share/transport/socket/sysSocket.h > src/solaris/transport/socket/socket_md.c > that eliminate compiler warnings that > stem from the fact that the > variables that the native code passes to > various system calls were not > declared correctly. They were declared > as integers, but they must be > "unsigned" integers because they are > used to define buffer lengths. > Were one to supply a negative value as > an argument, it would be cast > into an unsigned "Martian" value and > there'd be (hopefully) a system > call error. > > Thanks! > John Zavgren > > http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/ > > > > > > > > > -- > John Zavgren > john.zavgren at oracle.com > 603-821-0904 > US-Burlington-MA > From sean.mullan at oracle.com Wed Jan 9 06:58:34 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 09 Jan 2013 14:58:34 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130109145938.EA84547143@hg.openjdk.java.net> Changeset: 86828e84654f Author: mullan Date: 2013-01-08 19:00 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86828e84654f 7019834: Eliminate dependency from PolicyFile to com.sun.security.auth.PrincipalComparator Summary: Add new java.security.Principal.implies method Reviewed-by: alanb ! src/share/classes/java/security/Principal.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/PolicyParser.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java + test/java/security/Principal/Implies.java ! test/sun/security/provider/PolicyFile/Comparator.java Changeset: bf6d0bca5ea7 Author: mullan Date: 2013-01-08 19:02 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf6d0bca5ea7 Merge - make/jdk/asm/Makefile - src/share/classes/sun/awt/TextureSizeConstraining.java - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: f0ed9ef84637 Author: mullan Date: 2013-01-09 08:59 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0ed9ef84637 Merge From jon.masamitsu at oracle.com Wed Jan 9 09:43:28 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 09 Jan 2013 09:43:28 -0800 Subject: request for review - 8004172: Remove display of permanent generation counters from jstat options In-Reply-To: <50E75A88.1020205@oracle.com> References: <50E75A88.1020205@oracle.com> Message-ID: <50EDAC40.3090408@oracle.com> I still need a review from an official "reviewer" please. Jon On 1/4/2013 2:41 PM, Jon Masamitsu wrote: > 8004172: Remove display of permanent generation counters from jstat > options > > This change removes from the jstat options the display of > permanent generation counters. It also removes entirely the > gcpermcapacity option. > > http://cr.openjdk.java.net/~jmasa/8004172/webrev.00/ > > The permanent generation has been removed from the hotspot VM. > The jstat counters for the permanent generation will be removed. > This change is in preparation for that removal. From jonathan.gibbons at oracle.com Wed Jan 9 10:27:28 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 09 Jan 2013 18:27:28 +0000 Subject: hg: jdk8/tl/langtools: 8005644: set default max errs and max warns Message-ID: <20130109182733.888E24714D@hg.openjdk.java.net> Changeset: d2eb08b3f64f Author: jjg Date: 2013-01-09 10:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d2eb08b3f64f 8005644: set default max errs and max warns Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/Messager.java + test/tools/javadoc/MaxWarns.java From karen.kinnear at oracle.com Wed Jan 9 11:17:53 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Wed, 09 Jan 2013 19:17:53 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests Message-ID: <20130109191755.D0B294714F@hg.openjdk.java.net> Changeset: adc176e95bf2 Author: acorn Date: 2013-01-09 11:39 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/adc176e95bf2 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests Summary: Fix verifier for new interface access flags Reviewed-by: acorn, kvn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/classfile/classFileParser.cpp From zhengyu.gu at oracle.com Wed Jan 9 14:21:04 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 09 Jan 2013 22:21:04 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130109222112.1B85C4715D@hg.openjdk.java.net> Changeset: dd7248d3e151 Author: zgu Date: 2013-01-09 14:46 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dd7248d3e151 7152671: RFE: Windows decoder should add some std dirs to the symbol search path Summary: Added JRE/JDK bin directories to decoder's symbol search path Reviewed-by: dcubed, sla ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp Changeset: 97ee8abd6ab2 Author: zgu Date: 2013-01-09 12:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/97ee8abd6ab2 Merge From mandy.chung at oracle.com Wed Jan 9 17:12:23 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Jan 2013 01:12:23 +0000 Subject: hg: jdk8/tl/jdk: 7103957: NegativeArraySizeException while initializing class IntegerCache Message-ID: <20130110011234.EAE414715F@hg.openjdk.java.net> Changeset: 4c8b37f159f9 Author: mchung Date: 2013-01-09 16:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c8b37f159f9 7103957: NegativeArraySizeException while initializing class IntegerCache Reviewed-by: darcy, mchung Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/lang/Integer.java From joe.darcy at oracle.com Wed Jan 9 20:03:14 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 10 Jan 2013 04:03:14 +0000 Subject: hg: jdk8/tl/langtools: 8004730: Add language model support for parameter reflection Message-ID: <20130110040316.EE49E47166@hg.openjdk.java.net> Changeset: 7612fe48be90 Author: darcy Date: 2013-01-09 20:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7612fe48be90 8004730: Add language model support for parameter reflection Reviewed-by: abuckley ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/VariableElement.java ! src/share/classes/javax/lang/model/element/package-info.java From joe.darcy at oracle.com Wed Jan 9 20:20:30 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 10 Jan 2013 04:20:30 +0000 Subject: hg: jdk8/tl/jdk: 8005713: Simplify library support for repeating annotations in java.lang.annotation Message-ID: <20130110042043.518CA47167@hg.openjdk.java.net> Changeset: 4176e6cc499e Author: darcy Date: 2013-01-09 20:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4176e6cc499e 8005713: Simplify library support for repeating annotations in java.lang.annotation Reviewed-by: abuckley + src/share/classes/java/lang/annotation/Repeatable.java From stuart.marks at oracle.com Thu Jan 10 00:52:10 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 10 Jan 2013 00:52:10 -0800 Subject: jmx-dev [PATCH] JDK-8005472: com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh failed on windows In-Reply-To: <50EAB014.30805@oracle.com> References: <50E16BA8.40203@oracle.com> <682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com> <50EAB014.30805@oracle.com> Message-ID: <50EE813A.1020501@oracle.com> On 1/7/13 3:23 AM, Jaroslav Bachorik wrote: > On 01/04/2013 11:37 PM, Kelly O'Hair wrote: >> I suspect it is not hanging because it does not exist, but that some other windows process has it's hands on it. >> This is the stdout file from the server being started up right? >> Could the server from a previous test run be still running? > > Exactly. Amy confirmed this and provided a patch which resolves the > hanging problem. > > The update patch is at > http://cr.openjdk.java.net/~jbachorik/8005472/webrev.01 Hi Jaroslav, The change to remove the parentheses from around the server program looks right. It avoids forking an extra process (at least in some shells) and lets $! refer to the actual JVM, not an intermediate shell process. The rm -f from Kelly's suggestion is good too. But there are other things wrong with the script. I don't think they could cause hanging, but they could cause the script to fail in unforeseen ways, or even to report success incorrectly. One problem is introduced by the change, where the Server's stderr is also redirected into $URL_PATH along with stdout. This means that if the Server program reports any errors, they'll get mixed into the URL_PATH file instead of appearing in the test log. The URL_PATH file's contents is never reported, so these error messages will be invisible. The exit status of some of the critical commands (such as the compilations) isn't checked, so if javac fails for some reason, the test might not report failure. Instead, some weird error might or might not be reported later (though one will still see the javac errors in the log). I don't think the sleep at line 80 is necessary, since the client runs synchronously and should have exited by this point. The wait loop checking for the existence of the URL_PATH file doesn't actually guarantee that the server is running or has initialized yet. The file is actually created by the shell before the Server JVM starts up. Thus, runClient might try to read from it before the server has written anything to it. Or, as mentioned above, the server might have written some error messages into the URL_PATH file instead of the expected contents. Thus, the contents of the JMXURL variable can quite possibly be incorrect. If this occurs, what will happen when the client runs? It may emit some error message, and this will be filtered out by the grep pipeline. Thus, HAS_ERRORS might end up empty, and the test will report passing, even though everything has failed! For this changeset I'd recommend at a minimum removing the redirection of stderr to URL_PATH. If the server fails we'll at least see errors in the test log. For checking the notification message, is there a way to modify the client to report an exit status or throw an exception? Throwing an exception from main() will exit the JVM with a nonzero status, so this can be checked more easily from the script. I think this is less error-prone than grepping the output for a specific error message. The test should fail if there is *any* error; it should not succeed if an expected error is absent. You might consider having jtreg build the client and server classes. This might simplify some of the setup. Also, jtreg is meticulous about aborting the test if any compilations fail, so it takes care of that for you. It would be nice if there were a better way to have the client rendezvous with the server. I hate to suggest it, but sleeping unconditionally after starting the server is probably necessary. Anything more robust probably requires rearchitecting the test, though. Sorry to dump all this on you. But one of the shell-based RMI tests suffers from *exactly* the same pathologies. (I have yet to fix it.) Unfortunately, I believe that there are a lot of other shell-based tests in the test suite that have similar problems. The lesson here is that writing reliable shell tests is a lot harder than it seems. Thanks, s'marks From jaroslav.bachorik at oracle.com Thu Jan 10 00:56:42 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 10 Jan 2013 09:56:42 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50ED7DEF.9020108@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> <50ED7436.1020205@oracle.com> <50ED7801.8080704@oracle.com> <50ED7DEF.9020108@oracle.com> Message-ID: <50EE824A.8020106@oracle.com> On 01/09/2013 03:25 PM, shanliang wrote: > Jaroslav Bachorik wrote: >> On 01/09/2013 02:44 PM, shanliang wrote: >> >>> Let's forget the JMX implementation at first. If an MBean is >>> unregistered, a user at client side calls "removeNotificationListener" >>> on the MBean, what should happen? if the user calls "isRegistered" on >>> the MBean, what should happen? >>> >>> I have done 2 tests, I used only one thread: >>> >>> 1) >>> ...... >>> localServer.unregisterMBean(myMBean); >>> boolean isRegistered = remoteClientServer.isRegistered(myMBean)); >>> >>> I got isRegistered = false; >>> >>> 2) >>> ...... >>> localServer.unregisterMBean(myMBean); >>> System.out.println("isRegistered = >>> "+remoteClientServer.sRegistered(myMBean)); >>> remoteClientServer.removeNotificationListener(myMBean, listener); >>> >>> I did not get an exception. >>> >>> The 1) told that the client could know the MBean was unregistered, then >>> the client should throw an exception for the call of >>> "removeNotificationListener" in 2). >>> >> >> Yes, but then it would not test the listener leakage as it was supposed >> to test but rather the fact that the client throws the appropriate >> exception. The fact that the mbean was unregistered does not necessarily >> mean that the listeners were released. The main problem remains - the >> listeners are being cleaned-up asynchronously and the clean-up process >> might race against the other uses of the JMX API. >> > client.removeNotificationListener is not a right way here to test > listener leak, we could use some other ways, for example we keep the > listener in a weak reference, then after the mbean is removed, the weak > reference should be empty after some time. Another way is like > DeadListenerTest does to check whether clean has done at server side: > use reflection to get the "listenerMap" at server side and make sure it > is empty, but this need to add a private method to the class > ClientNotifForwarder. There will still be problems with timing. You need either to wait for the GC to kick in to clean up the weak ref. And the listenerMap will not be purged of the unregistered MBean listeners until the notification is generated, processed on the ClientNotificationForwarder and forwarded to the server. So there goes the timing issue again. The problem is that the "unregisterMBean" operation does not guarantee that the listeners have been unregistered at the time it returns. So, one way or the other we will need to wait an arbitrary amount of time before checking for the memory leak. -JB- > > I think we have 3 things to do here: > 1) modify the test to not use removeNotificationListener for testing > listener leak > 2) create a new bug about a client does not throw an exception after an > mbean is unregistered > 3) create a bug about a client does not throw a same exception as at > server side. > > I will do 2) and 3), if you like you can continue 1), it might need to > do fix also in the JMX implementation. > > Shanliang >> >>> The test "DeadListenerTest" got passed in some machines because of the >>> timeout for waiting a notification. I think its failure just tells a new >>> bug. >>> >>> To set a longer timeout just hides the real bug, and the test might fail >>> again one day if running condition is changed and you might need longer >>> timeout again. >>> >> >> Yes, I agree with you that extending the timeout just lessens the >> likelihood of the race condition and does not prevent it. >> >> >>> Shanliang >>> >>> Jaroslav Bachorik wrote: >>> >>>> On 01/09/2013 11:08 AM, shanliang wrote: >>>> >>>> >>>>> Jaroslav Bachorik wrote: >>>>> >>>>>> On 01/09/2013 09:40 AM, shanliang wrote: >>>>>> >>>>>> >>>>>>> I still have no idea why the test failed, but I do not see why a >>>>>>> longer >>>>>>> timeout can fix the test. Have you reproduced the problem and tested >>>>>>> your fix? if yes then possible the long timeout hided a real >>>>>>> problem. >>>>>>> >>>>>> Yes, I can reproduce the problem (using the fastbuild bits and -Xcomp >>>>>> switch) and verify that the fix makes the test pass. >>>>>> >>>>>> The ClientNotifForwarder scans the notifications for >>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>>>>> appropriate notification listeners in a separate thread. Thus, >>>>>> calling >>>>>> "removeNotificationListener" on the main thread is prone to racing. >>>>>> >>>>> It is true that ClientNotifForwarder scans the notifications for >>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>>>> appropriate notification listeners in a separate thread. This is for a >>>>> client connection to do clean if a user never calls >>>>> removeNotificationListener. >>>>> >>>>> But calling directly removeNotificationListener from a client should >>>>> still get exception if the clean has not been done. As I said, if the >>>>> client checked and found the listener was still there, then the client >>>>> sent a request to its server to remove the listener at server side, >>>>> the >>>>> server should find that the MBean in question was not registered, >>>>> so the >>>>> server should throw an exception. The bug might be here. >>>>> >>>> This won't work. The server side listeners are removed upon receiving >>>> the "unregistered" notification which is delivered from the >>>> ClientNotificationForwarder and it may have not run yet (since it runs >>>> in a separate executor thread). The result is that the attempt to >>>> remove >>>> the notification listener on the server will succeed as well failing >>>> the >>>> test subsequently. >>>> >>>> -JB- >>>> >>>> >>>> >>>>> Shanliang >>>>> >>>>>> >>>>>> >>>>>>> The timeout you made longer was used to wait a notification which >>>>>>> should >>>>>>> never arrive. >>>>>>> >>>>>> Well, it can be used to allow more time to process the "unregister" >>>>>> notification, too. >>>>>> >>>>>> When I think more of this I am more inclined to fix the race >>>>>> condition. >>>>>> An updated webrev will follow. >>>>>> >>>>>> >>>>>> >>>>>>> To remove a listener from a client side, we did: >>>>>>> 1) at client side, check whether it was added in the client side >>>>>>> 2) at server side, check whether the MBean in question was >>>>>>> registered in >>>>>>> the MBeanServer (!!!) >>>>>>> 3) at server side, check whether the listener was added. >>>>>>> >>>>>>> So 2) tells that we did not rely on a "unregister" notification. >>>>>>> Anyway, >>>>>>> if you use a SAME thread to call "unregister" operation to >>>>>>> unregister an >>>>>>> mbean, then any following call (without any time break) to use the >>>>>>> mbean >>>>>>> should fail, like "removeNotificationListener", "isRegistered" etc. >>>>>>> >>>>>>> I do see a bug here, if we remove a listener from a non-existing >>>>>>> MBeam, >>>>>>> we get "ListenerNotFoundException" at a client side, but get >>>>>>> "InstanceNotFoundException" at server side, I think we should >>>>>>> create a >>>>>>> bug, because both implemented the same interface >>>>>>> MBeanServerConnection. >>>>>>> >>>>>> Yes, it is rather inconsistent. >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>> >>>>>>> Shanliang >>>>>>> >>>>>>> Jaroslav Bachorik wrote: >>>>>>> >>>>>>>> Looking for review and a sponsor. >>>>>>>> >>>>>>>> Webrev at http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>>>>>> >>>>>>>> In this issue the timing is the problem. >>>>>>>> MBeanServer.unregisterMBean() >>>>>>>> fires the "unregister" notification which is sent to the server >>>>>>>> asynchronously. Thus it may happen that the "unregister" >>>>>>>> notification >>>>>>>> has not been yet processed at the time of invoking >>>>>>>> removeNotificationListener() and the notification listeners hasn't >>>>>>>> been >>>>>>>> cleaned up leading to the test failure. >>>>>>>> >>>>>>>> There is no synchronization between the client and the server and >>>>>>>> such >>>>>>>> race condition can occur occasionally. Normally, the execution is >>>>>>>> fast >>>>>>>> enough to behave like the "unregister" notification is processed >>>>>>>> synchronously with the unregisterMBean() operation but it seems >>>>>>>> that >>>>>>>> using fastdebug Server VM bits with the -Xcomp option strains >>>>>>>> the CPU >>>>>>>> enough to make this problem appear. >>>>>>>> >>>>>>>> There is no proper fix for this - the only thing that work is >>>>>>>> waiting a >>>>>>>> bit longer in the main thread to give the notification processing >>>>>>>> thread >>>>>>>> some time to clean up the listeners. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>> >>>>> >>>> >>> >> >> > > From shanliang.jiang at oracle.com Thu Jan 10 01:05:11 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 10 Jan 2013 10:05:11 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50EE824A.8020106@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> <50ED7436.1020205@oracle.com> <50ED7801.8080704@oracle.com> <50ED7DEF.9020108@oracle.com> <50EE824A.8020106@oracle.com> Message-ID: <50EE8447.50901@oracle.com> Jaroslav Bachorik wrote: > On 01/09/2013 03:25 PM, shanliang wrote: > >> Jaroslav Bachorik wrote: >> >>> On 01/09/2013 02:44 PM, shanliang wrote: >>> >>> >>>> Let's forget the JMX implementation at first. If an MBean is >>>> unregistered, a user at client side calls "removeNotificationListener" >>>> on the MBean, what should happen? if the user calls "isRegistered" on >>>> the MBean, what should happen? >>>> >>>> I have done 2 tests, I used only one thread: >>>> >>>> 1) >>>> ...... >>>> localServer.unregisterMBean(myMBean); >>>> boolean isRegistered = remoteClientServer.isRegistered(myMBean)); >>>> >>>> I got isRegistered = false; >>>> >>>> 2) >>>> ...... >>>> localServer.unregisterMBean(myMBean); >>>> System.out.println("isRegistered = >>>> "+remoteClientServer.sRegistered(myMBean)); >>>> remoteClientServer.removeNotificationListener(myMBean, listener); >>>> >>>> I did not get an exception. >>>> >>>> The 1) told that the client could know the MBean was unregistered, then >>>> the client should throw an exception for the call of >>>> "removeNotificationListener" in 2). >>>> >>>> >>> Yes, but then it would not test the listener leakage as it was supposed >>> to test but rather the fact that the client throws the appropriate >>> exception. The fact that the mbean was unregistered does not necessarily >>> mean that the listeners were released. The main problem remains - the >>> listeners are being cleaned-up asynchronously and the clean-up process >>> might race against the other uses of the JMX API. >>> >>> >> client.removeNotificationListener is not a right way here to test >> listener leak, we could use some other ways, for example we keep the >> listener in a weak reference, then after the mbean is removed, the weak >> reference should be empty after some time. Another way is like >> DeadListenerTest does to check whether clean has done at server side: >> use reflection to get the "listenerMap" at server side and make sure it >> is empty, but this need to add a private method to the class >> ClientNotifForwarder. >> > > There will still be problems with timing. You need either to wait for > the GC to kick in to clean up the weak ref. And the listenerMap will not > be purged of the unregistered MBean listeners until the notification is > generated, processed on the ClientNotificationForwarder and forwarded to > the server. So there goes the timing issue again. > > The problem is that the "unregisterMBean" operation does not guarantee > that the listeners have been unregistered at the time it returns. So, > one way or the other we will need to wait an arbitrary amount of time > before checking for the memory leak. > Yes we need to wait, but you can use a cycle like: long maxWaitingTime = 3000; long startTime = System.currentTimeMillis(); while ( weakReference.get != null && System.currentTimeMillis() < startTime + maxWaitingTime) { System.gc(); Thread.sleep(100); System.gc(); } if (weakReference.get != null) { // failed } Shanliang > -JB- > > >> I think we have 3 things to do here: >> 1) modify the test to not use removeNotificationListener for testing >> listener leak >> 2) create a new bug about a client does not throw an exception after an >> mbean is unregistered >> 3) create a bug about a client does not throw a same exception as at >> server side. >> >> I will do 2) and 3), if you like you can continue 1), it might need to >> do fix also in the JMX implementation. >> >> Shanliang >> >>> >>> >>>> The test "DeadListenerTest" got passed in some machines because of the >>>> timeout for waiting a notification. I think its failure just tells a new >>>> bug. >>>> >>>> To set a longer timeout just hides the real bug, and the test might fail >>>> again one day if running condition is changed and you might need longer >>>> timeout again. >>>> >>>> >>> Yes, I agree with you that extending the timeout just lessens the >>> likelihood of the race condition and does not prevent it. >>> >>> >>> >>>> Shanliang >>>> >>>> Jaroslav Bachorik wrote: >>>> >>>> >>>>> On 01/09/2013 11:08 AM, shanliang wrote: >>>>> >>>>> >>>>> >>>>>> Jaroslav Bachorik wrote: >>>>>> >>>>>> >>>>>>> On 01/09/2013 09:40 AM, shanliang wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I still have no idea why the test failed, but I do not see why a >>>>>>>> longer >>>>>>>> timeout can fix the test. Have you reproduced the problem and tested >>>>>>>> your fix? if yes then possible the long timeout hided a real >>>>>>>> problem. >>>>>>>> >>>>>>>> >>>>>>> Yes, I can reproduce the problem (using the fastbuild bits and -Xcomp >>>>>>> switch) and verify that the fix makes the test pass. >>>>>>> >>>>>>> The ClientNotifForwarder scans the notifications for >>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>>>>>> appropriate notification listeners in a separate thread. Thus, >>>>>>> calling >>>>>>> "removeNotificationListener" on the main thread is prone to racing. >>>>>>> >>>>>>> >>>>>> It is true that ClientNotifForwarder scans the notifications for >>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>>>>> appropriate notification listeners in a separate thread. This is for a >>>>>> client connection to do clean if a user never calls >>>>>> removeNotificationListener. >>>>>> >>>>>> But calling directly removeNotificationListener from a client should >>>>>> still get exception if the clean has not been done. As I said, if the >>>>>> client checked and found the listener was still there, then the client >>>>>> sent a request to its server to remove the listener at server side, >>>>>> the >>>>>> server should find that the MBean in question was not registered, >>>>>> so the >>>>>> server should throw an exception. The bug might be here. >>>>>> >>>>>> >>>>> This won't work. The server side listeners are removed upon receiving >>>>> the "unregistered" notification which is delivered from the >>>>> ClientNotificationForwarder and it may have not run yet (since it runs >>>>> in a separate executor thread). The result is that the attempt to >>>>> remove >>>>> the notification listener on the server will succeed as well failing >>>>> the >>>>> test subsequently. >>>>> >>>>> -JB- >>>>> >>>>> >>>>> >>>>> >>>>>> Shanliang >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The timeout you made longer was used to wait a notification which >>>>>>>> should >>>>>>>> never arrive. >>>>>>>> >>>>>>>> >>>>>>> Well, it can be used to allow more time to process the "unregister" >>>>>>> notification, too. >>>>>>> >>>>>>> When I think more of this I am more inclined to fix the race >>>>>>> condition. >>>>>>> An updated webrev will follow. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> To remove a listener from a client side, we did: >>>>>>>> 1) at client side, check whether it was added in the client side >>>>>>>> 2) at server side, check whether the MBean in question was >>>>>>>> registered in >>>>>>>> the MBeanServer (!!!) >>>>>>>> 3) at server side, check whether the listener was added. >>>>>>>> >>>>>>>> So 2) tells that we did not rely on a "unregister" notification. >>>>>>>> Anyway, >>>>>>>> if you use a SAME thread to call "unregister" operation to >>>>>>>> unregister an >>>>>>>> mbean, then any following call (without any time break) to use the >>>>>>>> mbean >>>>>>>> should fail, like "removeNotificationListener", "isRegistered" etc. >>>>>>>> >>>>>>>> I do see a bug here, if we remove a listener from a non-existing >>>>>>>> MBeam, >>>>>>>> we get "ListenerNotFoundException" at a client side, but get >>>>>>>> "InstanceNotFoundException" at server side, I think we should >>>>>>>> create a >>>>>>>> bug, because both implemented the same interface >>>>>>>> MBeanServerConnection. >>>>>>>> >>>>>>>> >>>>>>> Yes, it is rather inconsistent. >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Shanliang >>>>>>>> >>>>>>>> Jaroslav Bachorik wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Looking for review and a sponsor. >>>>>>>>> >>>>>>>>> Webrev at http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>>>>>>> >>>>>>>>> In this issue the timing is the problem. >>>>>>>>> MBeanServer.unregisterMBean() >>>>>>>>> fires the "unregister" notification which is sent to the server >>>>>>>>> asynchronously. Thus it may happen that the "unregister" >>>>>>>>> notification >>>>>>>>> has not been yet processed at the time of invoking >>>>>>>>> removeNotificationListener() and the notification listeners hasn't >>>>>>>>> been >>>>>>>>> cleaned up leading to the test failure. >>>>>>>>> >>>>>>>>> There is no synchronization between the client and the server and >>>>>>>>> such >>>>>>>>> race condition can occur occasionally. Normally, the execution is >>>>>>>>> fast >>>>>>>>> enough to behave like the "unregister" notification is processed >>>>>>>>> synchronously with the unregisterMBean() operation but it seems >>>>>>>>> that >>>>>>>>> using fastdebug Server VM bits with the -Xcomp option strains >>>>>>>>> the CPU >>>>>>>>> enough to make this problem appear. >>>>>>>>> >>>>>>>>> There is no proper fix for this - the only thing that work is >>>>>>>>> waiting a >>>>>>>>> bit longer in the main thread to give the notification processing >>>>>>>>> thread >>>>>>>>> some time to clean up the listeners. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130110/c9203ef0/attachment-0001.html From stuart.marks at oracle.com Thu Jan 10 01:15:42 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 10 Jan 2013 01:15:42 -0800 Subject: jmx-dev [PATCH] JDK-8005472: com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh failed on windows In-Reply-To: <50EE813A.1020501@oracle.com> References: <50E16BA8.40203@oracle.com> <682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com> <50EAB014.30805@oracle.com> <50EE813A.1020501@oracle.com> Message-ID: <50EE86BE.5090101@oracle.com> On 1/10/13 12:52 AM, Stuart Marks wrote: > The exit status of some of the critical commands (such as the compilations) > isn't checked, so if javac fails for some reason, the test might not report > failure. Instead, some weird error might or might not be reported later (though > one will still see the javac errors in the log). Adding set -e near the top of the script will enable a feature where the script will exit if any command gives a nonzero exit status. This avoids having to do a lot of tedious error checking of commands that just "do stuff" (like mkdir, rm, javac) but beware, some commands give a non-zero exit status somewhat unexpectedly, like grep. s'marks From jaroslav.bachorik at oracle.com Thu Jan 10 01:34:36 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 10 Jan 2013 10:34:36 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50EE8447.50901@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> <50ED7436.1020205@oracle.com> <50ED7801.8080704@oracle.com> <50ED7DEF.9020108@oracle.com> <50EE824A.8020106@oracle.com> <50EE8447.50901@oracle.com> Message-ID: <50EE8B2C.9030900@oracle.com> On 01/10/2013 10:05 AM, shanliang wrote: > Jaroslav Bachorik wrote: >> On 01/09/2013 03:25 PM, shanliang wrote: >> >>> Jaroslav Bachorik wrote: >>> >>>> On 01/09/2013 02:44 PM, shanliang wrote: >>>> >>>> >>>>> Let's forget the JMX implementation at first. If an MBean is >>>>> unregistered, a user at client side calls "removeNotificationListener" >>>>> on the MBean, what should happen? if the user calls "isRegistered" on >>>>> the MBean, what should happen? >>>>> >>>>> I have done 2 tests, I used only one thread: >>>>> >>>>> 1) >>>>> ...... >>>>> localServer.unregisterMBean(myMBean); >>>>> boolean isRegistered = remoteClientServer.isRegistered(myMBean)); >>>>> >>>>> I got isRegistered = false; >>>>> >>>>> 2) >>>>> ...... >>>>> localServer.unregisterMBean(myMBean); >>>>> System.out.println("isRegistered = >>>>> "+remoteClientServer.sRegistered(myMBean)); >>>>> remoteClientServer.removeNotificationListener(myMBean, listener); >>>>> >>>>> I did not get an exception. >>>>> >>>>> The 1) told that the client could know the MBean was unregistered, >>>>> then >>>>> the client should throw an exception for the call of >>>>> "removeNotificationListener" in 2). >>>>> >>>> Yes, but then it would not test the listener leakage as it was supposed >>>> to test but rather the fact that the client throws the appropriate >>>> exception. The fact that the mbean was unregistered does not >>>> necessarily >>>> mean that the listeners were released. The main problem remains - the >>>> listeners are being cleaned-up asynchronously and the clean-up process >>>> might race against the other uses of the JMX API. >>>> >>> client.removeNotificationListener is not a right way here to test >>> listener leak, we could use some other ways, for example we keep the >>> listener in a weak reference, then after the mbean is removed, the weak >>> reference should be empty after some time. Another way is like >>> DeadListenerTest does to check whether clean has done at server side: >>> use reflection to get the "listenerMap" at server side and make sure it >>> is empty, but this need to add a private method to the class >>> ClientNotifForwarder. >>> >> >> There will still be problems with timing. You need either to wait for >> the GC to kick in to clean up the weak ref. And the listenerMap will not >> be purged of the unregistered MBean listeners until the notification is >> generated, processed on the ClientNotificationForwarder and forwarded to >> the server. So there goes the timing issue again. >> >> The problem is that the "unregisterMBean" operation does not guarantee >> that the listeners have been unregistered at the time it returns. So, >> one way or the other we will need to wait an arbitrary amount of time >> before checking for the memory leak. >> > Yes we need to wait, but you can use a cycle like: > long maxWaitingTime = 3000; > long startTime = System.currentTimeMillis(); > while ( weakReference.get != null > && System.currentTimeMillis() < startTime + > maxWaitingTime) { > System.gc(); > Thread.sleep(100); > System.gc(); > } > > if (weakReference.get != null) { > // failed > } > Sounds reasonable. I'll update the test. -JB- > Shanliang >> -JB- >> >> >>> I think we have 3 things to do here: >>> 1) modify the test to not use removeNotificationListener for testing >>> listener leak >>> 2) create a new bug about a client does not throw an exception after an >>> mbean is unregistered >>> 3) create a bug about a client does not throw a same exception as at >>> server side. >>> >>> I will do 2) and 3), if you like you can continue 1), it might need to >>> do fix also in the JMX implementation. >>> >>> Shanliang >>> >>>> >>>> >>>>> The test "DeadListenerTest" got passed in some machines because of the >>>>> timeout for waiting a notification. I think its failure just tells >>>>> a new >>>>> bug. >>>>> >>>>> To set a longer timeout just hides the real bug, and the test might >>>>> fail >>>>> again one day if running condition is changed and you might need >>>>> longer >>>>> timeout again. >>>>> >>>> Yes, I agree with you that extending the timeout just lessens the >>>> likelihood of the race condition and does not prevent it. >>>> >>>> >>>> >>>>> Shanliang >>>>> >>>>> Jaroslav Bachorik wrote: >>>>> >>>>>> On 01/09/2013 11:08 AM, shanliang wrote: >>>>>> >>>>>> >>>>>>> Jaroslav Bachorik wrote: >>>>>>> >>>>>>>> On 01/09/2013 09:40 AM, shanliang wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I still have no idea why the test failed, but I do not see why a >>>>>>>>> longer >>>>>>>>> timeout can fix the test. Have you reproduced the problem and >>>>>>>>> tested >>>>>>>>> your fix? if yes then possible the long timeout hided a real >>>>>>>>> problem. >>>>>>>>> >>>>>>>> Yes, I can reproduce the problem (using the fastbuild bits and >>>>>>>> -Xcomp >>>>>>>> switch) and verify that the fix makes the test pass. >>>>>>>> >>>>>>>> The ClientNotifForwarder scans the notifications for >>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>>>>>>> appropriate notification listeners in a separate thread. Thus, >>>>>>>> calling >>>>>>>> "removeNotificationListener" on the main thread is prone to racing. >>>>>>>> >>>>>>> It is true that ClientNotifForwarder scans the notifications for >>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>>>>>> appropriate notification listeners in a separate thread. This is >>>>>>> for a >>>>>>> client connection to do clean if a user never calls >>>>>>> removeNotificationListener. >>>>>>> >>>>>>> But calling directly removeNotificationListener from a client should >>>>>>> still get exception if the clean has not been done. As I said, if >>>>>>> the >>>>>>> client checked and found the listener was still there, then the >>>>>>> client >>>>>>> sent a request to its server to remove the listener at server side, >>>>>>> the >>>>>>> server should find that the MBean in question was not registered, >>>>>>> so the >>>>>>> server should throw an exception. The bug might be here. >>>>>>> >>>>>> This won't work. The server side listeners are removed upon receiving >>>>>> the "unregistered" notification which is delivered from the >>>>>> ClientNotificationForwarder and it may have not run yet (since it >>>>>> runs >>>>>> in a separate executor thread). The result is that the attempt to >>>>>> remove >>>>>> the notification listener on the server will succeed as well failing >>>>>> the >>>>>> test subsequently. >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>> >>>>>>> Shanliang >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The timeout you made longer was used to wait a notification which >>>>>>>>> should >>>>>>>>> never arrive. >>>>>>>>> >>>>>>>> Well, it can be used to allow more time to process the "unregister" >>>>>>>> notification, too. >>>>>>>> >>>>>>>> When I think more of this I am more inclined to fix the race >>>>>>>> condition. >>>>>>>> An updated webrev will follow. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> To remove a listener from a client side, we did: >>>>>>>>> 1) at client side, check whether it was added in the client side >>>>>>>>> 2) at server side, check whether the MBean in question was >>>>>>>>> registered in >>>>>>>>> the MBeanServer (!!!) >>>>>>>>> 3) at server side, check whether the listener was added. >>>>>>>>> >>>>>>>>> So 2) tells that we did not rely on a "unregister" notification. >>>>>>>>> Anyway, >>>>>>>>> if you use a SAME thread to call "unregister" operation to >>>>>>>>> unregister an >>>>>>>>> mbean, then any following call (without any time break) to use the >>>>>>>>> mbean >>>>>>>>> should fail, like "removeNotificationListener", "isRegistered" >>>>>>>>> etc. >>>>>>>>> >>>>>>>>> I do see a bug here, if we remove a listener from a non-existing >>>>>>>>> MBeam, >>>>>>>>> we get "ListenerNotFoundException" at a client side, but get >>>>>>>>> "InstanceNotFoundException" at server side, I think we should >>>>>>>>> create a >>>>>>>>> bug, because both implemented the same interface >>>>>>>>> MBeanServerConnection. >>>>>>>>> >>>>>>>> Yes, it is rather inconsistent. >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Shanliang >>>>>>>>> >>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>> >>>>>>>>>> Looking for review and a sponsor. >>>>>>>>>> >>>>>>>>>> Webrev at http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>>>>>>>> >>>>>>>>>> In this issue the timing is the problem. >>>>>>>>>> MBeanServer.unregisterMBean() >>>>>>>>>> fires the "unregister" notification which is sent to the server >>>>>>>>>> asynchronously. Thus it may happen that the "unregister" >>>>>>>>>> notification >>>>>>>>>> has not been yet processed at the time of invoking >>>>>>>>>> removeNotificationListener() and the notification listeners >>>>>>>>>> hasn't >>>>>>>>>> been >>>>>>>>>> cleaned up leading to the test failure. >>>>>>>>>> >>>>>>>>>> There is no synchronization between the client and the server and >>>>>>>>>> such >>>>>>>>>> race condition can occur occasionally. Normally, the execution is >>>>>>>>>> fast >>>>>>>>>> enough to behave like the "unregister" notification is processed >>>>>>>>>> synchronously with the unregisterMBean() operation but it seems >>>>>>>>>> that >>>>>>>>>> using fastdebug Server VM bits with the -Xcomp option strains >>>>>>>>>> the CPU >>>>>>>>>> enough to make this problem appear. >>>>>>>>>> >>>>>>>>>> There is no proper fix for this - the only thing that work is >>>>>>>>>> waiting a >>>>>>>>>> bit longer in the main thread to give the notification processing >>>>>>>>>> thread >>>>>>>>>> some time to clean up the listeners. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > > From jaroslav.bachorik at oracle.com Thu Jan 10 03:41:44 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 10 Jan 2013 12:41:44 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50EE8447.50901@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> <50ED7436.1020205@oracle.com> <50ED7801.8080704@oracle.com> <50ED7DEF.9020108@oracle.com> <50EE824A.8020106@oracle.com> <50EE8447.50901@oracle.com> Message-ID: <50EEA8F8.7090007@oracle.com> On 01/10/2013 10:05 AM, shanliang wrote: > Jaroslav Bachorik wrote: >> On 01/09/2013 03:25 PM, shanliang wrote: >> >>> Jaroslav Bachorik wrote: >>> >>>> On 01/09/2013 02:44 PM, shanliang wrote: >>>> >>>> >>>>> Let's forget the JMX implementation at first. If an MBean is >>>>> unregistered, a user at client side calls "removeNotificationListener" >>>>> on the MBean, what should happen? if the user calls "isRegistered" on >>>>> the MBean, what should happen? >>>>> >>>>> I have done 2 tests, I used only one thread: >>>>> >>>>> 1) >>>>> ...... >>>>> localServer.unregisterMBean(myMBean); >>>>> boolean isRegistered = remoteClientServer.isRegistered(myMBean)); >>>>> >>>>> I got isRegistered = false; >>>>> >>>>> 2) >>>>> ...... >>>>> localServer.unregisterMBean(myMBean); >>>>> System.out.println("isRegistered = >>>>> "+remoteClientServer.sRegistered(myMBean)); >>>>> remoteClientServer.removeNotificationListener(myMBean, listener); >>>>> >>>>> I did not get an exception. >>>>> >>>>> The 1) told that the client could know the MBean was unregistered, >>>>> then >>>>> the client should throw an exception for the call of >>>>> "removeNotificationListener" in 2). >>>>> >>>> Yes, but then it would not test the listener leakage as it was supposed >>>> to test but rather the fact that the client throws the appropriate >>>> exception. The fact that the mbean was unregistered does not >>>> necessarily >>>> mean that the listeners were released. The main problem remains - the >>>> listeners are being cleaned-up asynchronously and the clean-up process >>>> might race against the other uses of the JMX API. >>>> >>> client.removeNotificationListener is not a right way here to test >>> listener leak, we could use some other ways, for example we keep the >>> listener in a weak reference, then after the mbean is removed, the weak >>> reference should be empty after some time. Another way is like >>> DeadListenerTest does to check whether clean has done at server side: >>> use reflection to get the "listenerMap" at server side and make sure it >>> is empty, but this need to add a private method to the class >>> ClientNotifForwarder. >>> >> >> There will still be problems with timing. You need either to wait for >> the GC to kick in to clean up the weak ref. And the listenerMap will not >> be purged of the unregistered MBean listeners until the notification is >> generated, processed on the ClientNotificationForwarder and forwarded to >> the server. So there goes the timing issue again. >> >> The problem is that the "unregisterMBean" operation does not guarantee >> that the listeners have been unregistered at the time it returns. So, >> one way or the other we will need to wait an arbitrary amount of time >> before checking for the memory leak. >> > Yes we need to wait, but you can use a cycle like: > long maxWaitingTime = 3000; > long startTime = System.currentTimeMillis(); > while ( weakReference.get != null > && System.currentTimeMillis() < startTime + > maxWaitingTime) { > System.gc(); > Thread.sleep(100); > System.gc(); > } > > if (weakReference.get != null) { > // failed > } Still you need an arbitrary timeout which might be reached under extreme conditions making this test to fail intermittently. But I'd say that's the nature of tests for memory leak fixes, due to the unpredictable nature of the GC runs. Unless you take a heap dump and do a reachability analysis you can not be sure whether a reference is dangling somwehwere or it just hasn't been collected yet :/ -JB- > > Shanliang >> -JB- >> >> >>> I think we have 3 things to do here: >>> 1) modify the test to not use removeNotificationListener for testing >>> listener leak >>> 2) create a new bug about a client does not throw an exception after an >>> mbean is unregistered >>> 3) create a bug about a client does not throw a same exception as at >>> server side. >>> >>> I will do 2) and 3), if you like you can continue 1), it might need to >>> do fix also in the JMX implementation. >>> >>> Shanliang >>> >>>> >>>> >>>>> The test "DeadListenerTest" got passed in some machines because of the >>>>> timeout for waiting a notification. I think its failure just tells >>>>> a new >>>>> bug. >>>>> >>>>> To set a longer timeout just hides the real bug, and the test might >>>>> fail >>>>> again one day if running condition is changed and you might need >>>>> longer >>>>> timeout again. >>>>> >>>> Yes, I agree with you that extending the timeout just lessens the >>>> likelihood of the race condition and does not prevent it. >>>> >>>> >>>> >>>>> Shanliang >>>>> >>>>> Jaroslav Bachorik wrote: >>>>> >>>>>> On 01/09/2013 11:08 AM, shanliang wrote: >>>>>> >>>>>> >>>>>>> Jaroslav Bachorik wrote: >>>>>>> >>>>>>>> On 01/09/2013 09:40 AM, shanliang wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I still have no idea why the test failed, but I do not see why a >>>>>>>>> longer >>>>>>>>> timeout can fix the test. Have you reproduced the problem and >>>>>>>>> tested >>>>>>>>> your fix? if yes then possible the long timeout hided a real >>>>>>>>> problem. >>>>>>>>> >>>>>>>> Yes, I can reproduce the problem (using the fastbuild bits and >>>>>>>> -Xcomp >>>>>>>> switch) and verify that the fix makes the test pass. >>>>>>>> >>>>>>>> The ClientNotifForwarder scans the notifications for >>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>>>>>>> appropriate notification listeners in a separate thread. Thus, >>>>>>>> calling >>>>>>>> "removeNotificationListener" on the main thread is prone to racing. >>>>>>>> >>>>>>> It is true that ClientNotifForwarder scans the notifications for >>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>>>>>> appropriate notification listeners in a separate thread. This is >>>>>>> for a >>>>>>> client connection to do clean if a user never calls >>>>>>> removeNotificationListener. >>>>>>> >>>>>>> But calling directly removeNotificationListener from a client should >>>>>>> still get exception if the clean has not been done. As I said, if >>>>>>> the >>>>>>> client checked and found the listener was still there, then the >>>>>>> client >>>>>>> sent a request to its server to remove the listener at server side, >>>>>>> the >>>>>>> server should find that the MBean in question was not registered, >>>>>>> so the >>>>>>> server should throw an exception. The bug might be here. >>>>>>> >>>>>> This won't work. The server side listeners are removed upon receiving >>>>>> the "unregistered" notification which is delivered from the >>>>>> ClientNotificationForwarder and it may have not run yet (since it >>>>>> runs >>>>>> in a separate executor thread). The result is that the attempt to >>>>>> remove >>>>>> the notification listener on the server will succeed as well failing >>>>>> the >>>>>> test subsequently. >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>> >>>>>>> Shanliang >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The timeout you made longer was used to wait a notification which >>>>>>>>> should >>>>>>>>> never arrive. >>>>>>>>> >>>>>>>> Well, it can be used to allow more time to process the "unregister" >>>>>>>> notification, too. >>>>>>>> >>>>>>>> When I think more of this I am more inclined to fix the race >>>>>>>> condition. >>>>>>>> An updated webrev will follow. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> To remove a listener from a client side, we did: >>>>>>>>> 1) at client side, check whether it was added in the client side >>>>>>>>> 2) at server side, check whether the MBean in question was >>>>>>>>> registered in >>>>>>>>> the MBeanServer (!!!) >>>>>>>>> 3) at server side, check whether the listener was added. >>>>>>>>> >>>>>>>>> So 2) tells that we did not rely on a "unregister" notification. >>>>>>>>> Anyway, >>>>>>>>> if you use a SAME thread to call "unregister" operation to >>>>>>>>> unregister an >>>>>>>>> mbean, then any following call (without any time break) to use the >>>>>>>>> mbean >>>>>>>>> should fail, like "removeNotificationListener", "isRegistered" >>>>>>>>> etc. >>>>>>>>> >>>>>>>>> I do see a bug here, if we remove a listener from a non-existing >>>>>>>>> MBeam, >>>>>>>>> we get "ListenerNotFoundException" at a client side, but get >>>>>>>>> "InstanceNotFoundException" at server side, I think we should >>>>>>>>> create a >>>>>>>>> bug, because both implemented the same interface >>>>>>>>> MBeanServerConnection. >>>>>>>>> >>>>>>>> Yes, it is rather inconsistent. >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Shanliang >>>>>>>>> >>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>> >>>>>>>>>> Looking for review and a sponsor. >>>>>>>>>> >>>>>>>>>> Webrev at http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>>>>>>>> >>>>>>>>>> In this issue the timing is the problem. >>>>>>>>>> MBeanServer.unregisterMBean() >>>>>>>>>> fires the "unregister" notification which is sent to the server >>>>>>>>>> asynchronously. Thus it may happen that the "unregister" >>>>>>>>>> notification >>>>>>>>>> has not been yet processed at the time of invoking >>>>>>>>>> removeNotificationListener() and the notification listeners >>>>>>>>>> hasn't >>>>>>>>>> been >>>>>>>>>> cleaned up leading to the test failure. >>>>>>>>>> >>>>>>>>>> There is no synchronization between the client and the server and >>>>>>>>>> such >>>>>>>>>> race condition can occur occasionally. Normally, the execution is >>>>>>>>>> fast >>>>>>>>>> enough to behave like the "unregister" notification is processed >>>>>>>>>> synchronously with the unregisterMBean() operation but it seems >>>>>>>>>> that >>>>>>>>>> using fastdebug Server VM bits with the -Xcomp option strains >>>>>>>>>> the CPU >>>>>>>>>> enough to make this problem appear. >>>>>>>>>> >>>>>>>>>> There is no proper fix for this - the only thing that work is >>>>>>>>>> waiting a >>>>>>>>>> bit longer in the main thread to give the notification processing >>>>>>>>>> thread >>>>>>>>>> some time to clean up the listeners. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > > From shanliang.jiang at oracle.com Thu Jan 10 03:53:10 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 10 Jan 2013 12:53:10 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50EEA8F8.7090007@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> <50ED7436.1020205@oracle.com> <50ED7801.8080704@oracle.com> <50ED7DEF.9020108@oracle.com> <50EE824A.8020106@oracle.com> <50EE8447.50901@oracle.com> <50EEA8F8.7090007@oracle.com> Message-ID: <50EEABA6.6010203@oracle.com> Instead to wait GC, you can also to wait the MBeanServerNotification.UNREGISTRATION_NOTIFICATION, when you receive it, then your listener must be removed too. Of course this solution is implementation dependent, but the test is already implementation dependent. Shanliang Jaroslav Bachorik wrote: > On 01/10/2013 10:05 AM, shanliang wrote: > >> Jaroslav Bachorik wrote: >> >>> On 01/09/2013 03:25 PM, shanliang wrote: >>> >>> >>>> Jaroslav Bachorik wrote: >>>> >>>> >>>>> On 01/09/2013 02:44 PM, shanliang wrote: >>>>> >>>>> >>>>> >>>>>> Let's forget the JMX implementation at first. If an MBean is >>>>>> unregistered, a user at client side calls "removeNotificationListener" >>>>>> on the MBean, what should happen? if the user calls "isRegistered" on >>>>>> the MBean, what should happen? >>>>>> >>>>>> I have done 2 tests, I used only one thread: >>>>>> >>>>>> 1) >>>>>> ...... >>>>>> localServer.unregisterMBean(myMBean); >>>>>> boolean isRegistered = remoteClientServer.isRegistered(myMBean)); >>>>>> >>>>>> I got isRegistered = false; >>>>>> >>>>>> 2) >>>>>> ...... >>>>>> localServer.unregisterMBean(myMBean); >>>>>> System.out.println("isRegistered = >>>>>> "+remoteClientServer.sRegistered(myMBean)); >>>>>> remoteClientServer.removeNotificationListener(myMBean, listener); >>>>>> >>>>>> I did not get an exception. >>>>>> >>>>>> The 1) told that the client could know the MBean was unregistered, >>>>>> then >>>>>> the client should throw an exception for the call of >>>>>> "removeNotificationListener" in 2). >>>>>> >>>>>> >>>>> Yes, but then it would not test the listener leakage as it was supposed >>>>> to test but rather the fact that the client throws the appropriate >>>>> exception. The fact that the mbean was unregistered does not >>>>> necessarily >>>>> mean that the listeners were released. The main problem remains - the >>>>> listeners are being cleaned-up asynchronously and the clean-up process >>>>> might race against the other uses of the JMX API. >>>>> >>>>> >>>> client.removeNotificationListener is not a right way here to test >>>> listener leak, we could use some other ways, for example we keep the >>>> listener in a weak reference, then after the mbean is removed, the weak >>>> reference should be empty after some time. Another way is like >>>> DeadListenerTest does to check whether clean has done at server side: >>>> use reflection to get the "listenerMap" at server side and make sure it >>>> is empty, but this need to add a private method to the class >>>> ClientNotifForwarder. >>>> >>>> >>> There will still be problems with timing. You need either to wait for >>> the GC to kick in to clean up the weak ref. And the listenerMap will not >>> be purged of the unregistered MBean listeners until the notification is >>> generated, processed on the ClientNotificationForwarder and forwarded to >>> the server. So there goes the timing issue again. >>> >>> The problem is that the "unregisterMBean" operation does not guarantee >>> that the listeners have been unregistered at the time it returns. So, >>> one way or the other we will need to wait an arbitrary amount of time >>> before checking for the memory leak. >>> >>> >> Yes we need to wait, but you can use a cycle like: >> long maxWaitingTime = 3000; >> long startTime = System.currentTimeMillis(); >> while ( weakReference.get != null >> && System.currentTimeMillis() < startTime + >> maxWaitingTime) { >> System.gc(); >> Thread.sleep(100); >> System.gc(); >> } >> >> if (weakReference.get != null) { >> // failed >> } >> > > Still you need an arbitrary timeout which might be reached under extreme > conditions making this test to fail intermittently. But I'd say that's > the nature of tests for memory leak fixes, due to the unpredictable > nature of the GC runs. Unless you take a heap dump and do a reachability > analysis you can not be sure whether a reference is dangling somwehwere > or it just hasn't been collected yet :/ > > -JB- > > >> Shanliang >> >>> -JB- >>> >>> >>> >>>> I think we have 3 things to do here: >>>> 1) modify the test to not use removeNotificationListener for testing >>>> listener leak >>>> 2) create a new bug about a client does not throw an exception after an >>>> mbean is unregistered >>>> 3) create a bug about a client does not throw a same exception as at >>>> server side. >>>> >>>> I will do 2) and 3), if you like you can continue 1), it might need to >>>> do fix also in the JMX implementation. >>>> >>>> Shanliang >>>> >>>> >>>>> >>>>> >>>>> >>>>>> The test "DeadListenerTest" got passed in some machines because of the >>>>>> timeout for waiting a notification. I think its failure just tells >>>>>> a new >>>>>> bug. >>>>>> >>>>>> To set a longer timeout just hides the real bug, and the test might >>>>>> fail >>>>>> again one day if running condition is changed and you might need >>>>>> longer >>>>>> timeout again. >>>>>> >>>>>> >>>>> Yes, I agree with you that extending the timeout just lessens the >>>>> likelihood of the race condition and does not prevent it. >>>>> >>>>> >>>>> >>>>> >>>>>> Shanliang >>>>>> >>>>>> Jaroslav Bachorik wrote: >>>>>> >>>>>> >>>>>>> On 01/09/2013 11:08 AM, shanliang wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Jaroslav Bachorik wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On 01/09/2013 09:40 AM, shanliang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> I still have no idea why the test failed, but I do not see why a >>>>>>>>>> longer >>>>>>>>>> timeout can fix the test. Have you reproduced the problem and >>>>>>>>>> tested >>>>>>>>>> your fix? if yes then possible the long timeout hided a real >>>>>>>>>> problem. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Yes, I can reproduce the problem (using the fastbuild bits and >>>>>>>>> -Xcomp >>>>>>>>> switch) and verify that the fix makes the test pass. >>>>>>>>> >>>>>>>>> The ClientNotifForwarder scans the notifications for >>>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>>>>>>>> appropriate notification listeners in a separate thread. Thus, >>>>>>>>> calling >>>>>>>>> "removeNotificationListener" on the main thread is prone to racing. >>>>>>>>> >>>>>>>>> >>>>>>>> It is true that ClientNotifForwarder scans the notifications for >>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes the >>>>>>>> appropriate notification listeners in a separate thread. This is >>>>>>>> for a >>>>>>>> client connection to do clean if a user never calls >>>>>>>> removeNotificationListener. >>>>>>>> >>>>>>>> But calling directly removeNotificationListener from a client should >>>>>>>> still get exception if the clean has not been done. As I said, if >>>>>>>> the >>>>>>>> client checked and found the listener was still there, then the >>>>>>>> client >>>>>>>> sent a request to its server to remove the listener at server side, >>>>>>>> the >>>>>>>> server should find that the MBean in question was not registered, >>>>>>>> so the >>>>>>>> server should throw an exception. The bug might be here. >>>>>>>> >>>>>>>> >>>>>>> This won't work. The server side listeners are removed upon receiving >>>>>>> the "unregistered" notification which is delivered from the >>>>>>> ClientNotificationForwarder and it may have not run yet (since it >>>>>>> runs >>>>>>> in a separate executor thread). The result is that the attempt to >>>>>>> remove >>>>>>> the notification listener on the server will succeed as well failing >>>>>>> the >>>>>>> test subsequently. >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Shanliang >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> The timeout you made longer was used to wait a notification which >>>>>>>>>> should >>>>>>>>>> never arrive. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Well, it can be used to allow more time to process the "unregister" >>>>>>>>> notification, too. >>>>>>>>> >>>>>>>>> When I think more of this I am more inclined to fix the race >>>>>>>>> condition. >>>>>>>>> An updated webrev will follow. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> To remove a listener from a client side, we did: >>>>>>>>>> 1) at client side, check whether it was added in the client side >>>>>>>>>> 2) at server side, check whether the MBean in question was >>>>>>>>>> registered in >>>>>>>>>> the MBeanServer (!!!) >>>>>>>>>> 3) at server side, check whether the listener was added. >>>>>>>>>> >>>>>>>>>> So 2) tells that we did not rely on a "unregister" notification. >>>>>>>>>> Anyway, >>>>>>>>>> if you use a SAME thread to call "unregister" operation to >>>>>>>>>> unregister an >>>>>>>>>> mbean, then any following call (without any time break) to use the >>>>>>>>>> mbean >>>>>>>>>> should fail, like "removeNotificationListener", "isRegistered" >>>>>>>>>> etc. >>>>>>>>>> >>>>>>>>>> I do see a bug here, if we remove a listener from a non-existing >>>>>>>>>> MBeam, >>>>>>>>>> we get "ListenerNotFoundException" at a client side, but get >>>>>>>>>> "InstanceNotFoundException" at server side, I think we should >>>>>>>>>> create a >>>>>>>>>> bug, because both implemented the same interface >>>>>>>>>> MBeanServerConnection. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Yes, it is rather inconsistent. >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Shanliang >>>>>>>>>> >>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Looking for review and a sponsor. >>>>>>>>>>> >>>>>>>>>>> Webrev at http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>>>>>>>>> >>>>>>>>>>> In this issue the timing is the problem. >>>>>>>>>>> MBeanServer.unregisterMBean() >>>>>>>>>>> fires the "unregister" notification which is sent to the server >>>>>>>>>>> asynchronously. Thus it may happen that the "unregister" >>>>>>>>>>> notification >>>>>>>>>>> has not been yet processed at the time of invoking >>>>>>>>>>> removeNotificationListener() and the notification listeners >>>>>>>>>>> hasn't >>>>>>>>>>> been >>>>>>>>>>> cleaned up leading to the test failure. >>>>>>>>>>> >>>>>>>>>>> There is no synchronization between the client and the server and >>>>>>>>>>> such >>>>>>>>>>> race condition can occur occasionally. Normally, the execution is >>>>>>>>>>> fast >>>>>>>>>>> enough to behave like the "unregister" notification is processed >>>>>>>>>>> synchronously with the unregisterMBean() operation but it seems >>>>>>>>>>> that >>>>>>>>>>> using fastdebug Server VM bits with the -Xcomp option strains >>>>>>>>>>> the CPU >>>>>>>>>>> enough to make this problem appear. >>>>>>>>>>> >>>>>>>>>>> There is no proper fix for this - the only thing that work is >>>>>>>>>>> waiting a >>>>>>>>>>> bit longer in the main thread to give the notification processing >>>>>>>>>>> thread >>>>>>>>>>> some time to clean up the listeners. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130110/c2e94c85/attachment-0001.html From jaroslav.bachorik at oracle.com Thu Jan 10 04:09:04 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 10 Jan 2013 13:09:04 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50EEABA6.6010203@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> <50ED7436.1020205@oracle.com> <50ED7801.8080704@oracle.com> <50ED7DEF.9020108@oracle.com> <50EE824A.8020106@oracle.com> <50EE8447.50901@oracle.com> <50EEA8F8.7090007@oracle.com> <50EEABA6.6010203@oracle.com> Message-ID: <50EEAF60.7040801@oracle.com> On 01/10/2013 12:53 PM, shanliang wrote: > Instead to wait GC, you can also to wait the > MBeanServerNotification.UNREGISTRATION_NOTIFICATION, when you receive > it, then your listener must be removed too. Of course this solution is The problem is that the *NotificationForwarder implementations swallow this kind of notification and just perform the cleanup. No other listener will ever receive this notification. The "unregisterMBean" operation's semantics is not clearly defined. Intuitively, when unregistering an MBean all the associated listeners should be gone before the method returns. But this is not the case - currently the listeners are sanitized some time after the "unregisterMBean" operation started, eventually. There is no easy way to notify the API user that the listeners were removed. I am afraid that in order to resolve these problems new APIs would need to be introduced and the whole mechanism of delivering notification should be revisited (as it was planned for JMX 2.0, anyway). As for fixing the test - checking the weak references works fine as well as increasing the timeout. They both can fail when the system is extremely busy but the GC based solution will be in general faster than the one with increased timeout. -JB- > implementation dependent, but the test is already implementation dependent. > > Shanliang > > > Jaroslav Bachorik wrote: >> On 01/10/2013 10:05 AM, shanliang wrote: >> >>> Jaroslav Bachorik wrote: >>> >>>> On 01/09/2013 03:25 PM, shanliang wrote: >>>> >>>> >>>>> Jaroslav Bachorik wrote: >>>>> >>>>>> On 01/09/2013 02:44 PM, shanliang wrote: >>>>>> >>>>>> >>>>>>> Let's forget the JMX implementation at first. If an MBean is >>>>>>> unregistered, a user at client side calls >>>>>>> "removeNotificationListener" >>>>>>> on the MBean, what should happen? if the user calls >>>>>>> "isRegistered" on >>>>>>> the MBean, what should happen? >>>>>>> >>>>>>> I have done 2 tests, I used only one thread: >>>>>>> >>>>>>> 1) >>>>>>> ...... >>>>>>> localServer.unregisterMBean(myMBean); >>>>>>> boolean isRegistered = remoteClientServer.isRegistered(myMBean)); >>>>>>> >>>>>>> I got isRegistered = false; >>>>>>> >>>>>>> 2) >>>>>>> ...... >>>>>>> localServer.unregisterMBean(myMBean); >>>>>>> System.out.println("isRegistered = >>>>>>> "+remoteClientServer.sRegistered(myMBean)); >>>>>>> remoteClientServer.removeNotificationListener(myMBean, listener); >>>>>>> >>>>>>> I did not get an exception. >>>>>>> >>>>>>> The 1) told that the client could know the MBean was unregistered, >>>>>>> then >>>>>>> the client should throw an exception for the call of >>>>>>> "removeNotificationListener" in 2). >>>>>>> >>>>>> Yes, but then it would not test the listener leakage as it was >>>>>> supposed >>>>>> to test but rather the fact that the client throws the appropriate >>>>>> exception. The fact that the mbean was unregistered does not >>>>>> necessarily >>>>>> mean that the listeners were released. The main problem remains - the >>>>>> listeners are being cleaned-up asynchronously and the clean-up >>>>>> process >>>>>> might race against the other uses of the JMX API. >>>>>> >>>>> client.removeNotificationListener is not a right way here to test >>>>> listener leak, we could use some other ways, for example we keep the >>>>> listener in a weak reference, then after the mbean is removed, the >>>>> weak >>>>> reference should be empty after some time. Another way is like >>>>> DeadListenerTest does to check whether clean has done at server side: >>>>> use reflection to get the "listenerMap" at server side and make >>>>> sure it >>>>> is empty, but this need to add a private method to the class >>>>> ClientNotifForwarder. >>>>> >>>> There will still be problems with timing. You need either to wait for >>>> the GC to kick in to clean up the weak ref. And the listenerMap will >>>> not >>>> be purged of the unregistered MBean listeners until the notification is >>>> generated, processed on the ClientNotificationForwarder and >>>> forwarded to >>>> the server. So there goes the timing issue again. >>>> >>>> The problem is that the "unregisterMBean" operation does not guarantee >>>> that the listeners have been unregistered at the time it returns. So, >>>> one way or the other we will need to wait an arbitrary amount of time >>>> before checking for the memory leak. >>>> >>> Yes we need to wait, but you can use a cycle like: >>> long maxWaitingTime = 3000; >>> long startTime = System.currentTimeMillis(); >>> while ( weakReference.get != null >>> && System.currentTimeMillis() < startTime + >>> maxWaitingTime) { >>> System.gc(); >>> Thread.sleep(100); >>> System.gc(); >>> } >>> >>> if (weakReference.get != null) { >>> // failed >>> } >>> >> >> Still you need an arbitrary timeout which might be reached under extreme >> conditions making this test to fail intermittently. But I'd say that's >> the nature of tests for memory leak fixes, due to the unpredictable >> nature of the GC runs. Unless you take a heap dump and do a reachability >> analysis you can not be sure whether a reference is dangling somwehwere >> or it just hasn't been collected yet :/ >> >> -JB- >> >> >>> Shanliang >>> >>>> -JB- >>>> >>>> >>>> >>>>> I think we have 3 things to do here: >>>>> 1) modify the test to not use removeNotificationListener for testing >>>>> listener leak >>>>> 2) create a new bug about a client does not throw an exception >>>>> after an >>>>> mbean is unregistered >>>>> 3) create a bug about a client does not throw a same exception as at >>>>> server side. >>>>> >>>>> I will do 2) and 3), if you like you can continue 1), it might need to >>>>> do fix also in the JMX implementation. >>>>> >>>>> Shanliang >>>>> >>>>>> >>>>>> >>>>>>> The test "DeadListenerTest" got passed in some machines because >>>>>>> of the >>>>>>> timeout for waiting a notification. I think its failure just tells >>>>>>> a new >>>>>>> bug. >>>>>>> >>>>>>> To set a longer timeout just hides the real bug, and the test might >>>>>>> fail >>>>>>> again one day if running condition is changed and you might need >>>>>>> longer >>>>>>> timeout again. >>>>>>> >>>>>> Yes, I agree with you that extending the timeout just lessens the >>>>>> likelihood of the race condition and does not prevent it. >>>>>> >>>>>> >>>>>> >>>>>>> Shanliang >>>>>>> >>>>>>> Jaroslav Bachorik wrote: >>>>>>> >>>>>>>> On 01/09/2013 11:08 AM, shanliang wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>> >>>>>>>>>> On 01/09/2013 09:40 AM, shanliang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I still have no idea why the test failed, but I do not see why a >>>>>>>>>>> longer >>>>>>>>>>> timeout can fix the test. Have you reproduced the problem and >>>>>>>>>>> tested >>>>>>>>>>> your fix? if yes then possible the long timeout hided a real >>>>>>>>>>> problem. >>>>>>>>>>> >>>>>>>>>> Yes, I can reproduce the problem (using the fastbuild bits and >>>>>>>>>> -Xcomp >>>>>>>>>> switch) and verify that the fix makes the test pass. >>>>>>>>>> >>>>>>>>>> The ClientNotifForwarder scans the notifications for >>>>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and >>>>>>>>>> removes the >>>>>>>>>> appropriate notification listeners in a separate thread. Thus, >>>>>>>>>> calling >>>>>>>>>> "removeNotificationListener" on the main thread is prone to >>>>>>>>>> racing. >>>>>>>>>> >>>>>>>>> It is true that ClientNotifForwarder scans the notifications for >>>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes >>>>>>>>> the >>>>>>>>> appropriate notification listeners in a separate thread. This is >>>>>>>>> for a >>>>>>>>> client connection to do clean if a user never calls >>>>>>>>> removeNotificationListener. >>>>>>>>> >>>>>>>>> But calling directly removeNotificationListener from a client >>>>>>>>> should >>>>>>>>> still get exception if the clean has not been done. As I said, if >>>>>>>>> the >>>>>>>>> client checked and found the listener was still there, then the >>>>>>>>> client >>>>>>>>> sent a request to its server to remove the listener at server >>>>>>>>> side, >>>>>>>>> the >>>>>>>>> server should find that the MBean in question was not registered, >>>>>>>>> so the >>>>>>>>> server should throw an exception. The bug might be here. >>>>>>>>> >>>>>>>> This won't work. The server side listeners are removed upon >>>>>>>> receiving >>>>>>>> the "unregistered" notification which is delivered from the >>>>>>>> ClientNotificationForwarder and it may have not run yet (since it >>>>>>>> runs >>>>>>>> in a separate executor thread). The result is that the attempt to >>>>>>>> remove >>>>>>>> the notification listener on the server will succeed as well >>>>>>>> failing >>>>>>>> the >>>>>>>> test subsequently. >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Shanliang >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> The timeout you made longer was used to wait a notification >>>>>>>>>>> which >>>>>>>>>>> should >>>>>>>>>>> never arrive. >>>>>>>>>>> >>>>>>>>>> Well, it can be used to allow more time to process the >>>>>>>>>> "unregister" >>>>>>>>>> notification, too. >>>>>>>>>> >>>>>>>>>> When I think more of this I am more inclined to fix the race >>>>>>>>>> condition. >>>>>>>>>> An updated webrev will follow. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> To remove a listener from a client side, we did: >>>>>>>>>>> 1) at client side, check whether it was added in the client side >>>>>>>>>>> 2) at server side, check whether the MBean in question was >>>>>>>>>>> registered in >>>>>>>>>>> the MBeanServer (!!!) >>>>>>>>>>> 3) at server side, check whether the listener was added. >>>>>>>>>>> >>>>>>>>>>> So 2) tells that we did not rely on a "unregister" notification. >>>>>>>>>>> Anyway, >>>>>>>>>>> if you use a SAME thread to call "unregister" operation to >>>>>>>>>>> unregister an >>>>>>>>>>> mbean, then any following call (without any time break) to >>>>>>>>>>> use the >>>>>>>>>>> mbean >>>>>>>>>>> should fail, like "removeNotificationListener", "isRegistered" >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> I do see a bug here, if we remove a listener from a non-existing >>>>>>>>>>> MBeam, >>>>>>>>>>> we get "ListenerNotFoundException" at a client side, but get >>>>>>>>>>> "InstanceNotFoundException" at server side, I think we should >>>>>>>>>>> create a >>>>>>>>>>> bug, because both implemented the same interface >>>>>>>>>>> MBeanServerConnection. >>>>>>>>>>> >>>>>>>>>> Yes, it is rather inconsistent. >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Shanliang >>>>>>>>>>> >>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>> >>>>>>>>>>>> Looking for review and a sponsor. >>>>>>>>>>>> >>>>>>>>>>>> Webrev at >>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>>>>>>>>>> >>>>>>>>>>>> In this issue the timing is the problem. >>>>>>>>>>>> MBeanServer.unregisterMBean() >>>>>>>>>>>> fires the "unregister" notification which is sent to the server >>>>>>>>>>>> asynchronously. Thus it may happen that the "unregister" >>>>>>>>>>>> notification >>>>>>>>>>>> has not been yet processed at the time of invoking >>>>>>>>>>>> removeNotificationListener() and the notification listeners >>>>>>>>>>>> hasn't >>>>>>>>>>>> been >>>>>>>>>>>> cleaned up leading to the test failure. >>>>>>>>>>>> >>>>>>>>>>>> There is no synchronization between the client and the >>>>>>>>>>>> server and >>>>>>>>>>>> such >>>>>>>>>>>> race condition can occur occasionally. Normally, the >>>>>>>>>>>> execution is >>>>>>>>>>>> fast >>>>>>>>>>>> enough to behave like the "unregister" notification is >>>>>>>>>>>> processed >>>>>>>>>>>> synchronously with the unregisterMBean() operation but it seems >>>>>>>>>>>> that >>>>>>>>>>>> using fastdebug Server VM bits with the -Xcomp option strains >>>>>>>>>>>> the CPU >>>>>>>>>>>> enough to make this problem appear. >>>>>>>>>>>> >>>>>>>>>>>> There is no proper fix for this - the only thing that work is >>>>>>>>>>>> waiting a >>>>>>>>>>>> bit longer in the main thread to give the notification >>>>>>>>>>>> processing >>>>>>>>>>>> thread >>>>>>>>>>>> some time to clean up the listeners. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > > From jaroslav.bachorik at oracle.com Thu Jan 10 04:31:45 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 10 Jan 2013 13:31:45 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50EEAF60.7040801@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> <50ED7436.1020205@oracle.com> <50ED7801.8080704@oracle.com> <50ED7DEF.9020108@oracle.com> <50EE824A.8020106@oracle.com> <50EE8447.50901@oracle.com> <50EEA8F8.7090007@oracle.com> <50EEABA6.6010203@oracle.com> <50EEAF60.7040801@oracle.com> Message-ID: <50EEB4B1.8070101@oracle.com> On 01/10/2013 01:09 PM, Jaroslav Bachorik wrote: > On 01/10/2013 12:53 PM, shanliang wrote: >> Instead to wait GC, you can also to wait the >> MBeanServerNotification.UNREGISTRATION_NOTIFICATION, when you receive >> it, then your listener must be removed too. Of course this solution is > > The problem is that the *NotificationForwarder implementations swallow > this kind of notification and just perform the cleanup. No other > listener will ever receive this notification. > > The "unregisterMBean" operation's semantics is not clearly defined. > Intuitively, when unregistering an MBean all the associated listeners > should be gone before the method returns. But this is not the case - > currently the listeners are sanitized some time after the > "unregisterMBean" operation started, eventually. There is no easy way to > notify the API user that the listeners were removed. I am afraid that in > order to resolve these problems new APIs would need to be introduced and > the whole mechanism of delivering notification should be revisited (as > it was planned for JMX 2.0, anyway). > > As for fixing the test - checking the weak references works fine as well > as increasing the timeout. They both can fail when the system is > extremely busy but the GC based solution will be in general faster than > the one with increased timeout. Updated webrev: http://cr.openjdk.java.net/~jbachorik/7170447/webrev.01 > > -JB- > >> implementation dependent, but the test is already implementation dependent. >> >> Shanliang >> >> >> Jaroslav Bachorik wrote: >>> On 01/10/2013 10:05 AM, shanliang wrote: >>> >>>> Jaroslav Bachorik wrote: >>>> >>>>> On 01/09/2013 03:25 PM, shanliang wrote: >>>>> >>>>> >>>>>> Jaroslav Bachorik wrote: >>>>>> >>>>>>> On 01/09/2013 02:44 PM, shanliang wrote: >>>>>>> >>>>>>> >>>>>>>> Let's forget the JMX implementation at first. If an MBean is >>>>>>>> unregistered, a user at client side calls >>>>>>>> "removeNotificationListener" >>>>>>>> on the MBean, what should happen? if the user calls >>>>>>>> "isRegistered" on >>>>>>>> the MBean, what should happen? >>>>>>>> >>>>>>>> I have done 2 tests, I used only one thread: >>>>>>>> >>>>>>>> 1) >>>>>>>> ...... >>>>>>>> localServer.unregisterMBean(myMBean); >>>>>>>> boolean isRegistered = remoteClientServer.isRegistered(myMBean)); >>>>>>>> >>>>>>>> I got isRegistered = false; >>>>>>>> >>>>>>>> 2) >>>>>>>> ...... >>>>>>>> localServer.unregisterMBean(myMBean); >>>>>>>> System.out.println("isRegistered = >>>>>>>> "+remoteClientServer.sRegistered(myMBean)); >>>>>>>> remoteClientServer.removeNotificationListener(myMBean, listener); >>>>>>>> >>>>>>>> I did not get an exception. >>>>>>>> >>>>>>>> The 1) told that the client could know the MBean was unregistered, >>>>>>>> then >>>>>>>> the client should throw an exception for the call of >>>>>>>> "removeNotificationListener" in 2). >>>>>>>> >>>>>>> Yes, but then it would not test the listener leakage as it was >>>>>>> supposed >>>>>>> to test but rather the fact that the client throws the appropriate >>>>>>> exception. The fact that the mbean was unregistered does not >>>>>>> necessarily >>>>>>> mean that the listeners were released. The main problem remains - the >>>>>>> listeners are being cleaned-up asynchronously and the clean-up >>>>>>> process >>>>>>> might race against the other uses of the JMX API. >>>>>>> >>>>>> client.removeNotificationListener is not a right way here to test >>>>>> listener leak, we could use some other ways, for example we keep the >>>>>> listener in a weak reference, then after the mbean is removed, the >>>>>> weak >>>>>> reference should be empty after some time. Another way is like >>>>>> DeadListenerTest does to check whether clean has done at server side: >>>>>> use reflection to get the "listenerMap" at server side and make >>>>>> sure it >>>>>> is empty, but this need to add a private method to the class >>>>>> ClientNotifForwarder. >>>>>> >>>>> There will still be problems with timing. You need either to wait for >>>>> the GC to kick in to clean up the weak ref. And the listenerMap will >>>>> not >>>>> be purged of the unregistered MBean listeners until the notification is >>>>> generated, processed on the ClientNotificationForwarder and >>>>> forwarded to >>>>> the server. So there goes the timing issue again. >>>>> >>>>> The problem is that the "unregisterMBean" operation does not guarantee >>>>> that the listeners have been unregistered at the time it returns. So, >>>>> one way or the other we will need to wait an arbitrary amount of time >>>>> before checking for the memory leak. >>>>> >>>> Yes we need to wait, but you can use a cycle like: >>>> long maxWaitingTime = 3000; >>>> long startTime = System.currentTimeMillis(); >>>> while ( weakReference.get != null >>>> && System.currentTimeMillis() < startTime + >>>> maxWaitingTime) { >>>> System.gc(); >>>> Thread.sleep(100); >>>> System.gc(); >>>> } >>>> >>>> if (weakReference.get != null) { >>>> // failed >>>> } >>>> >>> >>> Still you need an arbitrary timeout which might be reached under extreme >>> conditions making this test to fail intermittently. But I'd say that's >>> the nature of tests for memory leak fixes, due to the unpredictable >>> nature of the GC runs. Unless you take a heap dump and do a reachability >>> analysis you can not be sure whether a reference is dangling somwehwere >>> or it just hasn't been collected yet :/ >>> >>> -JB- >>> >>> >>>> Shanliang >>>> >>>>> -JB- >>>>> >>>>> >>>>> >>>>>> I think we have 3 things to do here: >>>>>> 1) modify the test to not use removeNotificationListener for testing >>>>>> listener leak >>>>>> 2) create a new bug about a client does not throw an exception >>>>>> after an >>>>>> mbean is unregistered >>>>>> 3) create a bug about a client does not throw a same exception as at >>>>>> server side. >>>>>> >>>>>> I will do 2) and 3), if you like you can continue 1), it might need to >>>>>> do fix also in the JMX implementation. >>>>>> >>>>>> Shanliang >>>>>> >>>>>>> >>>>>>> >>>>>>>> The test "DeadListenerTest" got passed in some machines because >>>>>>>> of the >>>>>>>> timeout for waiting a notification. I think its failure just tells >>>>>>>> a new >>>>>>>> bug. >>>>>>>> >>>>>>>> To set a longer timeout just hides the real bug, and the test might >>>>>>>> fail >>>>>>>> again one day if running condition is changed and you might need >>>>>>>> longer >>>>>>>> timeout again. >>>>>>>> >>>>>>> Yes, I agree with you that extending the timeout just lessens the >>>>>>> likelihood of the race condition and does not prevent it. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Shanliang >>>>>>>> >>>>>>>> Jaroslav Bachorik wrote: >>>>>>>> >>>>>>>>> On 01/09/2013 11:08 AM, shanliang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>> >>>>>>>>>>> On 01/09/2013 09:40 AM, shanliang wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I still have no idea why the test failed, but I do not see why a >>>>>>>>>>>> longer >>>>>>>>>>>> timeout can fix the test. Have you reproduced the problem and >>>>>>>>>>>> tested >>>>>>>>>>>> your fix? if yes then possible the long timeout hided a real >>>>>>>>>>>> problem. >>>>>>>>>>>> >>>>>>>>>>> Yes, I can reproduce the problem (using the fastbuild bits and >>>>>>>>>>> -Xcomp >>>>>>>>>>> switch) and verify that the fix makes the test pass. >>>>>>>>>>> >>>>>>>>>>> The ClientNotifForwarder scans the notifications for >>>>>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and >>>>>>>>>>> removes the >>>>>>>>>>> appropriate notification listeners in a separate thread. Thus, >>>>>>>>>>> calling >>>>>>>>>>> "removeNotificationListener" on the main thread is prone to >>>>>>>>>>> racing. >>>>>>>>>>> >>>>>>>>>> It is true that ClientNotifForwarder scans the notifications for >>>>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes >>>>>>>>>> the >>>>>>>>>> appropriate notification listeners in a separate thread. This is >>>>>>>>>> for a >>>>>>>>>> client connection to do clean if a user never calls >>>>>>>>>> removeNotificationListener. >>>>>>>>>> >>>>>>>>>> But calling directly removeNotificationListener from a client >>>>>>>>>> should >>>>>>>>>> still get exception if the clean has not been done. As I said, if >>>>>>>>>> the >>>>>>>>>> client checked and found the listener was still there, then the >>>>>>>>>> client >>>>>>>>>> sent a request to its server to remove the listener at server >>>>>>>>>> side, >>>>>>>>>> the >>>>>>>>>> server should find that the MBean in question was not registered, >>>>>>>>>> so the >>>>>>>>>> server should throw an exception. The bug might be here. >>>>>>>>>> >>>>>>>>> This won't work. The server side listeners are removed upon >>>>>>>>> receiving >>>>>>>>> the "unregistered" notification which is delivered from the >>>>>>>>> ClientNotificationForwarder and it may have not run yet (since it >>>>>>>>> runs >>>>>>>>> in a separate executor thread). The result is that the attempt to >>>>>>>>> remove >>>>>>>>> the notification listener on the server will succeed as well >>>>>>>>> failing >>>>>>>>> the >>>>>>>>> test subsequently. >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Shanliang >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> The timeout you made longer was used to wait a notification >>>>>>>>>>>> which >>>>>>>>>>>> should >>>>>>>>>>>> never arrive. >>>>>>>>>>>> >>>>>>>>>>> Well, it can be used to allow more time to process the >>>>>>>>>>> "unregister" >>>>>>>>>>> notification, too. >>>>>>>>>>> >>>>>>>>>>> When I think more of this I am more inclined to fix the race >>>>>>>>>>> condition. >>>>>>>>>>> An updated webrev will follow. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> To remove a listener from a client side, we did: >>>>>>>>>>>> 1) at client side, check whether it was added in the client side >>>>>>>>>>>> 2) at server side, check whether the MBean in question was >>>>>>>>>>>> registered in >>>>>>>>>>>> the MBeanServer (!!!) >>>>>>>>>>>> 3) at server side, check whether the listener was added. >>>>>>>>>>>> >>>>>>>>>>>> So 2) tells that we did not rely on a "unregister" notification. >>>>>>>>>>>> Anyway, >>>>>>>>>>>> if you use a SAME thread to call "unregister" operation to >>>>>>>>>>>> unregister an >>>>>>>>>>>> mbean, then any following call (without any time break) to >>>>>>>>>>>> use the >>>>>>>>>>>> mbean >>>>>>>>>>>> should fail, like "removeNotificationListener", "isRegistered" >>>>>>>>>>>> etc. >>>>>>>>>>>> >>>>>>>>>>>> I do see a bug here, if we remove a listener from a non-existing >>>>>>>>>>>> MBeam, >>>>>>>>>>>> we get "ListenerNotFoundException" at a client side, but get >>>>>>>>>>>> "InstanceNotFoundException" at server side, I think we should >>>>>>>>>>>> create a >>>>>>>>>>>> bug, because both implemented the same interface >>>>>>>>>>>> MBeanServerConnection. >>>>>>>>>>>> >>>>>>>>>>> Yes, it is rather inconsistent. >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Shanliang >>>>>>>>>>>> >>>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Looking for review and a sponsor. >>>>>>>>>>>>> >>>>>>>>>>>>> Webrev at >>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>>>>>>>>>>> >>>>>>>>>>>>> In this issue the timing is the problem. >>>>>>>>>>>>> MBeanServer.unregisterMBean() >>>>>>>>>>>>> fires the "unregister" notification which is sent to the server >>>>>>>>>>>>> asynchronously. Thus it may happen that the "unregister" >>>>>>>>>>>>> notification >>>>>>>>>>>>> has not been yet processed at the time of invoking >>>>>>>>>>>>> removeNotificationListener() and the notification listeners >>>>>>>>>>>>> hasn't >>>>>>>>>>>>> been >>>>>>>>>>>>> cleaned up leading to the test failure. >>>>>>>>>>>>> >>>>>>>>>>>>> There is no synchronization between the client and the >>>>>>>>>>>>> server and >>>>>>>>>>>>> such >>>>>>>>>>>>> race condition can occur occasionally. Normally, the >>>>>>>>>>>>> execution is >>>>>>>>>>>>> fast >>>>>>>>>>>>> enough to behave like the "unregister" notification is >>>>>>>>>>>>> processed >>>>>>>>>>>>> synchronously with the unregisterMBean() operation but it seems >>>>>>>>>>>>> that >>>>>>>>>>>>> using fastdebug Server VM bits with the -Xcomp option strains >>>>>>>>>>>>> the CPU >>>>>>>>>>>>> enough to make this problem appear. >>>>>>>>>>>>> >>>>>>>>>>>>> There is no proper fix for this - the only thing that work is >>>>>>>>>>>>> waiting a >>>>>>>>>>>>> bit longer in the main thread to give the notification >>>>>>>>>>>>> processing >>>>>>>>>>>>> thread >>>>>>>>>>>>> some time to clean up the listeners. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> -JB- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> >> > From shanliang.jiang at oracle.com Thu Jan 10 05:18:32 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 10 Jan 2013 14:18:32 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50EEB4B1.8070101@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> <50ED7436.1020205@oracle.com> <50ED7801.8080704@oracle.com> <50ED7DEF.9020108@oracle.com> <50EE824A.8020106@oracle.com> <50EE8447.50901@oracle.com> <50EEA8F8.7090007@oracle.com> <50EEABA6.6010203@oracle.com> <50EEAF60.7040801@oracle.com> <50EEB4B1.8070101@oracle.com> Message-ID: <50EEBFA8.5010001@oracle.com> The weakListener is unnecessary, the test does already the same verification: 171 Set setForUnreg = listenerMap.get(name); 172 assertTrue("No trace of unregistered MBean: " + setForUnreg, setForUnreg == null); All other are OK for me. Shanliang Jaroslav Bachorik wrote: > On 01/10/2013 01:09 PM, Jaroslav Bachorik wrote: > >> On 01/10/2013 12:53 PM, shanliang wrote: >> >>> Instead to wait GC, you can also to wait the >>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION, when you receive >>> it, then your listener must be removed too. Of course this solution is >>> >> The problem is that the *NotificationForwarder implementations swallow >> this kind of notification and just perform the cleanup. No other >> listener will ever receive this notification. >> >> The "unregisterMBean" operation's semantics is not clearly defined. >> Intuitively, when unregistering an MBean all the associated listeners >> should be gone before the method returns. But this is not the case - >> currently the listeners are sanitized some time after the >> "unregisterMBean" operation started, eventually. There is no easy way to >> notify the API user that the listeners were removed. I am afraid that in >> order to resolve these problems new APIs would need to be introduced and >> the whole mechanism of delivering notification should be revisited (as >> it was planned for JMX 2.0, anyway). >> >> As for fixing the test - checking the weak references works fine as well >> as increasing the timeout. They both can fail when the system is >> extremely busy but the GC based solution will be in general faster than >> the one with increased timeout. >> > > Updated webrev: http://cr.openjdk.java.net/~jbachorik/7170447/webrev.01 > > >> -JB- >> >> >>> implementation dependent, but the test is already implementation dependent. >>> >>> Shanliang >>> >>> >>> Jaroslav Bachorik wrote: >>> >>>> On 01/10/2013 10:05 AM, shanliang wrote: >>>> >>>> >>>>> Jaroslav Bachorik wrote: >>>>> >>>>> >>>>>> On 01/09/2013 03:25 PM, shanliang wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Jaroslav Bachorik wrote: >>>>>>> >>>>>>> >>>>>>>> On 01/09/2013 02:44 PM, shanliang wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Let's forget the JMX implementation at first. If an MBean is >>>>>>>>> unregistered, a user at client side calls >>>>>>>>> "removeNotificationListener" >>>>>>>>> on the MBean, what should happen? if the user calls >>>>>>>>> "isRegistered" on >>>>>>>>> the MBean, what should happen? >>>>>>>>> >>>>>>>>> I have done 2 tests, I used only one thread: >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> ...... >>>>>>>>> localServer.unregisterMBean(myMBean); >>>>>>>>> boolean isRegistered = remoteClientServer.isRegistered(myMBean)); >>>>>>>>> >>>>>>>>> I got isRegistered = false; >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> ...... >>>>>>>>> localServer.unregisterMBean(myMBean); >>>>>>>>> System.out.println("isRegistered = >>>>>>>>> "+remoteClientServer.sRegistered(myMBean)); >>>>>>>>> remoteClientServer.removeNotificationListener(myMBean, listener); >>>>>>>>> >>>>>>>>> I did not get an exception. >>>>>>>>> >>>>>>>>> The 1) told that the client could know the MBean was unregistered, >>>>>>>>> then >>>>>>>>> the client should throw an exception for the call of >>>>>>>>> "removeNotificationListener" in 2). >>>>>>>>> >>>>>>>>> >>>>>>>> Yes, but then it would not test the listener leakage as it was >>>>>>>> supposed >>>>>>>> to test but rather the fact that the client throws the appropriate >>>>>>>> exception. The fact that the mbean was unregistered does not >>>>>>>> necessarily >>>>>>>> mean that the listeners were released. The main problem remains - the >>>>>>>> listeners are being cleaned-up asynchronously and the clean-up >>>>>>>> process >>>>>>>> might race against the other uses of the JMX API. >>>>>>>> >>>>>>>> >>>>>>> client.removeNotificationListener is not a right way here to test >>>>>>> listener leak, we could use some other ways, for example we keep the >>>>>>> listener in a weak reference, then after the mbean is removed, the >>>>>>> weak >>>>>>> reference should be empty after some time. Another way is like >>>>>>> DeadListenerTest does to check whether clean has done at server side: >>>>>>> use reflection to get the "listenerMap" at server side and make >>>>>>> sure it >>>>>>> is empty, but this need to add a private method to the class >>>>>>> ClientNotifForwarder. >>>>>>> >>>>>>> >>>>>> There will still be problems with timing. You need either to wait for >>>>>> the GC to kick in to clean up the weak ref. And the listenerMap will >>>>>> not >>>>>> be purged of the unregistered MBean listeners until the notification is >>>>>> generated, processed on the ClientNotificationForwarder and >>>>>> forwarded to >>>>>> the server. So there goes the timing issue again. >>>>>> >>>>>> The problem is that the "unregisterMBean" operation does not guarantee >>>>>> that the listeners have been unregistered at the time it returns. So, >>>>>> one way or the other we will need to wait an arbitrary amount of time >>>>>> before checking for the memory leak. >>>>>> >>>>>> >>>>> Yes we need to wait, but you can use a cycle like: >>>>> long maxWaitingTime = 3000; >>>>> long startTime = System.currentTimeMillis(); >>>>> while ( weakReference.get != null >>>>> && System.currentTimeMillis() < startTime + >>>>> maxWaitingTime) { >>>>> System.gc(); >>>>> Thread.sleep(100); >>>>> System.gc(); >>>>> } >>>>> >>>>> if (weakReference.get != null) { >>>>> // failed >>>>> } >>>>> >>>>> >>>> Still you need an arbitrary timeout which might be reached under extreme >>>> conditions making this test to fail intermittently. But I'd say that's >>>> the nature of tests for memory leak fixes, due to the unpredictable >>>> nature of the GC runs. Unless you take a heap dump and do a reachability >>>> analysis you can not be sure whether a reference is dangling somwehwere >>>> or it just hasn't been collected yet :/ >>>> >>>> -JB- >>>> >>>> >>>> >>>>> Shanliang >>>>> >>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I think we have 3 things to do here: >>>>>>> 1) modify the test to not use removeNotificationListener for testing >>>>>>> listener leak >>>>>>> 2) create a new bug about a client does not throw an exception >>>>>>> after an >>>>>>> mbean is unregistered >>>>>>> 3) create a bug about a client does not throw a same exception as at >>>>>>> server side. >>>>>>> >>>>>>> I will do 2) and 3), if you like you can continue 1), it might need to >>>>>>> do fix also in the JMX implementation. >>>>>>> >>>>>>> Shanliang >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The test "DeadListenerTest" got passed in some machines because >>>>>>>>> of the >>>>>>>>> timeout for waiting a notification. I think its failure just tells >>>>>>>>> a new >>>>>>>>> bug. >>>>>>>>> >>>>>>>>> To set a longer timeout just hides the real bug, and the test might >>>>>>>>> fail >>>>>>>>> again one day if running condition is changed and you might need >>>>>>>>> longer >>>>>>>>> timeout again. >>>>>>>>> >>>>>>>>> >>>>>>>> Yes, I agree with you that extending the timeout just lessens the >>>>>>>> likelihood of the race condition and does not prevent it. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Shanliang >>>>>>>>> >>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 01/09/2013 11:08 AM, shanliang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 01/09/2013 09:40 AM, shanliang wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I still have no idea why the test failed, but I do not see why a >>>>>>>>>>>>> longer >>>>>>>>>>>>> timeout can fix the test. Have you reproduced the problem and >>>>>>>>>>>>> tested >>>>>>>>>>>>> your fix? if yes then possible the long timeout hided a real >>>>>>>>>>>>> problem. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Yes, I can reproduce the problem (using the fastbuild bits and >>>>>>>>>>>> -Xcomp >>>>>>>>>>>> switch) and verify that the fix makes the test pass. >>>>>>>>>>>> >>>>>>>>>>>> The ClientNotifForwarder scans the notifications for >>>>>>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and >>>>>>>>>>>> removes the >>>>>>>>>>>> appropriate notification listeners in a separate thread. Thus, >>>>>>>>>>>> calling >>>>>>>>>>>> "removeNotificationListener" on the main thread is prone to >>>>>>>>>>>> racing. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> It is true that ClientNotifForwarder scans the notifications for >>>>>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes >>>>>>>>>>> the >>>>>>>>>>> appropriate notification listeners in a separate thread. This is >>>>>>>>>>> for a >>>>>>>>>>> client connection to do clean if a user never calls >>>>>>>>>>> removeNotificationListener. >>>>>>>>>>> >>>>>>>>>>> But calling directly removeNotificationListener from a client >>>>>>>>>>> should >>>>>>>>>>> still get exception if the clean has not been done. As I said, if >>>>>>>>>>> the >>>>>>>>>>> client checked and found the listener was still there, then the >>>>>>>>>>> client >>>>>>>>>>> sent a request to its server to remove the listener at server >>>>>>>>>>> side, >>>>>>>>>>> the >>>>>>>>>>> server should find that the MBean in question was not registered, >>>>>>>>>>> so the >>>>>>>>>>> server should throw an exception. The bug might be here. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> This won't work. The server side listeners are removed upon >>>>>>>>>> receiving >>>>>>>>>> the "unregistered" notification which is delivered from the >>>>>>>>>> ClientNotificationForwarder and it may have not run yet (since it >>>>>>>>>> runs >>>>>>>>>> in a separate executor thread). The result is that the attempt to >>>>>>>>>> remove >>>>>>>>>> the notification listener on the server will succeed as well >>>>>>>>>> failing >>>>>>>>>> the >>>>>>>>>> test subsequently. >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Shanliang >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> The timeout you made longer was used to wait a notification >>>>>>>>>>>>> which >>>>>>>>>>>>> should >>>>>>>>>>>>> never arrive. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Well, it can be used to allow more time to process the >>>>>>>>>>>> "unregister" >>>>>>>>>>>> notification, too. >>>>>>>>>>>> >>>>>>>>>>>> When I think more of this I am more inclined to fix the race >>>>>>>>>>>> condition. >>>>>>>>>>>> An updated webrev will follow. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> To remove a listener from a client side, we did: >>>>>>>>>>>>> 1) at client side, check whether it was added in the client side >>>>>>>>>>>>> 2) at server side, check whether the MBean in question was >>>>>>>>>>>>> registered in >>>>>>>>>>>>> the MBeanServer (!!!) >>>>>>>>>>>>> 3) at server side, check whether the listener was added. >>>>>>>>>>>>> >>>>>>>>>>>>> So 2) tells that we did not rely on a "unregister" notification. >>>>>>>>>>>>> Anyway, >>>>>>>>>>>>> if you use a SAME thread to call "unregister" operation to >>>>>>>>>>>>> unregister an >>>>>>>>>>>>> mbean, then any following call (without any time break) to >>>>>>>>>>>>> use the >>>>>>>>>>>>> mbean >>>>>>>>>>>>> should fail, like "removeNotificationListener", "isRegistered" >>>>>>>>>>>>> etc. >>>>>>>>>>>>> >>>>>>>>>>>>> I do see a bug here, if we remove a listener from a non-existing >>>>>>>>>>>>> MBeam, >>>>>>>>>>>>> we get "ListenerNotFoundException" at a client side, but get >>>>>>>>>>>>> "InstanceNotFoundException" at server side, I think we should >>>>>>>>>>>>> create a >>>>>>>>>>>>> bug, because both implemented the same interface >>>>>>>>>>>>> MBeanServerConnection. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Yes, it is rather inconsistent. >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Shanliang >>>>>>>>>>>>> >>>>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Looking for review and a sponsor. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Webrev at >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> In this issue the timing is the problem. >>>>>>>>>>>>>> MBeanServer.unregisterMBean() >>>>>>>>>>>>>> fires the "unregister" notification which is sent to the server >>>>>>>>>>>>>> asynchronously. Thus it may happen that the "unregister" >>>>>>>>>>>>>> notification >>>>>>>>>>>>>> has not been yet processed at the time of invoking >>>>>>>>>>>>>> removeNotificationListener() and the notification listeners >>>>>>>>>>>>>> hasn't >>>>>>>>>>>>>> been >>>>>>>>>>>>>> cleaned up leading to the test failure. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is no synchronization between the client and the >>>>>>>>>>>>>> server and >>>>>>>>>>>>>> such >>>>>>>>>>>>>> race condition can occur occasionally. Normally, the >>>>>>>>>>>>>> execution is >>>>>>>>>>>>>> fast >>>>>>>>>>>>>> enough to behave like the "unregister" notification is >>>>>>>>>>>>>> processed >>>>>>>>>>>>>> synchronously with the unregisterMBean() operation but it seems >>>>>>>>>>>>>> that >>>>>>>>>>>>>> using fastdebug Server VM bits with the -Xcomp option strains >>>>>>>>>>>>>> the CPU >>>>>>>>>>>>>> enough to make this problem appear. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is no proper fix for this - the only thing that work is >>>>>>>>>>>>>> waiting a >>>>>>>>>>>>>> bit longer in the main thread to give the notification >>>>>>>>>>>>>> processing >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> some time to clean up the listeners. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130110/c9e6fdf9/attachment-0001.html From jaroslav.bachorik at oracle.com Thu Jan 10 05:49:09 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 10 Jan 2013 14:49:09 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50EEBFA8.5010001@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> <50ED7436.1020205@oracle.com> <50ED7801.8080704@oracle.com> <50ED7DEF.9020108@oracle.com> <50EE824A.8020106@oracle.com> <50EE8447.50901@oracle.com> <50EEA8F8.7090007@oracle.com> <50EEABA6.6010203@oracle.com> <50EEAF60.7040801@oracle.com> <50EEB4B1.8070101@oracle.com> <50EEBFA8.5010001@oracle.com> Message-ID: <50EEC6D5.2040400@oracle.com> On 01/10/2013 02:18 PM, shanliang wrote: > The weakListener is unnecessary, the test does already the same > verification: > 171 Set setForUnreg = listenerMap.get(name); > 172 assertTrue("No trace of unregistered MBean: " + setForUnreg, > setForUnreg == null); Addressed. > > All other are OK for me. So, http://cr.openjdk.java.net/~jbachorik/7170447/webrev.02 could be the final version. Thanks for the review! -JB- > > Shanliang > > > Jaroslav Bachorik wrote: >> On 01/10/2013 01:09 PM, Jaroslav Bachorik wrote: >> >>> On 01/10/2013 12:53 PM, shanliang wrote: >>> >>>> Instead to wait GC, you can also to wait the >>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION, when you receive >>>> it, then your listener must be removed too. Of course this solution is >>>> >>> The problem is that the *NotificationForwarder implementations swallow >>> this kind of notification and just perform the cleanup. No other >>> listener will ever receive this notification. >>> >>> The "unregisterMBean" operation's semantics is not clearly defined. >>> Intuitively, when unregistering an MBean all the associated listeners >>> should be gone before the method returns. But this is not the case - >>> currently the listeners are sanitized some time after the >>> "unregisterMBean" operation started, eventually. There is no easy way to >>> notify the API user that the listeners were removed. I am afraid that in >>> order to resolve these problems new APIs would need to be introduced and >>> the whole mechanism of delivering notification should be revisited (as >>> it was planned for JMX 2.0, anyway). >>> >>> As for fixing the test - checking the weak references works fine as well >>> as increasing the timeout. They both can fail when the system is >>> extremely busy but the GC based solution will be in general faster than >>> the one with increased timeout. >>> >> >> Updated webrev: http://cr.openjdk.java.net/~jbachorik/7170447/webrev.01 >> >> >>> -JB- >>> >>> >>>> implementation dependent, but the test is already implementation >>>> dependent. >>>> >>>> Shanliang >>>> >>>> >>>> Jaroslav Bachorik wrote: >>>> >>>>> On 01/10/2013 10:05 AM, shanliang wrote: >>>>> >>>>> >>>>>> Jaroslav Bachorik wrote: >>>>>> >>>>>>> On 01/09/2013 03:25 PM, shanliang wrote: >>>>>>> >>>>>>> >>>>>>>> Jaroslav Bachorik wrote: >>>>>>>> >>>>>>>>> On 01/09/2013 02:44 PM, shanliang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Let's forget the JMX implementation at first. If an MBean is >>>>>>>>>> unregistered, a user at client side calls >>>>>>>>>> "removeNotificationListener" >>>>>>>>>> on the MBean, what should happen? if the user calls >>>>>>>>>> "isRegistered" on >>>>>>>>>> the MBean, what should happen? >>>>>>>>>> >>>>>>>>>> I have done 2 tests, I used only one thread: >>>>>>>>>> >>>>>>>>>> 1) >>>>>>>>>> ...... >>>>>>>>>> localServer.unregisterMBean(myMBean); >>>>>>>>>> boolean isRegistered = remoteClientServer.isRegistered(myMBean)); >>>>>>>>>> >>>>>>>>>> I got isRegistered = false; >>>>>>>>>> >>>>>>>>>> 2) >>>>>>>>>> ...... >>>>>>>>>> localServer.unregisterMBean(myMBean); >>>>>>>>>> System.out.println("isRegistered = >>>>>>>>>> "+remoteClientServer.sRegistered(myMBean)); >>>>>>>>>> remoteClientServer.removeNotificationListener(myMBean, listener); >>>>>>>>>> >>>>>>>>>> I did not get an exception. >>>>>>>>>> >>>>>>>>>> The 1) told that the client could know the MBean was >>>>>>>>>> unregistered, >>>>>>>>>> then >>>>>>>>>> the client should throw an exception for the call of >>>>>>>>>> "removeNotificationListener" in 2). >>>>>>>>>> >>>>>>>>> Yes, but then it would not test the listener leakage as it was >>>>>>>>> supposed >>>>>>>>> to test but rather the fact that the client throws the appropriate >>>>>>>>> exception. The fact that the mbean was unregistered does not >>>>>>>>> necessarily >>>>>>>>> mean that the listeners were released. The main problem remains >>>>>>>>> - the >>>>>>>>> listeners are being cleaned-up asynchronously and the clean-up >>>>>>>>> process >>>>>>>>> might race against the other uses of the JMX API. >>>>>>>>> >>>>>>>> client.removeNotificationListener is not a right way here to test >>>>>>>> listener leak, we could use some other ways, for example we keep >>>>>>>> the >>>>>>>> listener in a weak reference, then after the mbean is removed, the >>>>>>>> weak >>>>>>>> reference should be empty after some time. Another way is like >>>>>>>> DeadListenerTest does to check whether clean has done at server >>>>>>>> side: >>>>>>>> use reflection to get the "listenerMap" at server side and make >>>>>>>> sure it >>>>>>>> is empty, but this need to add a private method to the class >>>>>>>> ClientNotifForwarder. >>>>>>>> >>>>>>> There will still be problems with timing. You need either to wait >>>>>>> for >>>>>>> the GC to kick in to clean up the weak ref. And the listenerMap will >>>>>>> not >>>>>>> be purged of the unregistered MBean listeners until the >>>>>>> notification is >>>>>>> generated, processed on the ClientNotificationForwarder and >>>>>>> forwarded to >>>>>>> the server. So there goes the timing issue again. >>>>>>> >>>>>>> The problem is that the "unregisterMBean" operation does not >>>>>>> guarantee >>>>>>> that the listeners have been unregistered at the time it returns. >>>>>>> So, >>>>>>> one way or the other we will need to wait an arbitrary amount of >>>>>>> time >>>>>>> before checking for the memory leak. >>>>>>> >>>>>> Yes we need to wait, but you can use a cycle like: >>>>>> long maxWaitingTime = 3000; >>>>>> long startTime = System.currentTimeMillis(); >>>>>> while ( weakReference.get != null >>>>>> && System.currentTimeMillis() < startTime + >>>>>> maxWaitingTime) { >>>>>> System.gc(); >>>>>> Thread.sleep(100); >>>>>> System.gc(); >>>>>> } >>>>>> >>>>>> if (weakReference.get != null) { >>>>>> // failed >>>>>> } >>>>>> >>>>> Still you need an arbitrary timeout which might be reached under >>>>> extreme >>>>> conditions making this test to fail intermittently. But I'd say that's >>>>> the nature of tests for memory leak fixes, due to the unpredictable >>>>> nature of the GC runs. Unless you take a heap dump and do a >>>>> reachability >>>>> analysis you can not be sure whether a reference is dangling >>>>> somwehwere >>>>> or it just hasn't been collected yet :/ >>>>> >>>>> -JB- >>>>> >>>>> >>>>> >>>>>> Shanliang >>>>>> >>>>>>> -JB- >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I think we have 3 things to do here: >>>>>>>> 1) modify the test to not use removeNotificationListener for >>>>>>>> testing >>>>>>>> listener leak >>>>>>>> 2) create a new bug about a client does not throw an exception >>>>>>>> after an >>>>>>>> mbean is unregistered >>>>>>>> 3) create a bug about a client does not throw a same exception >>>>>>>> as at >>>>>>>> server side. >>>>>>>> >>>>>>>> I will do 2) and 3), if you like you can continue 1), it might >>>>>>>> need to >>>>>>>> do fix also in the JMX implementation. >>>>>>>> >>>>>>>> Shanliang >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> The test "DeadListenerTest" got passed in some machines because >>>>>>>>>> of the >>>>>>>>>> timeout for waiting a notification. I think its failure just >>>>>>>>>> tells >>>>>>>>>> a new >>>>>>>>>> bug. >>>>>>>>>> >>>>>>>>>> To set a longer timeout just hides the real bug, and the test >>>>>>>>>> might >>>>>>>>>> fail >>>>>>>>>> again one day if running condition is changed and you might need >>>>>>>>>> longer >>>>>>>>>> timeout again. >>>>>>>>>> >>>>>>>>> Yes, I agree with you that extending the timeout just lessens the >>>>>>>>> likelihood of the race condition and does not prevent it. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Shanliang >>>>>>>>>> >>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>> >>>>>>>>>>> On 01/09/2013 11:08 AM, shanliang wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 01/09/2013 09:40 AM, shanliang wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> I still have no idea why the test failed, but I do not see >>>>>>>>>>>>>> why a >>>>>>>>>>>>>> longer >>>>>>>>>>>>>> timeout can fix the test. Have you reproduced the problem and >>>>>>>>>>>>>> tested >>>>>>>>>>>>>> your fix? if yes then possible the long timeout hided a real >>>>>>>>>>>>>> problem. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, I can reproduce the problem (using the fastbuild bits and >>>>>>>>>>>>> -Xcomp >>>>>>>>>>>>> switch) and verify that the fix makes the test pass. >>>>>>>>>>>>> >>>>>>>>>>>>> The ClientNotifForwarder scans the notifications for >>>>>>>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and >>>>>>>>>>>>> removes the >>>>>>>>>>>>> appropriate notification listeners in a separate thread. Thus, >>>>>>>>>>>>> calling >>>>>>>>>>>>> "removeNotificationListener" on the main thread is prone to >>>>>>>>>>>>> racing. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> It is true that ClientNotifForwarder scans the notifications >>>>>>>>>>>> for >>>>>>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes >>>>>>>>>>>> the >>>>>>>>>>>> appropriate notification listeners in a separate thread. >>>>>>>>>>>> This is >>>>>>>>>>>> for a >>>>>>>>>>>> client connection to do clean if a user never calls >>>>>>>>>>>> removeNotificationListener. >>>>>>>>>>>> >>>>>>>>>>>> But calling directly removeNotificationListener from a client >>>>>>>>>>>> should >>>>>>>>>>>> still get exception if the clean has not been done. As I >>>>>>>>>>>> said, if >>>>>>>>>>>> the >>>>>>>>>>>> client checked and found the listener was still there, then the >>>>>>>>>>>> client >>>>>>>>>>>> sent a request to its server to remove the listener at server >>>>>>>>>>>> side, >>>>>>>>>>>> the >>>>>>>>>>>> server should find that the MBean in question was not >>>>>>>>>>>> registered, >>>>>>>>>>>> so the >>>>>>>>>>>> server should throw an exception. The bug might be here. >>>>>>>>>>>> >>>>>>>>>>> This won't work. The server side listeners are removed upon >>>>>>>>>>> receiving >>>>>>>>>>> the "unregistered" notification which is delivered from the >>>>>>>>>>> ClientNotificationForwarder and it may have not run yet >>>>>>>>>>> (since it >>>>>>>>>>> runs >>>>>>>>>>> in a separate executor thread). The result is that the >>>>>>>>>>> attempt to >>>>>>>>>>> remove >>>>>>>>>>> the notification listener on the server will succeed as well >>>>>>>>>>> failing >>>>>>>>>>> the >>>>>>>>>>> test subsequently. >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Shanliang >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> The timeout you made longer was used to wait a notification >>>>>>>>>>>>>> which >>>>>>>>>>>>>> should >>>>>>>>>>>>>> never arrive. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Well, it can be used to allow more time to process the >>>>>>>>>>>>> "unregister" >>>>>>>>>>>>> notification, too. >>>>>>>>>>>>> >>>>>>>>>>>>> When I think more of this I am more inclined to fix the race >>>>>>>>>>>>> condition. >>>>>>>>>>>>> An updated webrev will follow. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> To remove a listener from a client side, we did: >>>>>>>>>>>>>> 1) at client side, check whether it was added in the >>>>>>>>>>>>>> client side >>>>>>>>>>>>>> 2) at server side, check whether the MBean in question was >>>>>>>>>>>>>> registered in >>>>>>>>>>>>>> the MBeanServer (!!!) >>>>>>>>>>>>>> 3) at server side, check whether the listener was added. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So 2) tells that we did not rely on a "unregister" >>>>>>>>>>>>>> notification. >>>>>>>>>>>>>> Anyway, >>>>>>>>>>>>>> if you use a SAME thread to call "unregister" operation to >>>>>>>>>>>>>> unregister an >>>>>>>>>>>>>> mbean, then any following call (without any time break) to >>>>>>>>>>>>>> use the >>>>>>>>>>>>>> mbean >>>>>>>>>>>>>> should fail, like "removeNotificationListener", >>>>>>>>>>>>>> "isRegistered" >>>>>>>>>>>>>> etc. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do see a bug here, if we remove a listener from a >>>>>>>>>>>>>> non-existing >>>>>>>>>>>>>> MBeam, >>>>>>>>>>>>>> we get "ListenerNotFoundException" at a client side, but get >>>>>>>>>>>>>> "InstanceNotFoundException" at server side, I think we should >>>>>>>>>>>>>> create a >>>>>>>>>>>>>> bug, because both implemented the same interface >>>>>>>>>>>>>> MBeanServerConnection. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, it is rather inconsistent. >>>>>>>>>>>>> >>>>>>>>>>>>> -JB- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Shanliang >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Looking for review and a sponsor. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Webrev at >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In this issue the timing is the problem. >>>>>>>>>>>>>>> MBeanServer.unregisterMBean() >>>>>>>>>>>>>>> fires the "unregister" notification which is sent to the >>>>>>>>>>>>>>> server >>>>>>>>>>>>>>> asynchronously. Thus it may happen that the "unregister" >>>>>>>>>>>>>>> notification >>>>>>>>>>>>>>> has not been yet processed at the time of invoking >>>>>>>>>>>>>>> removeNotificationListener() and the notification listeners >>>>>>>>>>>>>>> hasn't >>>>>>>>>>>>>>> been >>>>>>>>>>>>>>> cleaned up leading to the test failure. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is no synchronization between the client and the >>>>>>>>>>>>>>> server and >>>>>>>>>>>>>>> such >>>>>>>>>>>>>>> race condition can occur occasionally. Normally, the >>>>>>>>>>>>>>> execution is >>>>>>>>>>>>>>> fast >>>>>>>>>>>>>>> enough to behave like the "unregister" notification is >>>>>>>>>>>>>>> processed >>>>>>>>>>>>>>> synchronously with the unregisterMBean() operation but it >>>>>>>>>>>>>>> seems >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> using fastdebug Server VM bits with the -Xcomp option >>>>>>>>>>>>>>> strains >>>>>>>>>>>>>>> the CPU >>>>>>>>>>>>>>> enough to make this problem appear. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is no proper fix for this - the only thing that >>>>>>>>>>>>>>> work is >>>>>>>>>>>>>>> waiting a >>>>>>>>>>>>>>> bit longer in the main thread to give the notification >>>>>>>>>>>>>>> processing >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> some time to clean up the listeners. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >> > > From shanliang.jiang at oracle.com Thu Jan 10 07:14:40 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 10 Jan 2013 16:14:40 +0100 Subject: jmx-dev [PATCH] JDK-7170447: Intermittent DeadListenerTest.java failure In-Reply-To: <50EEC6D5.2040400@oracle.com> References: <50EC3850.7080508@oracle.com> <50ED2D0A.5000509@oracle.com> <50ED3C4F.1070001@oracle.com> <50ED41AC.4010007@oracle.com> <50ED6D8E.6070404@oracle.com> <50ED7436.1020205@oracle.com> <50ED7801.8080704@oracle.com> <50ED7DEF.9020108@oracle.com> <50EE824A.8020106@oracle.com> <50EE8447.50901@oracle.com> <50EEA8F8.7090007@oracle.com> <50EEABA6.6010203@oracle.com> <50EEAF60.7040801@oracle.com> <50EEB4B1.8070101@oracle.com> <50EEBFA8.5010001@oracle.com> <50EEC6D5.2040400@oracle.com> Message-ID: <50EEDAE0.7040904@oracle.com> It is OK for me, thanks for fixing the bug! Shanliang Jaroslav Bachorik wrote: > On 01/10/2013 02:18 PM, shanliang wrote: > >> The weakListener is unnecessary, the test does already the same >> verification: >> 171 Set setForUnreg = listenerMap.get(name); >> 172 assertTrue("No trace of unregistered MBean: " + setForUnreg, >> setForUnreg == null); >> > > Addressed. > > >> All other are OK for me. >> > > So, http://cr.openjdk.java.net/~jbachorik/7170447/webrev.02 could be the > final version. > > Thanks for the review! > > -JB- > > >> Shanliang >> >> >> Jaroslav Bachorik wrote: >> >>> On 01/10/2013 01:09 PM, Jaroslav Bachorik wrote: >>> >>> >>>> On 01/10/2013 12:53 PM, shanliang wrote: >>>> >>>> >>>>> Instead to wait GC, you can also to wait the >>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION, when you receive >>>>> it, then your listener must be removed too. Of course this solution is >>>>> >>>>> >>>> The problem is that the *NotificationForwarder implementations swallow >>>> this kind of notification and just perform the cleanup. No other >>>> listener will ever receive this notification. >>>> >>>> The "unregisterMBean" operation's semantics is not clearly defined. >>>> Intuitively, when unregistering an MBean all the associated listeners >>>> should be gone before the method returns. But this is not the case - >>>> currently the listeners are sanitized some time after the >>>> "unregisterMBean" operation started, eventually. There is no easy way to >>>> notify the API user that the listeners were removed. I am afraid that in >>>> order to resolve these problems new APIs would need to be introduced and >>>> the whole mechanism of delivering notification should be revisited (as >>>> it was planned for JMX 2.0, anyway). >>>> >>>> As for fixing the test - checking the weak references works fine as well >>>> as increasing the timeout. They both can fail when the system is >>>> extremely busy but the GC based solution will be in general faster than >>>> the one with increased timeout. >>>> >>>> >>> Updated webrev: http://cr.openjdk.java.net/~jbachorik/7170447/webrev.01 >>> >>> >>> >>>> -JB- >>>> >>>> >>>> >>>>> implementation dependent, but the test is already implementation >>>>> dependent. >>>>> >>>>> Shanliang >>>>> >>>>> >>>>> Jaroslav Bachorik wrote: >>>>> >>>>> >>>>>> On 01/10/2013 10:05 AM, shanliang wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Jaroslav Bachorik wrote: >>>>>>> >>>>>>> >>>>>>>> On 01/09/2013 03:25 PM, shanliang wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 01/09/2013 02:44 PM, shanliang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Let's forget the JMX implementation at first. If an MBean is >>>>>>>>>>> unregistered, a user at client side calls >>>>>>>>>>> "removeNotificationListener" >>>>>>>>>>> on the MBean, what should happen? if the user calls >>>>>>>>>>> "isRegistered" on >>>>>>>>>>> the MBean, what should happen? >>>>>>>>>>> >>>>>>>>>>> I have done 2 tests, I used only one thread: >>>>>>>>>>> >>>>>>>>>>> 1) >>>>>>>>>>> ...... >>>>>>>>>>> localServer.unregisterMBean(myMBean); >>>>>>>>>>> boolean isRegistered = remoteClientServer.isRegistered(myMBean)); >>>>>>>>>>> >>>>>>>>>>> I got isRegistered = false; >>>>>>>>>>> >>>>>>>>>>> 2) >>>>>>>>>>> ...... >>>>>>>>>>> localServer.unregisterMBean(myMBean); >>>>>>>>>>> System.out.println("isRegistered = >>>>>>>>>>> "+remoteClientServer.sRegistered(myMBean)); >>>>>>>>>>> remoteClientServer.removeNotificationListener(myMBean, listener); >>>>>>>>>>> >>>>>>>>>>> I did not get an exception. >>>>>>>>>>> >>>>>>>>>>> The 1) told that the client could know the MBean was >>>>>>>>>>> unregistered, >>>>>>>>>>> then >>>>>>>>>>> the client should throw an exception for the call of >>>>>>>>>>> "removeNotificationListener" in 2). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Yes, but then it would not test the listener leakage as it was >>>>>>>>>> supposed >>>>>>>>>> to test but rather the fact that the client throws the appropriate >>>>>>>>>> exception. The fact that the mbean was unregistered does not >>>>>>>>>> necessarily >>>>>>>>>> mean that the listeners were released. The main problem remains >>>>>>>>>> - the >>>>>>>>>> listeners are being cleaned-up asynchronously and the clean-up >>>>>>>>>> process >>>>>>>>>> might race against the other uses of the JMX API. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> client.removeNotificationListener is not a right way here to test >>>>>>>>> listener leak, we could use some other ways, for example we keep >>>>>>>>> the >>>>>>>>> listener in a weak reference, then after the mbean is removed, the >>>>>>>>> weak >>>>>>>>> reference should be empty after some time. Another way is like >>>>>>>>> DeadListenerTest does to check whether clean has done at server >>>>>>>>> side: >>>>>>>>> use reflection to get the "listenerMap" at server side and make >>>>>>>>> sure it >>>>>>>>> is empty, but this need to add a private method to the class >>>>>>>>> ClientNotifForwarder. >>>>>>>>> >>>>>>>>> >>>>>>>> There will still be problems with timing. You need either to wait >>>>>>>> for >>>>>>>> the GC to kick in to clean up the weak ref. And the listenerMap will >>>>>>>> not >>>>>>>> be purged of the unregistered MBean listeners until the >>>>>>>> notification is >>>>>>>> generated, processed on the ClientNotificationForwarder and >>>>>>>> forwarded to >>>>>>>> the server. So there goes the timing issue again. >>>>>>>> >>>>>>>> The problem is that the "unregisterMBean" operation does not >>>>>>>> guarantee >>>>>>>> that the listeners have been unregistered at the time it returns. >>>>>>>> So, >>>>>>>> one way or the other we will need to wait an arbitrary amount of >>>>>>>> time >>>>>>>> before checking for the memory leak. >>>>>>>> >>>>>>>> >>>>>>> Yes we need to wait, but you can use a cycle like: >>>>>>> long maxWaitingTime = 3000; >>>>>>> long startTime = System.currentTimeMillis(); >>>>>>> while ( weakReference.get != null >>>>>>> && System.currentTimeMillis() < startTime + >>>>>>> maxWaitingTime) { >>>>>>> System.gc(); >>>>>>> Thread.sleep(100); >>>>>>> System.gc(); >>>>>>> } >>>>>>> >>>>>>> if (weakReference.get != null) { >>>>>>> // failed >>>>>>> } >>>>>>> >>>>>>> >>>>>> Still you need an arbitrary timeout which might be reached under >>>>>> extreme >>>>>> conditions making this test to fail intermittently. But I'd say that's >>>>>> the nature of tests for memory leak fixes, due to the unpredictable >>>>>> nature of the GC runs. Unless you take a heap dump and do a >>>>>> reachability >>>>>> analysis you can not be sure whether a reference is dangling >>>>>> somwehwere >>>>>> or it just hasn't been collected yet :/ >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Shanliang >>>>>>> >>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> I think we have 3 things to do here: >>>>>>>>> 1) modify the test to not use removeNotificationListener for >>>>>>>>> testing >>>>>>>>> listener leak >>>>>>>>> 2) create a new bug about a client does not throw an exception >>>>>>>>> after an >>>>>>>>> mbean is unregistered >>>>>>>>> 3) create a bug about a client does not throw a same exception >>>>>>>>> as at >>>>>>>>> server side. >>>>>>>>> >>>>>>>>> I will do 2) and 3), if you like you can continue 1), it might >>>>>>>>> need to >>>>>>>>> do fix also in the JMX implementation. >>>>>>>>> >>>>>>>>> Shanliang >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> The test "DeadListenerTest" got passed in some machines because >>>>>>>>>>> of the >>>>>>>>>>> timeout for waiting a notification. I think its failure just >>>>>>>>>>> tells >>>>>>>>>>> a new >>>>>>>>>>> bug. >>>>>>>>>>> >>>>>>>>>>> To set a longer timeout just hides the real bug, and the test >>>>>>>>>>> might >>>>>>>>>>> fail >>>>>>>>>>> again one day if running condition is changed and you might need >>>>>>>>>>> longer >>>>>>>>>>> timeout again. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Yes, I agree with you that extending the timeout just lessens the >>>>>>>>>> likelihood of the race condition and does not prevent it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Shanliang >>>>>>>>>>> >>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 01/09/2013 11:08 AM, shanliang wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 01/09/2013 09:40 AM, shanliang wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I still have no idea why the test failed, but I do not see >>>>>>>>>>>>>>> why a >>>>>>>>>>>>>>> longer >>>>>>>>>>>>>>> timeout can fix the test. Have you reproduced the problem and >>>>>>>>>>>>>>> tested >>>>>>>>>>>>>>> your fix? if yes then possible the long timeout hided a real >>>>>>>>>>>>>>> problem. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, I can reproduce the problem (using the fastbuild bits and >>>>>>>>>>>>>> -Xcomp >>>>>>>>>>>>>> switch) and verify that the fix makes the test pass. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The ClientNotifForwarder scans the notifications for >>>>>>>>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and >>>>>>>>>>>>>> removes the >>>>>>>>>>>>>> appropriate notification listeners in a separate thread. Thus, >>>>>>>>>>>>>> calling >>>>>>>>>>>>>> "removeNotificationListener" on the main thread is prone to >>>>>>>>>>>>>> racing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> It is true that ClientNotifForwarder scans the notifications >>>>>>>>>>>>> for >>>>>>>>>>>>> MBeanServerNotification.UNREGISTRATION_NOTIFICATION and removes >>>>>>>>>>>>> the >>>>>>>>>>>>> appropriate notification listeners in a separate thread. >>>>>>>>>>>>> This is >>>>>>>>>>>>> for a >>>>>>>>>>>>> client connection to do clean if a user never calls >>>>>>>>>>>>> removeNotificationListener. >>>>>>>>>>>>> >>>>>>>>>>>>> But calling directly removeNotificationListener from a client >>>>>>>>>>>>> should >>>>>>>>>>>>> still get exception if the clean has not been done. As I >>>>>>>>>>>>> said, if >>>>>>>>>>>>> the >>>>>>>>>>>>> client checked and found the listener was still there, then the >>>>>>>>>>>>> client >>>>>>>>>>>>> sent a request to its server to remove the listener at server >>>>>>>>>>>>> side, >>>>>>>>>>>>> the >>>>>>>>>>>>> server should find that the MBean in question was not >>>>>>>>>>>>> registered, >>>>>>>>>>>>> so the >>>>>>>>>>>>> server should throw an exception. The bug might be here. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> This won't work. The server side listeners are removed upon >>>>>>>>>>>> receiving >>>>>>>>>>>> the "unregistered" notification which is delivered from the >>>>>>>>>>>> ClientNotificationForwarder and it may have not run yet >>>>>>>>>>>> (since it >>>>>>>>>>>> runs >>>>>>>>>>>> in a separate executor thread). The result is that the >>>>>>>>>>>> attempt to >>>>>>>>>>>> remove >>>>>>>>>>>> the notification listener on the server will succeed as well >>>>>>>>>>>> failing >>>>>>>>>>>> the >>>>>>>>>>>> test subsequently. >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Shanliang >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> The timeout you made longer was used to wait a notification >>>>>>>>>>>>>>> which >>>>>>>>>>>>>>> should >>>>>>>>>>>>>>> never arrive. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Well, it can be used to allow more time to process the >>>>>>>>>>>>>> "unregister" >>>>>>>>>>>>>> notification, too. >>>>>>>>>>>>>> >>>>>>>>>>>>>> When I think more of this I am more inclined to fix the race >>>>>>>>>>>>>> condition. >>>>>>>>>>>>>> An updated webrev will follow. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> To remove a listener from a client side, we did: >>>>>>>>>>>>>>> 1) at client side, check whether it was added in the >>>>>>>>>>>>>>> client side >>>>>>>>>>>>>>> 2) at server side, check whether the MBean in question was >>>>>>>>>>>>>>> registered in >>>>>>>>>>>>>>> the MBeanServer (!!!) >>>>>>>>>>>>>>> 3) at server side, check whether the listener was added. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So 2) tells that we did not rely on a "unregister" >>>>>>>>>>>>>>> notification. >>>>>>>>>>>>>>> Anyway, >>>>>>>>>>>>>>> if you use a SAME thread to call "unregister" operation to >>>>>>>>>>>>>>> unregister an >>>>>>>>>>>>>>> mbean, then any following call (without any time break) to >>>>>>>>>>>>>>> use the >>>>>>>>>>>>>>> mbean >>>>>>>>>>>>>>> should fail, like "removeNotificationListener", >>>>>>>>>>>>>>> "isRegistered" >>>>>>>>>>>>>>> etc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I do see a bug here, if we remove a listener from a >>>>>>>>>>>>>>> non-existing >>>>>>>>>>>>>>> MBeam, >>>>>>>>>>>>>>> we get "ListenerNotFoundException" at a client side, but get >>>>>>>>>>>>>>> "InstanceNotFoundException" at server side, I think we should >>>>>>>>>>>>>>> create a >>>>>>>>>>>>>>> bug, because both implemented the same interface >>>>>>>>>>>>>>> MBeanServerConnection. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, it is rather inconsistent. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Shanliang >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Looking for review and a sponsor. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Webrev at >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/7170447/webrev.00 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In this issue the timing is the problem. >>>>>>>>>>>>>>>> MBeanServer.unregisterMBean() >>>>>>>>>>>>>>>> fires the "unregister" notification which is sent to the >>>>>>>>>>>>>>>> server >>>>>>>>>>>>>>>> asynchronously. Thus it may happen that the "unregister" >>>>>>>>>>>>>>>> notification >>>>>>>>>>>>>>>> has not been yet processed at the time of invoking >>>>>>>>>>>>>>>> removeNotificationListener() and the notification listeners >>>>>>>>>>>>>>>> hasn't >>>>>>>>>>>>>>>> been >>>>>>>>>>>>>>>> cleaned up leading to the test failure. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is no synchronization between the client and the >>>>>>>>>>>>>>>> server and >>>>>>>>>>>>>>>> such >>>>>>>>>>>>>>>> race condition can occur occasionally. Normally, the >>>>>>>>>>>>>>>> execution is >>>>>>>>>>>>>>>> fast >>>>>>>>>>>>>>>> enough to behave like the "unregister" notification is >>>>>>>>>>>>>>>> processed >>>>>>>>>>>>>>>> synchronously with the unregisterMBean() operation but it >>>>>>>>>>>>>>>> seems >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> using fastdebug Server VM bits with the -Xcomp option >>>>>>>>>>>>>>>> strains >>>>>>>>>>>>>>>> the CPU >>>>>>>>>>>>>>>> enough to make this problem appear. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is no proper fix for this - the only thing that >>>>>>>>>>>>>>>> work is >>>>>>>>>>>>>>>> waiting a >>>>>>>>>>>>>>>> bit longer in the main thread to give the notification >>>>>>>>>>>>>>>> processing >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> some time to clean up the listeners. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130110/9248c139/attachment-0001.html From jaroslav.bachorik at oracle.com Thu Jan 10 07:20:03 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 10 Jan 2013 16:20:03 +0100 Subject: jmx-dev [PATCH] JDK-8005472: com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh failed on windows In-Reply-To: <50EE813A.1020501@oracle.com> References: <50E16BA8.40203@oracle.com> <682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com> <50EAB014.30805@oracle.com> <50EE813A.1020501@oracle.com> Message-ID: <50EEDC23.5080005@oracle.com> Update: http://cr.openjdk.java.net/~jbachorik/8005472/webrev.04 On 01/10/2013 09:52 AM, Stuart Marks wrote: > On 1/7/13 3:23 AM, Jaroslav Bachorik wrote: >> On 01/04/2013 11:37 PM, Kelly O'Hair wrote: >>> I suspect it is not hanging because it does not exist, but that some >>> other windows process has it's hands on it. >>> This is the stdout file from the server being started up right? >>> Could the server from a previous test run be still running? >> >> Exactly. Amy confirmed this and provided a patch which resolves the >> hanging problem. >> >> The update patch is at >> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.01 > > Hi Jaroslav, > > The change to remove the parentheses from around the server program > looks right. It avoids forking an extra process (at least in some > shells) and lets $! refer to the actual JVM, not an intermediate shell > process. The rm -f from Kelly's suggestion is good too. > > But there are other things wrong with the script. I don't think they > could cause hanging, but they could cause the script to fail in > unforeseen ways, or even to report success incorrectly. > > One problem is introduced by the change, where the Server's stderr is > also redirected into $URL_PATH along with stdout. This means that if the > Server program reports any errors, they'll get mixed into the URL_PATH > file instead of appearing in the test log. The URL_PATH file's contents > is never reported, so these error messages will be invisible. Fixed, only the stdout is redirected to $URL_PATH. > > The exit status of some of the critical commands (such as the > compilations) isn't checked, so if javac fails for some reason, the test > might not report failure. Instead, some weird error might or might not > be reported later (though one will still see the javac errors in the log). Fixed, introduced the check. The "set -e" was hanging the script so I have to check for the exit status manually. > > I don't think the sleep at line 80 is necessary, since the client runs > synchronously and should have exited by this point. And it's gone. > > The wait loop checking for the existence of the URL_PATH file doesn't > actually guarantee that the server is running or has initialized yet. > The file is actually created by the shell before the Server JVM starts > up. Thus, runClient might try to read from it before the server has > written anything to it. Or, as mentioned above, the server might have > written some error messages into the URL_PATH file instead of the > expected contents. Thus, the contents of the JMXURL variable can quite > possibly be incorrect. The err is not redirected to the file. A separate file is used to signal the availability of the server and that file is created from the java code after the server has been started. Also, the err and out streams are flushed to make sure the JMX URL makes it into the file. > > If this occurs, what will happen when the client runs? It may emit some > error message, and this will be filtered out by the grep pipeline. Thus, > HAS_ERRORS might end up empty, and the test will report passing, even > though everything has failed! Shouldn't happen with only the controlled stdout redirected to the file. > > For this changeset I'd recommend at a minimum removing the redirection > of stderr to URL_PATH. If the server fails we'll at least see errors in > the test log. > > For checking the notification message, is there a way to modify the > client to report an exit status or throw an exception? Throwing an > exception from main() will exit the JVM with a nonzero status, so this > can be checked more easily from the script. I think this is less > error-prone than grepping the output for a specific error message. The > test should fail if there is *any* error; it should not succeed if an > expected error is absent. This is unfortunately not possible. The notification processing needs to be robust enough to prevent exiting JVM in cases like this. Therefore it only reports the problem, dumps the notification and carries on. The only place one can find something went wrong is the err stream. > > You might consider having jtreg build the client and server classes. > This might simplify some of the setup. Also, jtreg is meticulous about > aborting the test if any compilations fail, so it takes care of that for > you. I need same name classes with incompatible code compiled to two different locations - client and server. I was not able to figure out how to use jtreg to accomplish that. -JB- > > It would be nice if there were a better way to have the client > rendezvous with the server. I hate to suggest it, but sleeping > unconditionally after starting the server is probably necessary. > Anything more robust probably requires rearchitecting the test, though. > > Sorry to dump all this on you. But one of the shell-based RMI tests > suffers from *exactly* the same pathologies. (I have yet to fix it.) > Unfortunately, I believe that there are a lot of other shell-based tests > in the test suite that have similar problems. The lesson here is that > writing reliable shell tests is a lot harder than it seems. > > Thanks, > > s'marks From naoto.sato at oracle.com Thu Jan 10 11:36:17 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 10 Jan 2013 19:36:17 +0000 Subject: hg: jdk8/tl/jdk: 8005962: TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments Message-ID: <20130110193629.349734718F@hg.openjdk.java.net> Changeset: c622df692bfb Author: bchristi Date: 2013-01-10 10:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c622df692bfb 8005962: TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments Summary: Test script now sets LC_ALL, other small changes, relocate test Reviewed-by: naoto, alanb + test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java + test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh - test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java - test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh From karen.kinnear at oracle.com Thu Jan 10 12:28:40 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Jan 2013 15:28:40 -0500 Subject: RFR: 8004095: Add support for JMX interface to Diagnostic Framework and Commands, In-Reply-To: <50CF33B0.6030301@oracle.com> References: <50CF017F.5050502@oracle.com> <32B19E42-82A3-424C-85DA-977815A230CD@oracle.com> <50CF33B0.6030301@oracle.com> Message-ID: Frederic, Finally getting to a code review. I like the design and the code looks very clean. I had a couple of questions please: 1. in the EFP and diagnosticCommand.hpp, why do GC.run and GC. run_finalization not need any special Java permissions? Is this backward compatibility with existing ways to do this? 2. jmm.h what happens if you run with code built with an older jmm.h in another process - are there cases where there would be a misinterpretation of dcmdInfo, dcmdArgInfo because the new arguments were not added at the end? 3. diagnosticFramework.hpp who deallocates the JavaPermission strings? Don't we have the same issue with the name, description and impact already? That they never get freed? 5. diagnosticFramework.hpp line 216 "DCmdParser parse" -> "DCmdParser parses" line 220 "relatively" -> "relative" 6. EFP/diagnosticCommand.cpp - this is the only major discussion point what is the plan for ManagementAgent.start/start_local, stop? Are we planning to add a new permission? Seems like a remote stop of the agent stops you in your tracks - i.e. you can now not remotely restart - at one point we discussed a "restart" rather than a stop, which might allow a remote requestor to change arguments without losing the ability to connect 7. diagnosticCommand.cpp line 259 "are disabled" -> "is disabled" 8. VMManagementImpl.c - for 7150256 line 394 "least one the" -> "least one of the" DiagnosticCommandMBean.java - for 7150256 line 76 "doesn't" -> "don't" DiagnosticCommandImpl.java - for 7150256 I tend to catch all exceptions rather than be specific - if they all would result in a failure, or e.g. ignoring a diagnostic command - that allows for later code changes that still get caught 9. sorry - copyrights will all want to be 2013 now thanks, Karen On Dec 17, 2012, at 10:01 AM, Frederic Parain wrote: > Staffan, > > Thank you for the review, I've fixed the code to address all > the issue you reported. The new webrev is here: > > http://cr.openjdk.java.net/~fparain/8004095/webrev.01/ > > Regards, > > Fred > > On 12/17/12 01:27 PM, Staffan Larsen wrote: >> Frederic, >> >> Looks good! Just a few small comments below. >> >> diagnosticCommand.cpp:255: When DisableExplicitGC is set, it would be great if the SystemGC command printed on error message so that the caller knows that the GC didn't happen as intended. I also think we should add an entry to GCCause for GCs caused by the DCmd (but that isn't new to this change). >> >> diagnosticFramework.hpp:423: nit: misspelled "enabled" in the method name >> >> diagnosticFramework.cpp:435: seems some testing code has slipped in >> >> diagnosticFramework.cpp:509: nit: missing spaces around '&'. (Consider adding () to clarify the precedence.) >> >> Thanks, >> /Staffan >> >> On 17 dec 2012, at 12:26, Frederic Parain wrote: >> >>> Hi, >>> >>> Please review the following change for CR 8004095. >>> >>> This changeset is the JDK side of two parts project. >>> >>> The goal of this feature is to allow remote invocations of >>> Diagnostic Commands via JMX. >>> >>> >>> Diagnostic Commands are actually invoked from the jcmd >>> tool, which is a local tool using the attachAPI. It was >>> not possible to remotely invoke these commands. >>> This project creates a new PlatformMBean, remotely >>> accessible via the Platform MBean Server, providing >>> access to Diagnostic Commands too. >>> >>> The JDK side of this project, including the new >>> Platform MBean, is covered in CR 7150256. >>> >>> This changeset contains the modifications in the >>> JVM to support the new API. >>> >>> There are two types of modifications: >>> 1 - extension of the diagnostic command framework >>> 2 - extension of existing diagnostic commands >>> >>> Modifications of the framework: >>> >>> The first modification of the framework is the mechanism >>> to communicate with the DiagnosticCommandsMBean defined >>> in the JDK. Communications are performed via the jmm.h >>> interface. In addition to a few new entries in the >>> jmm structure, several data structures have been declared >>> to export diagnostic command meta-data to the JDK. >>> >>> The second modification of the framework consists in an >>> export control mechanism. Diagnostic Commands are executed >>> inside the JVM, they have access to critical information >>> and can perform very disruptive operations. Even if the >>> DiagnosticCommandsMBean includes some security checks >>> using Java Permissions, it sometime better to simply >>> make a diagnostic command not available from the JMX >>> API. The export control mechanism gives to diagnostic >>> command developers full control on how the command will >>> be accessible. When a diagnostic command is registered >>> to the framework, a list of interfaces allowed to >>> export this command must be provided. The current >>> implementation defines three interfaces: JVM internal, >>> attachAPI and JMX. A diagnostic command can be >>> exported to any combination of these interfaces. >>> >>> Modifications of existing diagnostic commands: >>> >>> Because this feature allows remote invocations, it >>> is important to be able to control who is invoking >>> and what is invoked. Java Permission checks have >>> been introduced in the DiagnosticCommandsMBean and >>> are performed before a remote invocation request >>> is forwarded to the JVM. So, each Diagnostic Command >>> can require a Java Permission to be invoked remotely. >>> Note that invocations from inside the JVM or via the >>> attachAPI do not check these permissions. Invocations >>> from inside the JVM are considered trusted, and the >>> attachAPI has its own security model based on EUID/ >>> EGID. >>> Some existing diagnostic commands that have been >>> identified as begin potentially harmful have been >>> extended to specify the Java Permission required >>> for their execution. >>> >>> The webrev is here: >>> >>> http://cr.openjdk.java.net/~fparain/8004095/webrev.00/ >>> >>> Thanks, >>> >>> Fred >>> >>> >>> >>> >>> >>> -- >>> Frederic Parain - Oracle >>> Grenoble Engineering Center - France >>> Phone: +33 4 76 18 81 17 >>> Email: Frederic.Parain at Oracle.com >>> >> > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at Oracle.com > From stuart.marks at oracle.com Thu Jan 10 13:44:02 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 10 Jan 2013 13:44:02 -0800 Subject: jmx-dev [PATCH] JDK-8005472: com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh failed on windows In-Reply-To: <50EEDC23.5080005@oracle.com> References: <50E16BA8.40203@oracle.com> <682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com> <50EAB014.30805@oracle.com> <50EE813A.1020501@oracle.com> <50EEDC23.5080005@oracle.com> Message-ID: <50EF3622.9050500@oracle.com> On 1/10/13 7:20 AM, Jaroslav Bachorik wrote: > Update: http://cr.openjdk.java.net/~jbachorik/8005472/webrev.04 Thanks for the update. Note, argv[0] is used before argv.length is checked, so if no args are passed this gives index out of bounds instead of the usage message. I see you take pains to write and flush the URL to stdout before writing the signaling file. Good. The obvious alternative (which I started writing but then erased) is just to put the URL into the signaling file. But this has a race between creation of the file and the writing of its contents. So, what you have works. (This kind of rendezvous problem occurs a lot; it seems like there ought to be a simpler way.) I suspect the -e option caused hangs because if something failed, it would leave the server running, spoiling the next test run. The usual way to deal with this is to use the shell 'trap' statement, to kill subprocesses and remove temp files before exiting the shell. Probably a good practice in general, but perhaps too much shell hackery for this change. (Up to you if you want to tackle it.) Regarding how the test is detecting success/failure, the concern is that if the client fails for some reason other than the failure being checked for, the test will still report passing. Since the error message is coming out of the client JVM, in principle it ought to be possible to redirect it somehow in order to do the assertion checking in Java. With the current shell scheme, not only are other failures reported as the test passing, these other failures are erased in the grep pipeline, so they're not even visible in the test log. This last issue is rather far afield from this webrev, and fixing it will probably require some rearchitecting of the test. So maybe it should be considered independently. I just happened to notice this going on, and I noticed the similarity to what's going on in the RMI tests. s'marks > On 01/10/2013 09:52 AM, Stuart Marks wrote: >> On 1/7/13 3:23 AM, Jaroslav Bachorik wrote: >>> On 01/04/2013 11:37 PM, Kelly O'Hair wrote: >>>> I suspect it is not hanging because it does not exist, but that some >>>> other windows process has it's hands on it. >>>> This is the stdout file from the server being started up right? >>>> Could the server from a previous test run be still running? >>> >>> Exactly. Amy confirmed this and provided a patch which resolves the >>> hanging problem. >>> >>> The update patch is at >>> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.01 >> >> Hi Jaroslav, >> >> The change to remove the parentheses from around the server program >> looks right. It avoids forking an extra process (at least in some >> shells) and lets $! refer to the actual JVM, not an intermediate shell >> process. The rm -f from Kelly's suggestion is good too. >> >> But there are other things wrong with the script. I don't think they >> could cause hanging, but they could cause the script to fail in >> unforeseen ways, or even to report success incorrectly. >> >> One problem is introduced by the change, where the Server's stderr is >> also redirected into $URL_PATH along with stdout. This means that if the >> Server program reports any errors, they'll get mixed into the URL_PATH >> file instead of appearing in the test log. The URL_PATH file's contents >> is never reported, so these error messages will be invisible. > > Fixed, only the stdout is redirected to $URL_PATH. > >> >> The exit status of some of the critical commands (such as the >> compilations) isn't checked, so if javac fails for some reason, the test >> might not report failure. Instead, some weird error might or might not >> be reported later (though one will still see the javac errors in the log). > > Fixed, introduced the check. The "set -e" was hanging the script so I > have to check for the exit status manually. > >> >> I don't think the sleep at line 80 is necessary, since the client runs >> synchronously and should have exited by this point. > > And it's gone. > >> >> The wait loop checking for the existence of the URL_PATH file doesn't >> actually guarantee that the server is running or has initialized yet. >> The file is actually created by the shell before the Server JVM starts >> up. Thus, runClient might try to read from it before the server has >> written anything to it. Or, as mentioned above, the server might have >> written some error messages into the URL_PATH file instead of the >> expected contents. Thus, the contents of the JMXURL variable can quite >> possibly be incorrect. > > The err is not redirected to the file. A separate file is used to signal > the availability of the server and that file is created from the java > code after the server has been started. Also, the err and out streams > are flushed to make sure the JMX URL makes it into the file. > >> >> If this occurs, what will happen when the client runs? It may emit some >> error message, and this will be filtered out by the grep pipeline. Thus, >> HAS_ERRORS might end up empty, and the test will report passing, even >> though everything has failed! > > Shouldn't happen with only the controlled stdout redirected to the file. > >> >> For this changeset I'd recommend at a minimum removing the redirection >> of stderr to URL_PATH. If the server fails we'll at least see errors in >> the test log. >> >> For checking the notification message, is there a way to modify the >> client to report an exit status or throw an exception? Throwing an >> exception from main() will exit the JVM with a nonzero status, so this >> can be checked more easily from the script. I think this is less >> error-prone than grepping the output for a specific error message. The >> test should fail if there is *any* error; it should not succeed if an >> expected error is absent. > > This is unfortunately not possible. The notification processing needs to > be robust enough to prevent exiting JVM in cases like this. Therefore it > only reports the problem, dumps the notification and carries on. The > only place one can find something went wrong is the err stream. > >> >> You might consider having jtreg build the client and server classes. >> This might simplify some of the setup. Also, jtreg is meticulous about >> aborting the test if any compilations fail, so it takes care of that for >> you. > > I need same name classes with incompatible code compiled to two > different locations - client and server. I was not able to figure out > how to use jtreg to accomplish that. > > -JB- > >> >> It would be nice if there were a better way to have the client >> rendezvous with the server. I hate to suggest it, but sleeping >> unconditionally after starting the server is probably necessary. >> Anything more robust probably requires rearchitecting the test, though. >> >> Sorry to dump all this on you. But one of the shell-based RMI tests >> suffers from *exactly* the same pathologies. (I have yet to fix it.) >> Unfortunately, I believe that there are a lot of other shell-based tests >> in the test suite that have similar problems. The lesson here is that >> writing reliable shell tests is a lot harder than it seems. >> >> Thanks, >> >> s'marks > From stuart.marks at oracle.com Thu Jan 10 13:50:38 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 10 Jan 2013 21:50:38 +0000 Subject: hg: jdk8/tl/jdk: 8005582: java/lang/Runtime/exec/WinCommand.java intermittent test failures Message-ID: <20130110215100.F093A4719D@hg.openjdk.java.net> Changeset: 13ff1089e625 Author: jgish Date: 2013-01-10 15:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13ff1089e625 8005582: java/lang/Runtime/exec/WinCommand.java intermittent test failures Summary: Remove file-deletion code at cleanup which conflicts with jtreg cleanup Reviewed-by: chegar ! test/java/lang/Runtime/exec/WinCommand.java From chris.hegarty at oracle.com Thu Jan 10 13:53:49 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 10 Jan 2013 21:53:49 +0000 Subject: hg: jdk8/tl/jdk: 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 Message-ID: <20130110215400.8B9C54719E@hg.openjdk.java.net> Changeset: 3e906ccad412 Author: chegar Date: 2013-01-10 21:52 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e906ccad412 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 Reviewed-by: dl, shade ! src/share/classes/java/util/concurrent/atomic/AtomicBoolean.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java From jonathan.gibbons at oracle.com Thu Jan 10 14:10:01 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 10 Jan 2013 22:10:01 +0000 Subject: hg: jdk8/tl/langtools: 8006037: extra space in javac -help for -J and @ options Message-ID: <20130110221004.60C4A4719F@hg.openjdk.java.net> Changeset: d462da465da6 Author: jjg Date: 2013-01-10 14:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d462da465da6 8006037: extra space in javac -help for -J and @ options Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Option.java + test/tools/javac/main/Option_J_At_Test.java From jonathan.gibbons at oracle.com Thu Jan 10 15:49:08 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 10 Jan 2013 23:49:08 +0000 Subject: hg: jdk8/tl/langtools: 8006033: bug in Pretty.toSimpleString Message-ID: <20130110234910.ABCC9471AD@hg.openjdk.java.net> Changeset: 7d2f628f04f1 Author: jjg Date: 2013-01-10 15:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d2f628f04f1 8006033: bug in Pretty.toSimpleString Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/tree/Pretty.java + test/tools/javac/tree/PrettySimpleStringTest.java From karen.kinnear at oracle.com Thu Jan 10 17:14:23 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Fri, 11 Jan 2013 01:14:23 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7199207: NPG: Crash in PlaceholderTable::verify after StackOverflow Message-ID: <20130111011425.B36B3471B3@hg.openjdk.java.net> Changeset: aefb345d3f5e Author: acorn Date: 2013-01-10 17:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aefb345d3f5e 7199207: NPG: Crash in PlaceholderTable::verify after StackOverflow Summary: Reduce scope of placeholder table entries to improve cleanup Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/utilities/exceptions.hpp From jonathan.gibbons at oracle.com Thu Jan 10 19:39:02 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Jan 2013 03:39:02 +0000 Subject: hg: jdk8/tl/langtools: 8004834: Add doclint support into javadoc Message-ID: <20130111033905.490CC471B9@hg.openjdk.java.net> Changeset: fc4cb1577ad6 Author: jjg Date: 2013-01-10 19:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fc4cb1577ad6 8004834: Add doclint support into javadoc Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! test/com/sun/javadoc/5093723/T5093723.java ! test/com/sun/javadoc/testBadSourceFile/TestBadSourceFile.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testReturnTag/TestReturnTag.java ! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java ! test/com/sun/javadoc/testTagMisuse/TestTagMisuse.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java ! test/com/sun/javadoc/testWarnBadParamNames/TestWarnBadParamNames.java ! test/com/sun/javadoc/testWarnings/TestWarnings.java ! test/tools/javadoc/6958836/Test.java ! test/tools/javadoc/6964914/Test.java ! test/tools/javadoc/6964914/TestStdDoclet.java ! test/tools/javadoc/MaxWarns.java ! test/tools/javadoc/T6551367.java + test/tools/javadoc/doclint/DocLintTest.java From jonathan.gibbons at oracle.com Thu Jan 10 19:39:27 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Jan 2013 03:39:27 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130111033950.61FC7471BA@hg.openjdk.java.net> Changeset: c6e8a518c3cd Author: jjg Date: 2013-01-10 19:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6e8a518c3cd 8004834: Add doclint support into javadoc Reviewed-by: erikj, tbell ! make/docs/Makefile Changeset: c9308137ad9e Author: jjg Date: 2013-01-10 19:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9308137ad9e Merge - test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java - test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh From jonathan.gibbons at oracle.com Thu Jan 10 19:40:02 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Jan 2013 03:40:02 +0000 Subject: hg: jdk8/tl: 8004834: Add doclint support into javadoc Message-ID: <20130111034003.326D6471BB@hg.openjdk.java.net> Changeset: 1129fb75f611 Author: jjg Date: 2013-01-10 19:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1129fb75f611 8004834: Add doclint support into javadoc Reviewed-by: erikj, tbell ! common/makefiles/javadoc/Javadoc.gmk From john.coomes at oracle.com Thu Jan 10 20:56:04 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:56:04 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b72 for changeset c1be681d80a1 Message-ID: <20130111045605.18307471D4@hg.openjdk.java.net> Changeset: f03f90a4308d Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/f03f90a4308d Added tag jdk8-b72 for changeset c1be681d80a1 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:56:08 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:56:08 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b72 for changeset cb40427f4714 Message-ID: <20130111045609.E875C471D5@hg.openjdk.java.net> Changeset: 191afde59e7b Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/191afde59e7b Added tag jdk8-b72 for changeset cb40427f4714 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:56:13 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:56:13 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b72 for changeset bdf2af722a6b Message-ID: <20130111045619.5B342471D6@hg.openjdk.java.net> Changeset: 84946404d1e1 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/84946404d1e1 Added tag jdk8-b72 for changeset bdf2af722a6b ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:56:24 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:56:24 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b72 for changeset d9707230294d Message-ID: <20130111045628.48E2C471D7@hg.openjdk.java.net> Changeset: c606f644a5d9 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/c606f644a5d9 Added tag jdk8-b72 for changeset d9707230294d ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:56:35 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:56:35 +0000 Subject: hg: hsx/hotspot-rt/jdk: Added tag jdk8-b72 for changeset 32a57e645e01 Message-ID: <20130111045706.33332471D8@hg.openjdk.java.net> Changeset: c9a914b11436 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c9a914b11436 Added tag jdk8-b72 for changeset 32a57e645e01 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:58:09 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:58:09 +0000 Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b72 for changeset 6f0986ed9b7e Message-ID: <20130111045815.C6FD6471D9@hg.openjdk.java.net> Changeset: 45fed5cfd1c3 Author: katleman Date: 2013-01-10 09:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/45fed5cfd1c3 Added tag jdk8-b72 for changeset 6f0986ed9b7e ! .hgtags From vikram.aroskar at oracle.com Thu Jan 10 21:10:12 2013 From: vikram.aroskar at oracle.com (vikram.aroskar at oracle.com) Date: Fri, 11 Jan 2013 05:10:12 +0000 Subject: hg: jdk8/tl/jaxp: 8003147: port fix for BCEL bug 39695 Message-ID: <20130111051017.93E67471DA@hg.openjdk.java.net> Changeset: 47738fa4d411 Author: dbuck Date: 2013-01-10 20:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/47738fa4d411 8003147: port fix for BCEL bug 39695 Summary: Added support for Local Variable Type Table so that BCEL library can be used to modify methods with generics-related debug data without violating class file format Reviewed-by: lancea ! src/com/sun/org/apache/bcel/internal/Constants.java ! src/com/sun/org/apache/bcel/internal/classfile/Attribute.java ! src/com/sun/org/apache/bcel/internal/classfile/DescendingVisitor.java ! src/com/sun/org/apache/bcel/internal/classfile/EmptyVisitor.java + src/com/sun/org/apache/bcel/internal/classfile/LocalVariableTypeTable.java ! src/com/sun/org/apache/bcel/internal/classfile/Visitor.java ! src/com/sun/org/apache/bcel/internal/generic/MethodGen.java From joe.darcy at oracle.com Thu Jan 10 21:12:36 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 11 Jan 2013 05:12:36 +0000 Subject: hg: jdk8/tl/jdk: 8006062: Add @Repeatable to repeating annotations regression tests in JDK repo Message-ID: <20130111051247.E47CC471DB@hg.openjdk.java.net> Changeset: 86c563dc70ca Author: darcy Date: 2013-01-10 21:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86c563dc70ca 8006062: Add @Repeatable to repeating annotations regression tests in JDK repo Reviewed-by: jjg ! test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java From david.holmes at oracle.com Thu Jan 10 21:24:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2013 15:24:14 +1000 Subject: hg: hsx/hotspot-rt/hotspot: 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests In-Reply-To: <20130109191755.D0B294714F@hg.openjdk.java.net> References: <20130109191755.D0B294714F@hg.openjdk.java.net> Message-ID: <50EFA1FE.1040807@oracle.com> It is far from clear to me that this change is correct. If a Java 8 interface method is a default method then any of the implementation related modifiers should be valid: - strictfp - synchronized And can't interfaces now also have static methods? David On 10/01/2013 5:17 AM, karen.kinnear at oracle.com wrote: > Changeset: adc176e95bf2 > Author: acorn > Date: 2013-01-09 11:39 -0500 > URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/adc176e95bf2 > > 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests > Summary: Fix verifier for new interface access flags > Reviewed-by: acorn, kvn > Contributed-by: bharadwaj.yadavalli at oracle.com > > ! src/share/vm/classfile/classFileParser.cpp > From david.holmes at oracle.com Fri Jan 11 01:52:14 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Fri, 11 Jan 2013 09:52:14 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130111095229.1AE6D471E2@hg.openjdk.java.net> Changeset: 91bf7da5c609 Author: mikael Date: 2013-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/91bf7da5c609 8004747: Remove last_entry from VM_STRUCT macros Summary: Instead of passing in last_entry to all the VM_ macros just expand it in the main vmStructs.cpp file. Reviewed-by: dholmes, sspitsyn, minqi ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c1c8479222cd Author: dholmes Date: 2013-01-10 21:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c1c8479222cd 8005921: Memory leaks in vmStructs.cpp Reviewed-by: dholmes, mikael, rasbold Contributed-by: Jeremy Manson ! src/share/vm/runtime/vmStructs.cpp From alan.bateman at oracle.com Fri Jan 11 04:29:23 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 11 Jan 2013 12:29:23 +0000 Subject: hg: jdk8/tl/jdk: 8005566: (fs) test/java/nio/file/Files/Misc.java failing (sol) Message-ID: <20130111123228.01781471E5@hg.openjdk.java.net> Changeset: 0ca2e39a110d Author: alanb Date: 2013-01-11 12:27 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ca2e39a110d 8005566: (fs) test/java/nio/file/Files/Misc.java failing (sol) Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! test/java/nio/file/Files/Misc.java From karen.kinnear at oracle.com Fri Jan 11 05:11:51 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 11 Jan 2013 08:11:51 -0500 Subject: RFR (XS): 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs In-Reply-To: <50DE1C33.1040909@oracle.com> References: <50DE1C33.1040909@oracle.com> Message-ID: <4599E4F7-82A8-4E2B-B8F1-01AD5BEDCEBA@oracle.com> Mikael, I like the assertion that you added. I believe that this field isn't used by SA - so if you could double-check that in SA - if that is the case, please just remove it from vmStructs before checking in. thanks, Karen On Dec 28, 2012, at 5:24 PM, Mikael Vidstedt wrote: > > Please review the following change. > > Background: > > The _unloading field is a static field in ClassLoaderDataGraph (in classLoaderData.hpp) and should therefore be defined using static_field, as opposed to nonstatic_field, in vmStructs. > > Apart from changing from nonstatic_field to static_field I also added an assert in the CHECK_NONSTATIC_VM_STRUCT_ENTRY macro to make sure any field offsets are within the bounds of the corresponding structs. The assert triggers for _unloading before the change to static_field. > > The change passes JPRT. > > http://cr.openjdk.java.net/~mikael/8005592/webrev.00/ > > Thanks, > Mikael > From bharadwaj.yadavalli at oracle.com Fri Jan 11 08:10:08 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 11 Jan 2013 11:10:08 -0500 Subject: hg: hsx/hotspot-rt/hotspot: 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests In-Reply-To: <50EFA1FE.1040807@oracle.com> References: <20130109191755.D0B294714F@hg.openjdk.java.net> <50EFA1FE.1040807@oracle.com> Message-ID: <50F03960.4070403@oracle.com> Hi David, Thanks for taking a closer look at this. I followed the specification at http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.1/J.html#JJVMS-4.6 to make these changes. The illegality check I modified/added for Java 8 is as follows: if (major_gte_8) { // Class file version is JAVA_8_VERSION or later Methods of // interfaces may set any of the flags except ACC_PROTECTED, // ACC_FINAL, ACC_NATIVE, and ACC_SYNCHRONIZED; they must // have exactly one of the ACC_PUBLIC or ACC_PRIVATE flags set. if ((is_public == is_private) || /* Only one of private and public should be true - XNOR */ (is_native || is_protected || is_final || is_synchronized) || // If a specific method of a class or interface has its // ACC_ABSTRACT flag set, it must not have any of its // ACC_FINAL, ACC_NATIVE, ACC_PRIVATE, ACC_STATIC, // ACC_STRICT, or ACC_SYNCHRONIZED flags set. No need to // check for ACC_FINAL, ACC_NATIVE or ACC_SYNCHRONIZED as // those flags are illegal irrespective of ACC_ABSTRACT being set or not. (is_abstract && (is_private || is_static || is_strict))) { is_illegal = true; } On 1/11/2013 12:24 AM, David Holmes wrote: > It is far from clear to me that this change is correct. If a Java 8 > interface method is a default method then any of the implementation > related modifiers should be valid: > - strictfp The above condition does not flag strictfp as illegal and hence is valid. > - synchronized > From my reading of the spec and conversations with Brian Goetz and Dan Smith synchronized is now considered invalid. > And can't interfaces now also have static methods? > Yes, they can and the condition flags a method with static modifier only if it also has abstract modifier. Please let me know if I am missing (or misinterpreting) something. Thanks, Bharadwaj From mandy.chung at oracle.com Fri Jan 11 09:16:38 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Jan 2013 09:16:38 -0800 Subject: request for review - 8004172: Remove display of permanent generation counters from jstat options In-Reply-To: <50E75A88.1020205@oracle.com> References: <50E75A88.1020205@oracle.com> Message-ID: <50F048F6.80201@oracle.com> Hi Jon, On 1/4/2013 2:41 PM, Jon Masamitsu wrote: > 8004172: Remove display of permanent generation counters from jstat > options > > This change removes from the jstat options the display of > permanent generation counters. It also removes entirely the > gcpermcapacity option. > > http://cr.openjdk.java.net/~jmasa/8004172/webrev.00/ This change looks good. Have you checked out the jstat tests (jdk/test/sun/tools/jstat)? I expect that there are jstat tests that need to be updated. For jprt job, you need to add "jdk_tools" test target as it's not included in the default. The jstat man page needs to be updated per this change: http://download.java.net/jdk8/docs/technotes/tools/share/jstat.html You can contact the docs team and open an issue for the man page update. Mandy From alan.bateman at oracle.com Fri Jan 11 12:22:17 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 11 Jan 2013 20:22:17 +0000 Subject: hg: jdk8/tl/jdk: 8005978: shell tests need to use the $COMPILEJDK for javac, jar and other tools Message-ID: <20130111202241.5D59A47203@hg.openjdk.java.net> Changeset: 7da291690aa0 Author: alanb Date: 2013-01-11 20:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7da291690aa0 8005978: shell tests need to use the $COMPILEJDK for javac, jar and other tools Reviewed-by: chegar ! test/ProblemList.txt ! test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh ! test/java/io/FileOutputStream/FileOpen.sh ! test/java/io/Serializable/class/run.sh ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/maskSyntheticModifier/run.sh ! test/java/io/Serializable/packageAccess/run.sh ! test/java/io/Serializable/resolveClass/consTest/run.sh ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh ! test/java/io/Serializable/superclassDataLoss/run.sh ! test/java/io/Serializable/unnamedPackageSwitch/run.sh ! test/java/lang/Class/getEnclosingClass/build.sh ! test/java/lang/ClassLoader/Assert.sh ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh ! test/java/lang/Thread/UncaughtExceptions.sh ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/instrument/AppendToBootstrapClassPathSetUp.sh ! test/java/lang/instrument/AppendToClassPathSetUp.sh ! test/java/lang/instrument/BootClassPath/BootClassPathTest.sh ! test/java/lang/instrument/MakeJAR.sh ! test/java/lang/instrument/MakeJAR2.sh ! test/java/lang/instrument/MakeJAR3.sh ! test/java/lang/instrument/MakeJAR4.sh ! test/java/lang/instrument/ManifestTest.sh ! test/java/lang/instrument/ParallelTransformerLoader.sh ! test/java/lang/instrument/PremainClass/NoPremainAgent.sh ! test/java/lang/instrument/PremainClass/PremainClassTest.sh ! test/java/lang/instrument/PremainClass/ZeroArgPremainAgent.sh ! test/java/lang/instrument/RedefineBigClass.sh ! test/java/lang/instrument/RedefineClassWithNativeMethod.sh ! test/java/lang/instrument/RedefineMethodAddInvoke.sh ! test/java/lang/instrument/RedefineSetUp.sh ! test/java/lang/instrument/RetransformBigClass.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CircularityErrorTest.sh ! test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh ! test/java/lang/instrument/appendToClassLoaderSearch/run_tests.sh ! test/java/net/Authenticator/B4933582.sh ! test/java/net/URL/B5086147.sh ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/closetest/build.sh ! test/java/net/URLClassLoader/getresourceasstream/test.sh ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/net/URLConnection/UNCTest.sh ! test/java/nio/charset/spi/basic.sh ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/security/cert/CertificateFactory/slowstream.sh ! test/java/util/Formatter/Basic.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ServiceLoader/basic.sh ! test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh ! test/java/util/prefs/PrefsSpi.sh ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/script/CommonSetup.sh ! test/javax/script/ProviderTest.sh ! test/javax/security/auth/Subject/doAs/Test.sh ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.sh ! test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.sh ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/security/krb5/config/dns.sh ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.sh ! test/sun/security/pkcs11/KeyStore/Basic.sh ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/pkcs11/KeyStore/Solaris.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.sh ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/readjar.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/util/Oid/S11N.sh ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh ! test/tools/launcher/ClassPathWildCard.sh ! test/tools/launcher/MultipleJRE.sh From zhengyu.gu at oracle.com Fri Jan 11 13:00:46 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Fri, 11 Jan 2013 21:00:46 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130111210051.195F847209@hg.openjdk.java.net> Changeset: e0cf9af8978e Author: zgu Date: 2013-01-11 12:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e0cf9af8978e 8005936: PrintNMTStatistics doesn't work for normal JVM exit Summary: Moved NMT shutdown code to JVM exit handler to ensure NMT statistics is printed when PrintNMTStatistics is enabled Reviewed-by: acorn, dholmes, coleenp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp Changeset: 90a92d5bca17 Author: zgu Date: 2013-01-11 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/90a92d5bca17 Merge From joe.darcy at oracle.com Fri Jan 11 15:39:20 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 11 Jan 2013 23:39:20 +0000 Subject: hg: jdk8/tl/jdk: 7131459: [Fmt-De] DecimalFormat produces wrong format() results when close to a tie Message-ID: <20130111233932.0041F4720E@hg.openjdk.java.net> Changeset: bc1f16f5566f Author: darcy Date: 2013-01-11 15:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc1f16f5566f 7131459: [Fmt-De] DecimalFormat produces wrong format() results when close to a tie Reviewed-by: darcy Contributed-by: olivier.lagneau at oracle.com ! src/share/classes/java/text/DigitList.java ! src/share/classes/sun/misc/FloatingDecimal.java + test/java/text/Format/DecimalFormat/TieRoundingTest.java From xueming.shen at oracle.com Fri Jan 11 22:43:14 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Sat, 12 Jan 2013 06:43:14 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130112064336.B631A47222@hg.openjdk.java.net> Changeset: 6f6246aced89 Author: sherman Date: 2013-01-11 22:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f6246aced89 8005466: JAR file entry hash table uses too much memory (zlib_util.c) Summary: realign the fields of jzcell struct Reviewed-by: sherman Contributed-by: ioi.lam at oracle.com ! src/share/native/java/util/zip/zip_util.h Changeset: 8009c7e3899e Author: sherman Date: 2013-01-11 22:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8009c7e3899e Merge From chris.hegarty at oracle.com Sun Jan 13 14:14:36 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 13 Jan 2013 22:14:36 +0000 Subject: hg: jdk8/tl/jdk: 8006153: HTTP protocol handler authenication should use Base64 API Message-ID: <20130113221518.BD0B247237@hg.openjdk.java.net> Changeset: 7db04ae3378f Author: chegar Date: 2013-01-13 22:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7db04ae3378f 8006153: HTTP protocol handler authenication should use Base64 API Reviewed-by: chegar, alanb Contributed-by: Mark Sheppard ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java From david.holmes at oracle.com Sun Jan 13 16:32:36 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2013 10:32:36 +1000 Subject: hg: hsx/hotspot-rt/hotspot: 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests In-Reply-To: <50F03960.4070403@oracle.com> References: <20130109191755.D0B294714F@hg.openjdk.java.net> <50EFA1FE.1040807@oracle.com> <50F03960.4070403@oracle.com> Message-ID: <50F35224.6060304@oracle.com> On 12/01/2013 2:10 AM, Bharadwaj Yadavalli wrote: > Hi David, > > Thanks for taking a closer look at this. > > I followed the specification at > http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.1/J.html#JJVMS-4.6 to > make these changes. > > The illegality check I modified/added for Java 8 is as follows: > > if (major_gte_8) { > // Class file version is JAVA_8_VERSION or later Methods of > // interfaces may set any of the flags except ACC_PROTECTED, > // ACC_FINAL, ACC_NATIVE, and ACC_SYNCHRONIZED; they must > // have exactly one of the ACC_PUBLIC or ACC_PRIVATE flags set. > if ((is_public == is_private) || /* Only one of private and public > should be true - XNOR */ > (is_native || is_protected || is_final || is_synchronized) || > // If a specific method of a class or interface has its > // ACC_ABSTRACT flag set, it must not have any of its > // ACC_FINAL, ACC_NATIVE, ACC_PRIVATE, ACC_STATIC, > // ACC_STRICT, or ACC_SYNCHRONIZED flags set. No need to > // check for ACC_FINAL, ACC_NATIVE or ACC_SYNCHRONIZED as > // those flags are illegal irrespective of ACC_ABSTRACT being set or not. > (is_abstract && (is_private || is_static || is_strict))) { > is_illegal = true; > } > > On 1/11/2013 12:24 AM, David Holmes wrote: >> It is far from clear to me that this change is correct. If a Java 8 >> interface method is a default method then any of the implementation >> related modifiers should be valid: >> - strictfp > > The above condition does not flag strictfp as illegal and hence is valid. Sorry I had trouble reading the condition. I see now it is only the combination of abstract and strictfp that is illegal - as it should be. >> - synchronized >> > From my reading of the spec and conversations with Brian Goetz and Dan > Smith synchronized is now considered invalid. Something I need to take up with them then, it makes no sense to outlaw synchronized when you can code a synchronized block in the method anyway. >> And can't interfaces now also have static methods? >> > > Yes, they can and the condition flags a method with static modifier only > if it also has abstract modifier. Again I misread the condition. > Please let me know if I am missing (or misinterpreting) something. Thanks, David > Thanks, > > Bharadwaj > From david.holmes at oracle.com Sun Jan 13 16:57:35 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 14 Jan 2013 00:57:35 +0000 Subject: hg: jdk8/tl/jdk: 8005232: (JEP-149) Class Instance size reduction Message-ID: <20130114005756.0533447239@hg.openjdk.java.net> Changeset: 1109bfff4e92 Author: dholmes Date: 2013-01-13 19:57 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1109bfff4e92 8005232: (JEP-149) Class Instance size reduction Summary: Moved the fields for cached reflection objects into a seperate ReflectionData object to reduce dynamic footprint. Reviewed-by: dholmes, mchung, shade Contributed-by: Peter Levart ! src/share/classes/java/lang/Class.java From jesper.wilhelmsson at oracle.com Mon Jan 14 08:32:57 2013 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Mon, 14 Jan 2013 16:32:57 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8003985: Support @Contended Annotation - JEP 142 Message-ID: <20130114163300.D709047252@hg.openjdk.java.net> Changeset: 4a916f2ce331 Author: jwilhelm Date: 2013-01-14 15:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4a916f2ce331 8003985: Support @Contended Annotation - JEP 142 Summary: HotSpot changes to support @Contended annotation. Reviewed-by: coleenp, kvn, jrose Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp From joel.franck at oracle.com Mon Jan 14 11:08:32 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Mon, 14 Jan 2013 19:08:32 +0000 Subject: hg: jdk8/tl/langtools: 7193719: Support repeating annotations in javax.lang.model Message-ID: <20130114190837.C51BE47261@hg.openjdk.java.net> Changeset: 9f42a06a49c0 Author: jfranck Date: 2013-01-14 19:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9f42a06a49c0 7193719: Support repeating annotations in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/javax/lang/model/element/Element.java From mikael.vidstedt at oracle.com Mon Jan 14 11:16:21 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 14 Jan 2013 11:16:21 -0800 Subject: RFR (XS): 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs In-Reply-To: <4599E4F7-82A8-4E2B-B8F1-01AD5BEDCEBA@oracle.com> References: <50DE1C33.1040909@oracle.com> <4599E4F7-82A8-4E2B-B8F1-01AD5BEDCEBA@oracle.com> Message-ID: <50F45985.9070606@oracle.com> Thanks Karen, I have verified that the SA does not look for the _unloading field. I will remove it! Cheers, Mikael On 2013-01-11 05:11, Karen Kinnear wrote: > Mikael, > > I like the assertion that you added. > I believe that this field isn't used by SA - so if you could double-check that in SA - if that is the case, please > just remove it from vmStructs before checking in. > > thanks, > Karen > > On Dec 28, 2012, at 5:24 PM, Mikael Vidstedt wrote: > >> Please review the following change. >> >> Background: >> >> The _unloading field is a static field in ClassLoaderDataGraph (in classLoaderData.hpp) and should therefore be defined using static_field, as opposed to nonstatic_field, in vmStructs. >> >> Apart from changing from nonstatic_field to static_field I also added an assert in the CHECK_NONSTATIC_VM_STRUCT_ENTRY macro to make sure any field offsets are within the bounds of the corresponding structs. The assert triggers for _unloading before the change to static_field. >> >> The change passes JPRT. >> >> http://cr.openjdk.java.net/~mikael/8005592/webrev.00/ >> >> Thanks, >> Mikael >> From naoto.sato at oracle.com Mon Jan 14 11:17:42 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 14 Jan 2013 19:17:42 +0000 Subject: hg: jdk8/tl/jdk: 7162007: Clean up i18n related caches Message-ID: <20130114191803.3DF1247263@hg.openjdk.java.net> Changeset: 1d7a6adf499f Author: naoto Date: 2013-01-14 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d7a6adf499f 7162007: Clean up i18n related caches Reviewed-by: okutsu, ohair ! make/java/java/FILES_java.gmk ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java + src/share/classes/sun/util/locale/provider/ResourceBundleBasedAdapter.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! src/share/classes/sun/util/resources/LocaleData.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java From jonathan.gibbons at oracle.com Mon Jan 14 13:50:59 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 14 Jan 2013 21:50:59 +0000 Subject: hg: jdk8/tl/langtools: 8006119: update javac to follow latest spec for repeatable annotations Message-ID: <20130114215104.C7FBE47268@hg.openjdk.java.net> Changeset: df694c775e8a Author: jjg Date: 2013-01-14 13:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/df694c775e8a 8006119: update javac to follow latest spec for repeatable annotations Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeSynthDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerSynthDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeSynthDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerSynthNotDoc.java ! test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java ! test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.out ! test/tools/javac/annotations/repeatingAnnotations/BasicRepeatingAnnotations.java ! test/tools/javac/annotations/repeatingAnnotations/CheckTargets.java ! test/tools/javac/annotations/repeatingAnnotations/ClassReaderDefault.java ! test/tools/javac/annotations/repeatingAnnotations/ContainerHasRepeatedContained.java ! test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.java ! test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.out ! test/tools/javac/annotations/repeatingAnnotations/DefaultCasePresent.java ! test/tools/javac/annotations/repeatingAnnotations/DelayRepeatedContainer.java ! test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.java ! test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.out ! test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.java ! test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.out ! test/tools/javac/annotations/repeatingAnnotations/InvalidTarget.java - test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java ! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java ! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.out - test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out ! test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.java ! test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.out ! test/tools/javac/annotations/repeatingAnnotations/MultiLevelRepeatableAnno.java ! test/tools/javac/annotations/repeatingAnnotations/MultipleAnnoMixedOrder.java ! test/tools/javac/annotations/repeatingAnnotations/NestedContainers.java ! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out ! test/tools/javac/annotations/repeatingAnnotations/RepMemberAnno.java ! test/tools/javac/annotations/repeatingAnnotations/RepSelfMemberAnno.java ! test/tools/javac/annotations/repeatingAnnotations/RepeatingAndContainerPresent.java ! test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.java ! test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.out ! test/tools/javac/annotations/repeatingAnnotations/SelfRepeatingAnnotations.java ! test/tools/javac/annotations/repeatingAnnotations/SingleRepeatingAndContainer.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java + test/tools/javac/annotations/repeatingAnnotations/UseWrongRepeatable.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java ! test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.java ! test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.out ! test/tools/javac/annotations/repeatingAnnotations/combo/BasicSyntaxCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/DeprecatedAnnoCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/DocumentedAnnoCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java ! test/tools/javac/annotations/repeatingAnnotations/combo/InheritedAnnoCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java ! test/tools/javac/diags/examples.not-yet.txt - test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java - test/tools/javac/diags/examples/ContainedByInheritedMismatch.java - test/tools/javac/diags/examples/ContainedByNoValue.java - test/tools/javac/diags/examples/ContainedByNonDefault.java - test/tools/javac/diags/examples/ContainedByRetentionMismatch.java - test/tools/javac/diags/examples/ContainedByTargetMismatch.java - test/tools/javac/diags/examples/ContainedByWrongValueType.java ! test/tools/javac/diags/examples/InvalidDuplicateAnnotation.java + test/tools/javac/diags/examples/RepeatableDocumentedMismatch.java + test/tools/javac/diags/examples/RepeatableInheritedMismatch.java + test/tools/javac/diags/examples/RepeatableNoValue.java + test/tools/javac/diags/examples/RepeatableNonDefault.java + test/tools/javac/diags/examples/RepeatableRetentionMismatch.java + test/tools/javac/diags/examples/RepeatableTargetMismatch.java + test/tools/javac/diags/examples/RepeatableWrongValueType.java ! test/tools/javac/diags/examples/RepeatingAnnotationAndContainer.java - test/tools/javac/diags/examples/WrongContainedBy.java - test/tools/javac/diags/examples/WrongContainerFor.java From coleen.phillimore at oracle.com Mon Jan 14 14:02:44 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 14 Jan 2013 22:02:44 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130114220248.EB67F47269@hg.openjdk.java.net> Changeset: f9eb431c3efe Author: coleenp Date: 2013-01-14 11:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe 8006005: Fix constant pool index validation and alignment trap for method parameter reflection Summary: This patch addresses an alignment trap due to the storage format of method parameters data in constMethod. It also adds code to validate constant pool indexes for method parameters data. Reviewed-by: jrose, dholmes Contributed-by: eric.mccorkle at oracle.com ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/reflection.cpp Changeset: 5b6a231e5a86 Author: coleenp Date: 2013-01-14 08:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5b6a231e5a86 Merge ! src/share/vm/classfile/classFileParser.cpp From jonathan.gibbons at oracle.com Mon Jan 14 14:18:40 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 14 Jan 2013 22:18:40 +0000 Subject: hg: jdk8/tl/langtools: 8006241: Test DocRootSlash.java fails Message-ID: <20130114221844.D58714726C@hg.openjdk.java.net> Changeset: d54b4a091450 Author: jjg Date: 2013-01-14 14:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d54b4a091450 8006241: Test DocRootSlash.java fails Reviewed-by: darcy ! test/com/sun/javadoc/DocRootSlash/DocRootSlash.java From kumar.x.srinivasan at oracle.com Mon Jan 14 16:23:10 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 15 Jan 2013 00:23:10 +0000 Subject: hg: jdk8/tl/jdk: 8005252: pack200 should support MethodParameters Message-ID: <20130115002332.5968147270@hg.openjdk.java.net> Changeset: dcb64d498d5b Author: ksrini Date: 2013-01-14 15:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dcb64d498d5b 8005252: pack200 should support MethodParameters Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/main.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/ProblemList.txt ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java From xuelei.fan at oracle.com Mon Jan 14 18:32:53 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 15 Jan 2013 02:32:53 +0000 Subject: hg: jdk8/tl/jdk: 8006265: Add test SSLEngineDeadlock.java to ProblemList Message-ID: <20130115023314.1F84047277@hg.openjdk.java.net> Changeset: edb7e34a0531 Author: xuelei Date: 2013-01-14 18:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/edb7e34a0531 8006265: Add test SSLEngineDeadlock.java to ProblemList Reviewed-by: weijun ! test/ProblemList.txt From david.holmes at oracle.com Mon Jan 14 20:32:15 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 15 Jan 2013 04:32:15 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs Message-ID: <20130115043219.718454727C@hg.openjdk.java.net> Changeset: fe1472c87a27 Author: mikael Date: 2013-01-14 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fe1472c87a27 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs Summary: Added assertion to catch problem earlier and removed the unused field Reviewed-by: dholmes, acorn ! src/share/vm/runtime/vmStructs.cpp From alexey.utkin at oracle.com Tue Jan 15 02:30:36 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Tue, 15 Jan 2013 10:30:36 +0000 Subject: hg: jdk8/tl/jdk: 8005250: Downgrade normative references to ${java.home}/lib folder from Java client code. Message-ID: <20130115103109.B66EE47285@hg.openjdk.java.net> Changeset: a40052a54801 Author: uta Date: 2013-01-15 14:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a40052a54801 8005250: Downgrade normative references to ${java.home}/lib folder from Java client code. Summary: Javadoc was changed in accordance with CCC-8005250 request. Reviewed-by: alanb, amenkov ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java ! src/share/classes/javax/imageio/spi/IIORegistry.java ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/sound/sampled/AudioSystem.java ! src/share/classes/javax/swing/UIManager.java From chris.hegarty at oracle.com Tue Jan 15 03:45:16 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Jan 2013 11:45:16 +0000 Subject: hg: jdk8/tl/jdk: 8005406: HTTP server implementation should use Base64 API Message-ID: <20130115114538.593DD4728A@hg.openjdk.java.net> Changeset: 4b012af44f24 Author: chegar Date: 2013-01-15 11:44 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b012af44f24 8005406: HTTP server implementation should use Base64 API Reviewed-by: khazra, alanb, chegar Contributed-by: Mark Sheppard ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java From rob.mckenna at oracle.com Tue Jan 15 11:55:10 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Tue, 15 Jan 2013 19:55:10 +0000 Subject: hg: jdk8/tl/jdk: 8005618: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently Message-ID: <20130115195533.BCBF9472A8@hg.openjdk.java.net> Changeset: 44d6cabc9a3f Author: robm Date: 2013-01-15 19:58 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44d6cabc9a3f 8005618: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently Reviewed-by: alanb, martin, dholmes ! test/java/lang/ProcessBuilder/Basic.java From chris.hegarty at oracle.com Tue Jan 15 12:39:40 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Jan 2013 20:39:40 +0000 Subject: hg: jdk8/tl/langtools: 8006344: Broken javadoc link in javax.lang.model.element.Element Message-ID: <20130115203945.DD1AC472AC@hg.openjdk.java.net> Changeset: f805b5e3c9d1 Author: chegar Date: 2013-01-15 20:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f805b5e3c9d1 8006344: Broken javadoc link in javax.lang.model.element.Element Reviewed-by: lancea, alanb, jfranck ! src/share/classes/javax/lang/model/element/Element.java From jonathan.gibbons at oracle.com Tue Jan 15 13:03:40 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 15 Jan 2013 21:03:40 +0000 Subject: hg: jdk8/tl/langtools: 8006224: Doclint NPE for attribute with no value Message-ID: <20130115210343.8C6AC472AE@hg.openjdk.java.net> Changeset: bc1023e0e533 Author: jjg Date: 2013-01-15 13:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bc1023e0e533 8006224: Doclint NPE for attribute with no value Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/AnchorTest.java + test/tools/doclint/AnchorTest.out From coleen.phillimore at oracle.com Tue Jan 15 17:27:45 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 16 Jan 2013 01:27:45 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8005467: CDS size information is incorrect and unfriendly Message-ID: <20130116012749.6F512472C0@hg.openjdk.java.net> Changeset: c793367610c1 Author: coleenp Date: 2013-01-15 17:05 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c793367610c1 8005467: CDS size information is incorrect and unfriendly Summary: Changed words to bytes, and added usage percentage information Reviewed-by: coleenp, twisti Contributed-by: ioi.lam at oracle.com ! src/share/vm/memory/metaspaceShared.cpp From erik.helin at oracle.com Wed Jan 16 01:52:49 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 16 Jan 2013 10:52:49 +0100 Subject: RFR (S): 8006400: Add support for defining trace types in closed code Message-ID: <50F67871.7090101@oracle.com> Hi all, this change adds supports for defining trace types in closed code. Webrev: http://cr.openjdk.java.net/~ehelin/8006400/webrev.00/ Testing: JPRT Thanks, Erik From chris.hegarty at oracle.com Wed Jan 16 02:15:50 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 16 Jan 2013 10:15:50 +0000 Subject: hg: jdk8/tl/jdk: 8005926: Merge ThreadLocalRandom state into java.lang.Thread Message-ID: <20130116101618.3DE0A472D5@hg.openjdk.java.net> Changeset: 9d8ef6174cfd Author: dl Date: 2013-01-16 10:14 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d8ef6174cfd 8005926: Merge ThreadLocalRandom state into java.lang.Thread Reviewed-by: shade, chegar ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java From erik.helin at oracle.com Wed Jan 16 02:38:38 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 16 Jan 2013 11:38:38 +0100 Subject: RFR (S): 8006400: Add support for defining trace types in closed code In-Reply-To: <50F67871.7090101@oracle.com> References: <50F67871.7090101@oracle.com> Message-ID: <50F6832E.9020306@oracle.com> Hi, Staffan Larsen pointed out an error in the file trace.xml - the types were included after the events. The following updated webrev corrects this issue: http://cr.openjdk.java.net/~ehelin/8006400/webrev.01/ Thanks, Erik On 01/16/2013 10:52 AM, Erik Helin wrote: > Hi all, > > this change adds supports for defining trace types in closed code. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8006400/webrev.00/ > > Testing: > JPRT > > Thanks, > Erik From nils.loodin at oracle.com Wed Jan 16 02:37:57 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Wed, 16 Jan 2013 11:37:57 +0100 Subject: RFR (S): 8006400: Add support for defining trace types in closed code In-Reply-To: <50F67871.7090101@oracle.com> References: <50F67871.7090101@oracle.com> Message-ID: <6633A0E7-13B9-43C9-98AB-1B6A983ED1DD@oracle.com> I think it looks good. /Nisse On Jan 16, 2013, at 10:52 , Erik Helin wrote: > Hi all, > > this change adds supports for defining trace types in closed code. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8006400/webrev.00/ > > Testing: > JPRT > > Thanks, > Erik From erik.helin at oracle.com Wed Jan 16 03:00:08 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 16 Jan 2013 12:00:08 +0100 Subject: RFR (S): 8006400: Add support for defining trace types in closed code In-Reply-To: <6633A0E7-13B9-43C9-98AB-1B6A983ED1DD@oracle.com> References: <50F67871.7090101@oracle.com> <6633A0E7-13B9-43C9-98AB-1B6A983ED1DD@oracle.com> Message-ID: <50F68838.1080301@oracle.com> Hi Nils, thanks for reviewing this code! Please see the updated webrev that I just posted in response to an issue pointed out by Staffan Larsen. Thanks, Erik On 01/16/2013 11:37 AM, Nils Loodin wrote: > I think it looks good. > > /Nisse > > On Jan 16, 2013, at 10:52 , Erik Helin wrote: > >> Hi all, >> >> this change adds supports for defining trace types in closed code. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8006400/webrev.00/ >> >> Testing: >> JPRT >> >> Thanks, >> Erik > From nils.loodin at oracle.com Wed Jan 16 03:10:35 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Wed, 16 Jan 2013 12:10:35 +0100 Subject: RFR (S): 8006400: Add support for defining trace types in closed code In-Reply-To: <50F68838.1080301@oracle.com> References: <50F67871.7090101@oracle.com> <6633A0E7-13B9-43C9-98AB-1B6A983ED1DD@oracle.com> <50F68838.1080301@oracle.com> Message-ID: Darn, and here I was silently hoping you wouldn't draw attention to my premature review ;) /Nisse On Jan 16, 2013, at 12:00 , Erik Helin wrote: > Hi Nils, > > thanks for reviewing this code! > > Please see the updated webrev that I just posted in response to an issue pointed out by Staffan Larsen. > > Thanks, > Erik > > On 01/16/2013 11:37 AM, Nils Loodin wrote: >> I think it looks good. >> >> /Nisse >> >> On Jan 16, 2013, at 10:52 , Erik Helin wrote: >> >>> Hi all, >>> >>> this change adds supports for defining trace types in closed code. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8006400/webrev.00/ >>> >>> Testing: >>> JPRT >>> >>> Thanks, >>> Erik >> > From staffan.larsen at oracle.com Wed Jan 16 03:15:18 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 16 Jan 2013 12:15:18 +0100 Subject: RFR (S): 8006400: Add support for defining trace types in closed code In-Reply-To: <50F6832E.9020306@oracle.com> References: <50F67871.7090101@oracle.com> <50F6832E.9020306@oracle.com> Message-ID: Looks good! /Staffan On 16 jan 2013, at 11:38, Erik Helin wrote: > Hi, > > Staffan Larsen pointed out an error in the file trace.xml - the types were included after the events. > > The following updated webrev corrects this issue: > http://cr.openjdk.java.net/~ehelin/8006400/webrev.01/ > > Thanks, > Erik > > > On 01/16/2013 10:52 AM, Erik Helin wrote: >> Hi all, >> >> this change adds supports for defining trace types in closed code. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8006400/webrev.00/ >> >> Testing: >> JPRT >> >> Thanks, >> Erik > From chris.hegarty at oracle.com Wed Jan 16 04:11:13 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 16 Jan 2013 12:11:13 +0000 Subject: hg: jdk8/tl/jdk: 8001666: Add lambda-compatible atomics and accumulators to the ActomicXXX classes Message-ID: <20130116121134.C9446472DD@hg.openjdk.java.net> Changeset: a546d8897e0d Author: dl Date: 2013-01-16 12:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a546d8897e0d 8001666: Add lambda-compatible atomics and accumulators to the ActomicXXX classes Reviewed-by: dl, chegar, darcy, goetz Contributed-by: dl at cs.oswego.edu, chris.hegarty at oracle.com ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java From sean.mullan at oracle.com Wed Jan 16 06:58:18 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 16 Jan 2013 14:58:18 +0000 Subject: hg: jdk8/tl/jdk: 8005389: Backout fix for JDK-6500133 Message-ID: <20130116145924.3ACC0472E6@hg.openjdk.java.net> Changeset: c7d54f93d3e5 Author: juh Date: 2013-01-16 09:51 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c7d54f93d3e5 8005389: Backout fix for JDK-6500133 Reviewed-by: mullan ! src/share/classes/sun/security/x509/URIName.java ! test/sun/security/x509/URIName/Parse.java From maurizio.cimadamore at oracle.com Wed Jan 16 09:02:04 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 16 Jan 2013 17:02:04 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130116170224.B6AB5472ED@hg.openjdk.java.net> Changeset: f785dcac17b7 Author: mcimadamore Date: 2013-01-16 16:27 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f785dcac17b7 8005854: Add support for array constructor references Summary: Support constructor references of the kind int[]::new Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/lambda/MethodReference59.java + test/tools/javac/lambda/MethodReference60.java + test/tools/javac/lambda/MethodReference60.out Changeset: 7aa2025bbb7b Author: mcimadamore Date: 2013-01-16 16:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7aa2025bbb7b 8005299: Add FunctionalInterface checking to javac Summary: Javac should check that types annotated with @FunctionalInterface are indeed functional interfaces Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.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/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/BadFunctionalIntfAnno.java ! test/tools/javac/lambda/BadConv03.out ! test/tools/javac/lambda/BadLambdaPos.out ! test/tools/javac/lambda/BadTargetType.out + test/tools/javac/lambda/FunctionalInterfaceAnno.java + test/tools/javac/lambda/FunctionalInterfaceAnno.out ! test/tools/javac/lambda/Intersection01.out ! test/tools/javac/lambda/LambdaConv09.out ! test/tools/javac/lambda/LambdaExpr10.out ! test/tools/javac/lambda/MethodReference04.out ! test/tools/javac/lambda/TargetType17.out ! test/tools/javac/lambda/TargetType43.out ! test/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.out ! test/tools/javac/lambda/funcInterfaces/NonSAM1.out ! test/tools/javac/lambda/funcInterfaces/NonSAM3.out ! test/tools/javac/lambda/lambdaExpression/AbstractClass_neg.out ! test/tools/javac/lambda/lambdaExpression/InvalidExpression5.out From maurizio.cimadamore at oracle.com Wed Jan 16 09:41:11 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 16 Jan 2013 17:41:11 +0000 Subject: hg: jdk8/tl/langtools: 8005964: Regression: difference in error recovery after ambiguity causes JCK test failure Message-ID: <20130116174116.E1FA4472FA@hg.openjdk.java.net> Changeset: 1afdf1f1472b Author: mcimadamore Date: 2013-01-16 17:40 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1afdf1f1472b 8005964: Regression: difference in error recovery after ambiguity causes JCK test failure Summary: Wrong implementation of ResolveError.access in AmbiguityError Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/comp/Resolve.java From jonathan.gibbons at oracle.com Wed Jan 16 10:30:26 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 16 Jan 2013 18:30:26 +0000 Subject: hg: jdk8/tl/langtools: 8006236: doclint: structural issue hidden Message-ID: <20130116183032.359CA472FD@hg.openjdk.java.net> Changeset: 6b6311a8c9cc Author: jjg Date: 2013-01-16 10:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6b6311a8c9cc 8006236: doclint: structural issue hidden Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/EndTagsTest.java + test/tools/doclint/EndTagsTest.out From sean.mullan at oracle.com Wed Jan 16 10:37:08 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 16 Jan 2013 18:37:08 +0000 Subject: hg: jdk8/tl/jdk: 8005939: sun/security/x509/{X509CRLImplX509CertImpl}/Verify.java fail in confusing way when some providers not present Message-ID: <20130116183729.875AE472FE@hg.openjdk.java.net> Changeset: f7f77bdf248b Author: juh Date: 2013-01-16 13:35 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7f77bdf248b 8005939: sun/security/x509/{X509CRLImplX509CertImpl}/Verify.java fail in confusing way when some providers not present Reviewed-by: mullan, weijun ! test/sun/security/x509/X509CRLImpl/Verify.java ! test/sun/security/x509/X509CertImpl/Verify.java From lana.steuck at oracle.com Wed Jan 16 13:18:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:01 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130116211804.8921F4730F@hg.openjdk.java.net> Changeset: cb40427f4714 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cb40427f4714 Added tag jdk8-b71 for changeset 8171d23e914d ! .hgtags Changeset: 191afde59e7b Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/191afde59e7b Added tag jdk8-b72 for changeset cb40427f4714 ! .hgtags From lana.steuck at oracle.com Wed Jan 16 13:18:06 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:06 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20130116211821.E15BF47311@hg.openjdk.java.net> Changeset: bdf2af722a6b Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bdf2af722a6b Added tag jdk8-b71 for changeset 499be952a291 ! .hgtags Changeset: 84946404d1e1 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/84946404d1e1 Added tag jdk8-b72 for changeset bdf2af722a6b ! .hgtags Changeset: 06827097cdd3 Author: lana Date: 2013-01-16 12:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/06827097cdd3 Merge From lana.steuck at oracle.com Wed Jan 16 13:18:09 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:09 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20130116211825.1256547312@hg.openjdk.java.net> Changeset: 6f0986ed9b7e Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6f0986ed9b7e Added tag jdk8-b71 for changeset 467e4d9281bc ! .hgtags Changeset: 45fed5cfd1c3 Author: katleman Date: 2013-01-10 09:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/45fed5cfd1c3 Added tag jdk8-b72 for changeset 6f0986ed9b7e ! .hgtags Changeset: 8d0baee36c71 Author: lana Date: 2013-01-10 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8d0baee36c71 Merge Changeset: 63b20bde7cd6 Author: lana Date: 2013-01-16 12:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/63b20bde7cd6 Merge From lana.steuck at oracle.com Wed Jan 16 13:18:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:01 +0000 Subject: hg: jdk8/tl: 4 new changesets Message-ID: <20130116211801.EC7084730E@hg.openjdk.java.net> Changeset: c1be681d80a1 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c1be681d80a1 Added tag jdk8-b71 for changeset 51ad2a343420 ! .hgtags Changeset: f03f90a4308d Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f03f90a4308d Added tag jdk8-b72 for changeset c1be681d80a1 ! .hgtags Changeset: 93b9664f97ee Author: lana Date: 2013-01-10 15:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/93b9664f97ee Merge Changeset: cecfba251e4a Author: lana Date: 2013-01-16 11:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cecfba251e4a Merge From lana.steuck at oracle.com Wed Jan 16 13:18:03 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:03 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130116211813.6617747310@hg.openjdk.java.net> Changeset: d9707230294d Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d9707230294d Added tag jdk8-b71 for changeset f577a39c9fb3 ! .hgtags Changeset: c606f644a5d9 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c606f644a5d9 Added tag jdk8-b72 for changeset d9707230294d ! .hgtags From lana.steuck at oracle.com Wed Jan 16 13:18:27 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:27 +0000 Subject: hg: jdk8/tl/hotspot: 39 new changesets Message-ID: <20130116211948.11B1547313@hg.openjdk.java.net> Changeset: d5cb5830f570 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d5cb5830f570 Added tag jdk8-b71 for changeset 0847210f8548 ! .hgtags Changeset: 11619f33cd68 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/11619f33cd68 Added tag jdk8-b72 for changeset d5cb5830f570 ! .hgtags Changeset: cd962e15c08e Author: amurillo Date: 2012-12-21 10:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd962e15c08e 8005382: new hotspot build - hs25-b15 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e51c9860cf66 Author: jmasa Date: 2012-12-03 15:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e51c9860cf66 8005082: NPG: Add specialized Metachunk sizes for reflection and anonymous classloaders Reviewed-by: johnc, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/globals.hpp Changeset: 1de1b145f6bc Author: jmasa Date: 2012-12-26 15:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1de1b145f6bc 8005486: NPG: Incorrect assertion in ChunkManager::list_index() Reviewed-by: coleenp ! src/share/vm/memory/metaspace.cpp Changeset: b735136e0d82 Author: johnc Date: 2013-01-02 11:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b735136e0d82 8004132: SerialGC: ValidateMarkSweep broken when running GCOld Summary: Remove bit-rotten ValidateMarkSweep functionality and flag. Reviewed-by: johnc, jmasa Contributed-by: tamao ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp Changeset: 37f7535e5f18 Author: johnc Date: 2012-12-21 11:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37f7535e5f18 8001424: G1: Rename certain G1-specific flags Summary: Rename G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, and G1OldCSetRegionLiveThresholdPercent to G1NewSizePercent, G1MaxNewSizePercent, and G1MixedGCLiveThresholdPercent respectively. The previous names are no longer accepted. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: d275c3dc73e6 Author: johnc Date: 2013-01-03 16:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d275c3dc73e6 8004816: G1: Kitchensink failures after marking stack changes Summary: Reset the marking state, including the mark stack overflow flag, in the event of a marking stack overflow during serial reference processing. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: ca0a78017dc7 Author: brutisso Date: 2012-12-30 08:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca0a78017dc7 8005396: Use ParNew with only one thread instead of DefNew as default for CMS on single CPU machines Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/runtime/arguments.cpp Changeset: e0ab18eafbde Author: brutisso Date: 2013-01-04 11:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0ab18eafbde 8003820: Deprecate untested and rarely used GC combinations Summary: Log warning messages for DefNew+CMS and ParNew+SerialOld Reviewed-by: ysr, jwilhelm, jcoomes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: c98b676a98b4 Author: brutisso Date: 2013-01-04 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c98b676a98b4 8003822: Deprecate the incremental mode of CMS Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp Changeset: 6e9174173e00 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e9174173e00 8000325: Change default for CMSClassUnloadingEnabled to true Reviewed-by: stefank, ysr ! src/share/vm/runtime/globals.hpp Changeset: 0b54ffe4c2d3 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b54ffe4c2d3 8005672: Clean up some changes to GC logging with GCCause's Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: 7d42f3b08300 Author: dcubed Date: 2012-12-19 10:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7d42f3b08300 8005044: remove crufty '_g' support from HS runtime code Summary: Phase 2 is removing '_g' support from the Runtime code. Reviewed-by: dcubed, coleenp, hseigel Contributed-by: ron.durbin at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/vm/runtime/arguments.cpp Changeset: 35431a769282 Author: stefank Date: 2012-12-20 10:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35431a769282 8004823: Add VM support for type annotation reflection Reviewed-by: dholmes, coleenp Contributed-by: joel.franck at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflection.cpp Changeset: 4daebd4cc1dd Author: minqi Date: 2012-12-24 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4daebd4cc1dd Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/arguments.cpp Changeset: cc6a617fffd2 Author: coleenp Date: 2013-01-02 20:28 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc6a617fffd2 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with CompressedOops and KlassPtrs Summary: Relocate functions with jsr's when rewriting so not repeated after reading shared archive Reviewed-by: twisti, jrose ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.inline.hpp Changeset: 6c3f47d964f3 Author: hseigel Date: 2013-01-07 15:32 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c3f47d964f3 8003705: CDS failed on Windows: can not map in the CDS. Summary: Map memory only once to prevent 'already mapped' failures. Reviewed-by: acorn, zgu ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: 561148896559 Author: hseigel Date: 2013-01-08 13:38 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/561148896559 8005076: Creating a CDS archive with one alignment and running another causes a crash. Summary: Save the alignment when writing the CDS and compare it when reading the CDS. Reviewed-by: kvn, coleenp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ade95d680b42 Author: coleenp Date: 2013-01-08 14:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ade95d680b42 8004728: Add hotspot support for parameter reflection Summary: Add hotspot support for parameter reflection Reviewed-by: acorn, jrose, coleenp Contributed-by: eric.mccorkle at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp Changeset: 185a2c979a0e Author: coleenp Date: 2013-01-08 13:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/185a2c979a0e Merge Changeset: ecd24264898b Author: zgu Date: 2013-01-08 14:04 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ecd24264898b 8005048: NMT: #loaded classes needs to just show the # defined classes Summary: Count number of instance classes so that it matches class metadata size Reviewed-by: coleenp, acorn ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 37a3e8b7a1e9 Author: zgu Date: 2013-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37a3e8b7a1e9 Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 0c93d4818214 Author: zgu Date: 2013-01-08 15:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c93d4818214 Merge Changeset: 1f6d10b4cc0c Author: acorn Date: 2013-01-09 18:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f6d10b4cc0c Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 608b2e8a0063 Author: bpittore Date: 2013-01-03 15:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/608b2e8a0063 8004051: assert(_oprs_len[mode] < maxNumberOfOperands) failed: array overflow Summary: assert is triggered when number of register based arguments passed to a java method exceeds 16. Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.hpp Changeset: 0c8717a92b2d Author: jiangli Date: 2013-01-08 13:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c8717a92b2d 8001341: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. Summary: Use methodHandle. Reviewed-by: coleenp, acorn, twisti, sspitsyn ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 18c3c3fa291b Author: dlong Date: 2013-01-09 21:18 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/18c3c3fa291b Merge ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 4c8bf5e55392 Author: brutisso Date: 2013-01-09 09:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4c8bf5e55392 8005489: VM hangs during GC with ParallelGC and ParallelGCThreads=0 Summary: Print an error message and exit the VM if UseParallalGC is combined with ParllelGCThreads==0. Also reviewed by vitalyd at gmail.com. Reviewed-by: stefank, ehelin ! src/share/vm/runtime/arguments.cpp Changeset: b2fef6b220e9 Author: jmasa Date: 2013-01-10 07:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b2fef6b220e9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: d092d1b31229 Author: roland Date: 2012-12-23 17:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d092d1b31229 8005071: Incremental inlining for JSR 292 Summary: post parse inlining driven by number of live nodes. Reviewed-by: twisti, kvn, jrose ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 00af3a3a8df4 Author: kvn Date: 2013-01-03 15:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/00af3a3a8df4 8005522: use fast-string instructions on x86 for zeroing Summary: use 'rep stosb' instead of 'rep stosq' when fast-string operations are available. Reviewed-by: twisti, roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/memnode.cpp Changeset: e2e6bf86682c Author: kvn Date: 2013-01-03 16:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e2e6bf86682c 8005544: Use 256bit YMM registers in arraycopy stubs on x86 Summary: Use YMM registers in arraycopy and array_fill stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: ffa87474d7a4 Author: twisti Date: 2013-01-07 14:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ffa87474d7a4 8004537: replace AbstractAssembler emit_long with emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.hpp Changeset: 038dd2875b94 Author: kvn Date: 2013-01-08 11:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/038dd2875b94 8005419: Improve intrinsics code performance on x86 by using AVX2 Summary: use 256bit vpxor,vptest instructions in String.compareTo() and equals() intrinsics. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp + test/compiler/8005419/Test8005419.java Changeset: 5698813d45eb Author: twisti Date: 2013-01-09 15:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5698813d45eb 8005418: JSR 292: virtual dispatch bug in 292 impl Reviewed-by: jrose, kvn ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: f1c06dcee0b5 Author: kvn Date: 2013-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1c06dcee0b5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 1e129851479e Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e129851479e Merge Changeset: b5e6bec76f4a Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5e6bec76f4a Added tag hs25-b15 for changeset 1e129851479e ! .hgtags From lana.steuck at oracle.com Wed Jan 16 13:18:29 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:29 +0000 Subject: hg: jdk8/tl/jdk: 6 new changesets Message-ID: <20130116211951.9531347314@hg.openjdk.java.net> Changeset: 32a57e645e01 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32a57e645e01 Added tag jdk8-b71 for changeset 2a5af0f766d0 ! .hgtags Changeset: c9a914b11436 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9a914b11436 Added tag jdk8-b72 for changeset 32a57e645e01 ! .hgtags Changeset: d54922883f4c Author: alexsch Date: 2013-01-09 16:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d54922883f4c 8005019: JTable passes row index instead of length when inserts selection interval Reviewed-by: serb, denis ! src/share/classes/javax/swing/JTable.java + test/javax/swing/JTable/8005019/bug8005019.java Changeset: b2c425d7e5be Author: lana Date: 2013-01-10 15:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b2c425d7e5be Merge Changeset: 733885f57e14 Author: lana Date: 2013-01-10 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/733885f57e14 Merge Changeset: 9fed48caac80 Author: lana Date: 2013-01-16 12:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9fed48caac80 Merge From joe.darcy at oracle.com Wed Jan 16 13:22:28 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 16 Jan 2013 21:22:28 +0000 Subject: hg: jdk8/tl/langtools: 8006283: Change to Class.cast() in javax.lang.model implementation for repeating annotations Message-ID: <20130116212231.47D6C47315@hg.openjdk.java.net> Changeset: 8b749558767b Author: darcy Date: 2013-01-16 13:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8b749558767b 8006283: Change to Class.cast() in javax.lang.model implementation for repeating annotations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/model/JavacElements.java From serguei.spitsyn at oracle.com Wed Jan 16 13:46:26 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 16 Jan 2013 13:46:26 -0800 Subject: Review Request (S) 8005128: JSR 292: the mlvm redefineClassInBootstrap test crashes in ConstantPool::compare_entry_to Message-ID: <50F71FB2.4020702@oracle.com> Please, review the fix for: https://jbs.oracle.com/bugs/browse/JDK-8005128 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8005128-JVMTI-JSR292.0/ Summary: When constant pool is copied by the merge_constant_pools() the invokedynamic operands must be copied in a right order. The pool_holder needs to be set before copying the operands. Testing: nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist, vm/mlvm/indy/func/jvmti/redefineClassInBootstrap Will check if any jtreg tests are useful. Thanks, Serguei From jonathan.gibbons at oracle.com Wed Jan 16 20:41:40 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 17 Jan 2013 04:41:40 +0000 Subject: hg: jdk8/tl/langtools: 8006228: Doclint doesn't detect {@code nested inline} Message-ID: <20130117044145.5514147330@hg.openjdk.java.net> Changeset: 916143318f10 Author: jjg Date: 2013-01-16 20:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/916143318f10 8006228: Doclint doesn't detect {@code nested inline} Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/LiteralTest.java + test/tools/doclint/LiteralTest.out From staffan.larsen at oracle.com Thu Jan 17 03:30:46 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 17 Jan 2013 11:30:46 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8006403: Regression: jstack failed due to the FieldInfo regression in SA Message-ID: <20130117113055.4D7BE47364@hg.openjdk.java.net> Changeset: e94ed1591b42 Author: sla Date: 2013-01-16 16:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e94ed1591b42 8006403: Regression: jstack failed due to the FieldInfo regression in SA Reviewed-by: sla, dholmes Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/runtime/vmStructs.cpp From bengt.rutisson at oracle.com Thu Jan 17 06:38:59 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 17 Jan 2013 15:38:59 +0100 Subject: Fwd: Re: RFR (S): 8006400: Add support for defining trace types in closed code In-Reply-To: <50F7F358.6020402@oracle.com> References: <50F6832E.9020306@oracle.com> <50F7F358.6020402@oracle.com> Message-ID: <50F80D03.2020303@oracle.com> Hi Erik, Looks good to me. (I just subscribed to the serviceability-dev mailing list, so I hope this message gets through to the list. Otherwise I'll resend it when my subscription has been confirmed.) Bengt On 1/17/13 1:49 PM, Erik Helin wrote: > > -------- Original Message -------- > Subject: Re: RFR (S): 8006400: Add support for defining trace types in > closed code > Date: Wed, 16 Jan 2013 11:38:38 +0100 > From: Erik Helin > To: serviceability-dev at openjdk.java.net > > Hi, > > Staffan Larsen pointed out an error in the file trace.xml - the types > were included after the events. > > The following updated webrev corrects this issue: > http://cr.openjdk.java.net/~ehelin/8006400/webrev.01/ > > Thanks, > Erik > > > On 01/16/2013 10:52 AM, Erik Helin wrote: >> Hi all, >> >> this change adds supports for defining trace types in closed code. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8006400/webrev.00/ >> >> Testing: >> JPRT >> >> Thanks, >> Erik > > > From john.zavgren at oracle.com Thu Jan 17 10:07:10 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Thu, 17 Jan 2013 13:07:10 -0500 Subject: RFR JDK-8005120 In-Reply-To: <6742fde2-c599-4f61-a294-5671e55f2377@default> References: <6742fde2-c599-4f61-a294-5671e55f2377@default> Message-ID: <50F83DCE.1000602@oracle.com> Greetings: I would like you to review recent changes that I made to our native socket code for the purpose of eliminating compiler warnings. These changes boil down to passing parameters with the correct type to various system calls as well as one "opportunistic" change that corrects the implementation of the macro: FT2INT64, that's used by windows: #define FT2INT64(ft) \ - ((long)(ft).dwHighDateTime << 32 | (long)(ft).dwLowDateTime) + ((INT64)(ft).dwHighDateTime << 32 | (INT64)(ft).dwLowDateTime) The webrev image is located at: http://cr.openjdk.java.net/~jzavgren/8005120/webrev.07/ Thank you! John Zavgren john.zavgren at oracle.com On 12/20/2012 05:47 PM, John Zavgren wrote: > Greetings: > > I modified my changes so that windows knows the definition of the POSIX data type: socklen_t, and now all the system calls are using the "doctrinaire" data types. > > Please consider the following update. > > http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.01/ > > Thanks! > John Zavgren > > > > On 20/12/2012 13:49, John Zavgren wrote: >> Greetings: >> >> I agree that the "correct" way to fix this problem is to use POSIX data types, e.g., socklen_t. However, when I switch to the doctrinaire data type, the build fails on windows machines: >> ------------- build monologue ----- >> c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2146: syntax error : missing ')' before identifier 'len' >> c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2081: 'socklen_t' : name in formal parameter list illegal >> c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2061: syntax error : identifier 'len' >> c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2059: syntax error : ';' >> c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2059: syntax error : ')' >> .... >> ------------- build monologue ----- >> >> I used alternative types, e.g., uint32_t, etc. as a way to avoid the limitations of windows. >> What is the recommended way to accommodate this windows limitation? Shall I use a typedef statement to define "socklen_t"? > We don't suffer from this issue in the networking native code. The unix > and windows implementations are distinct. > > I see the vm defines socklen_t in a windows specific header, > hotspot/src/os/windows/vm/jvm_windows.h, as > typedef int socklen_t; > > ...and it is then used in shared code, like jvm.cpp, and the hpi, by > optionally including > > #ifdef TARGET_OS_FAMILY_windows > # include "jvm_windows.h" > #endif > > We could use a similar, but more simplistic, approach here. > > -Chris. > >> Thanks! >> >> >> ----- Original Message ----- >> From: chris.hegarty at oracle.com >> To: david.holmes at oracle.com >> Cc: Alan.Bateman at oracle.com, serviceability-dev at openjdk.java.net, john.zavgren at oracle.com, net-dev at openjdk.java.net >> Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada Eastern >> Subject: Re: RFR JDK-8005120 >> >> On 19/12/2012 20:52, David Holmes wrote: >>> Real sense of deja-vu here. Didn't we go through this same thing with >>> the HPI socket routines? >> Yes, and the networking native code too. >> >> I think it is best to use socklen_t for the unix code. From what I can >> see making these changes, to use socklen_t, should be relatively localized. >> >> -Chris. >> >>> Depending on the OS (and version?) we should be using socklen_t not int >>> and not uint32_t. >>> >>> David >>> >>> On 20/12/2012 2:35 AM, Chris Hegarty wrote: >>>> John, >>>> >>>> I grabbed your patch, and with it I now see different warnings. >>>> >>>> ../../../../src/share/transport/socket/socketTransport.c: In function >>>> 'socketTransport_startListening': >>>> ../../../../src/share/transport/socket/socketTransport.c:310:40: >>>> warning: pointer targets in passing argument 3 of 'dbgsysGetSocketName' >>>> differ in signedness [-Wpointer-sign] >>>> ../../../../src/share/transport/socket/sysSocket.h:58:5: note: expected >>>> 'uint32_t *' but argument is of type 'int *' >>>> ../../../../src/share/transport/socket/socketTransport.c: In function >>>> 'socketTransport_accept': >>>> ../../../../src/share/transport/socket/socketTransport.c:371:33: >>>> warning: pointer targets in passing argument 3 of 'dbgsysAccept' differ >>>> in signedness [-Wpointer-sign] >>>> ../../../../src/share/transport/socket/sysSocket.h:41:5: note: expected >>>> 'uint32_t *' but argument is of type 'int *' >>>> >>>> Do you see these in your build? >>>> >>>> -Chris. >>>> >>>> On 12/19/2012 03:42 PM, Alan Bateman wrote: >>>>> John - this is the debugger socket transport so cc'ing the >>>>> serviceability-dev list as that is where this code is maintained. >>>>> >>>>> On 19/12/2012 15:36, John Zavgren wrote: >>>>>> Greetings: >>>>>> Please consider the following change to the two files: >>>>>> src/share/transport/socket/sysSocket.h >>>>>> src/solaris/transport/socket/socket_md.c >>>>>> that eliminate compiler warnings that stem from the fact that the >>>>>> variables that the native code passes to various system calls were not >>>>>> declared correctly. They were declared as integers, but they must be >>>>>> "unsigned" integers because they are used to define buffer lengths. >>>>>> Were one to supply a negative value as an argument, it would be cast >>>>>> into an unsigned "Martian" value and there'd be (hopefully) a system >>>>>> call error. >>>>>> >>>>>> Thanks! >>>>>> John Zavgren >>>>>> >>>>>> http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/ -- John Zavgren john.zavgren at oracle.com 603-821-0904 US-Burlington-MA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130117/e7902dfa/attachment-0001.html From maurizio.cimadamore at oracle.com Thu Jan 17 10:15:49 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 17 Jan 2013 18:15:49 +0000 Subject: hg: jdk8/tl/langtools: 8005852: Treatment of '_' as identifier Message-ID: <20130117181554.2FFD747375@hg.openjdk.java.net> Changeset: 2d2b2be57c78 Author: mcimadamore Date: 2013-01-17 18:15 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2d2b2be57c78 8005852: Treatment of '_' as identifier Summary: warn when '_' is found in an identifier position Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/lambda/LambdaParserTest.java From harold.seigel at oracle.com Thu Jan 17 10:49:35 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Thu, 17 Jan 2013 18:49:35 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7102489: RFE: cleanup jlong typedef on __APPLE__and _LLP64 systems. Message-ID: <20130117184945.4394947378@hg.openjdk.java.net> Changeset: 203f64878aab Author: hseigel Date: 2013-01-17 10:25 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/203f64878aab 7102489: RFE: cleanup jlong typedef on __APPLE__and _LLP64 systems. Summary: Define jlong as long on all LP64 platforms and add JLONG_FORMAT macro. Reviewed-by: dholmes, coleenp, mikael, kvn ! src/cpu/x86/vm/jni_x86.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/java_md.h ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/launcher/java_md.c ! src/os/windows/launcher/java_md.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/tools/launcher/java.c ! src/share/tools/launcher/java.h ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/aprofiler.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/taskqueue.cpp From chris.hegarty at oracle.com Thu Jan 17 11:40:29 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 17 Jan 2013 19:40:29 +0000 Subject: RFR JDK-8005120 In-Reply-To: <50F83DCE.1000602@oracle.com> References: <6742fde2-c599-4f61-a294-5671e55f2377@default> <50F83DCE.1000602@oracle.com> Message-ID: <50F853AD.5090302@oracle.com> Thank you John, Looks fine to me. I can push it for you. -Chris. On 01/17/2013 06:07 PM, John Zavgren wrote: > Greetings: > I would like you to review recent changes that I made to our native > socket code for the purpose of eliminating compiler warnings. > > These changes boil down to passing parameters with the correct type to > various system calls as well as one "opportunistic" change that corrects > the implementation of the macro: FT2INT64, that's used by windows: > #define FT2INT64(ft) \ > - ((long)(ft).dwHighDateTime << 32 | (long)(ft).dwLowDateTime) > + ((INT64)(ft).dwHighDateTime << 32 | (INT64)(ft).dwLowDateTime) > > The webrev image is located at: > http://cr.openjdk.java.net/~jzavgren/8005120/webrev.07/ > > > Thank you! > John Zavgren > john.zavgren at oracle.com > > On 12/20/2012 05:47 PM, John Zavgren wrote: >> Greetings: >> >> I modified my changes so that windows knows the definition of the POSIX data type: socklen_t, and now all the system calls are using the "doctrinaire" data types. >> >> Please consider the following update. >> >> http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.01/ >> >> Thanks! >> John Zavgren >> >> >> >> On 20/12/2012 13:49, John Zavgren wrote: >>> Greetings: >>> >>> I agree that the "correct" way to fix this problem is to use POSIX data types, e.g., socklen_t. However, when I switch to the doctrinaire data type, the build fails on windows machines: >>> ------------- build monologue ----- >>> c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2146: syntax error : missing ')' before identifier 'len' >>> c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2081: 'socklen_t' : name in formal parameter list illegal >>> c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2061: syntax error : identifier 'len' >>> c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2059: syntax error : ';' >>> c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2059: syntax error : ')' >>> .... >>> ------------- build monologue ----- >>> >>> I used alternative types, e.g., uint32_t, etc. as a way to avoid the limitations of windows. >>> What is the recommended way to accommodate this windows limitation? Shall I use a typedef statement to define "socklen_t"? >> We don't suffer from this issue in the networking native code. The unix >> and windows implementations are distinct. >> >> I see the vm defines socklen_t in a windows specific header, >> hotspot/src/os/windows/vm/jvm_windows.h, as >> typedef int socklen_t; >> >> ...and it is then used in shared code, like jvm.cpp, and the hpi, by >> optionally including >> >> #ifdef TARGET_OS_FAMILY_windows >> # include "jvm_windows.h" >> #endif >> >> We could use a similar, but more simplistic, approach here. >> >> -Chris. >> >>> Thanks! >>> >>> >>> ----- Original Message ----- >>> From:chris.hegarty at oracle.com >>> To:david.holmes at oracle.com >>> Cc:Alan.Bateman at oracle.com,serviceability-dev at openjdk.java.net,john.zavgren at oracle.com,net-dev at openjdk.java.net >>> Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada Eastern >>> Subject: Re: RFR JDK-8005120 >>> >>> On 19/12/2012 20:52, David Holmes wrote: >>>> Real sense of deja-vu here. Didn't we go through this same thing with >>>> the HPI socket routines? >>> Yes, and the networking native code too. >>> >>> I think it is best to use socklen_t for the unix code. From what I can >>> see making these changes, to use socklen_t, should be relatively localized. >>> >>> -Chris. >>> >>>> Depending on the OS (and version?) we should be using socklen_t not int >>>> and not uint32_t. >>>> >>>> David >>>> >>>> On 20/12/2012 2:35 AM, Chris Hegarty wrote: >>>>> John, >>>>> >>>>> I grabbed your patch, and with it I now see different warnings. >>>>> >>>>> ../../../../src/share/transport/socket/socketTransport.c: In function >>>>> 'socketTransport_startListening': >>>>> ../../../../src/share/transport/socket/socketTransport.c:310:40: >>>>> warning: pointer targets in passing argument 3 of 'dbgsysGetSocketName' >>>>> differ in signedness [-Wpointer-sign] >>>>> ../../../../src/share/transport/socket/sysSocket.h:58:5: note: expected >>>>> 'uint32_t *' but argument is of type 'int *' >>>>> ../../../../src/share/transport/socket/socketTransport.c: In function >>>>> 'socketTransport_accept': >>>>> ../../../../src/share/transport/socket/socketTransport.c:371:33: >>>>> warning: pointer targets in passing argument 3 of 'dbgsysAccept' differ >>>>> in signedness [-Wpointer-sign] >>>>> ../../../../src/share/transport/socket/sysSocket.h:41:5: note: expected >>>>> 'uint32_t *' but argument is of type 'int *' >>>>> >>>>> Do you see these in your build? >>>>> >>>>> -Chris. >>>>> >>>>> On 12/19/2012 03:42 PM, Alan Bateman wrote: >>>>>> John - this is the debugger socket transport so cc'ing the >>>>>> serviceability-dev list as that is where this code is maintained. >>>>>> >>>>>> On 19/12/2012 15:36, John Zavgren wrote: >>>>>>> Greetings: >>>>>>> Please consider the following change to the two files: >>>>>>> src/share/transport/socket/sysSocket.h >>>>>>> src/solaris/transport/socket/socket_md.c >>>>>>> that eliminate compiler warnings that stem from the fact that the >>>>>>> variables that the native code passes to various system calls were not >>>>>>> declared correctly. They were declared as integers, but they must be >>>>>>> "unsigned" integers because they are used to define buffer lengths. >>>>>>> Were one to supply a negative value as an argument, it would be cast >>>>>>> into an unsigned "Martian" value and there'd be (hopefully) a system >>>>>>> call error. >>>>>>> >>>>>>> Thanks! >>>>>>> John Zavgren >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/ > > > -- > John Zavgren > john.zavgren at oracle.com > 603-821-0904 > US-Burlington-MA > From staffan.larsen at oracle.com Thu Jan 17 11:48:04 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 17 Jan 2013 20:48:04 +0100 Subject: RFR: 8006423 SA: NullPointerException in sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.java:67) Message-ID: <4ACE7799-52E8-45AF-A249-DBC92FC7997E@oracle.com> This is a request for review of a fix for SA on OS X. webrev: http://cr.openjdk.java.net/~sla/8006423/webrev.00/ bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006423 The bug report contains a detailed description of the problem and the proposed solution. I have copied some of that text below. To verify the fix I have manually run jstack on OS X. Thanks, /Staffan In many cases when running the SA version of JStack (or other SA tools) an NPE is thrown in BsdThread.getContext(). The underlaying cause is that SA fails to read the context of the thread in the native method getThreadIntegerRegisterSet0() (thread_get_state returns an error). The following is my understanding of what the cause is and a suggestion for a fix - my experience with OS X is a bit limited so I may be off on some details. thread_get_state() takes a thread_t as a parameter. The value of this parameter comes from SA reading the value of the OSThread._thread_id field in the Hotspot process being debugged. This value is set in HotSpot to ::mach_thread_self() which is documented as "The mach_thread_self system call returns the calling thread's thread port." My theory is that this "thread port" in not valid when a different process calls thread_get_state(). Instead, the other process (SA in this case) needs it's own "thread port" for the thread it wants to access. There is a way to list all the thread ports in a different process (or "task" as they are called in Mach) via the task_threads() function. So now we have the thread ports, we just need to correlate them with the C++ Thread objects in the Hotspot process. One way to do this correlation is via the stack pointer. We can get the current value of the stack pointer (rsp) in SA and look through all the Thread objects to see which one the stack pointer belongs to (by looking at Thread._stack_base and Thread._stack_size). Another way seems to be to use the thread_info() function with the THREAD_IDENTIFIER_INFO parameter. This gives us a struct which has a field called thread_id. The comment for this field in the thread_info.h file says "system-wide unique 64-bit thread id". The value for this thread_id is the same when called from Hotspot and when called from the debugging process (SA), so this looks like a way to do the correlation. This requires Hotspot to store this value in OSThread and SA to first list all the "thread ports", then find the thread_id for each one and select the right "thread port" for the thread we are looking for. Using a thread_id provided by the system seems more reliable than using the stack pointer for correlation. From xueming.shen at oracle.com Thu Jan 17 12:45:04 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 17 Jan 2013 20:45:04 +0000 Subject: hg: jdk8/tl/jdk: 8006090: Formatter asserts with -esa Message-ID: <20130117204528.C49394737E@hg.openjdk.java.net> Changeset: 787c7c1c210f Author: sherman Date: 2013-01-17 12:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/787c7c1c210f 8006090: Formatter asserts with -esa Summary: removed the offending assert Reviewed-by: alanb, darcy Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/util/Formatter.java ! test/ProblemList.txt From yumin.qi at oracle.com Thu Jan 17 13:23:07 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 17 Jan 2013 13:23:07 -0800 Subject: RFR: 8003348: SA can not read core file on OS X Message-ID: <50F86BBB.8000709@oracle.com> Hi, Please review for the changes for SA to read core file on Mac OS X, this is feature is not implemented on previous releases. This change made for SA to work on core file on Darwin, but still some function not fixed, such as 'pstack'. This is intended to integrate into 8. http://cr.openjdk.java.net/~minqi/8003348/ Please take some time since the code change is a little bigger. Thanks very much Yumin From coleen.phillimore at oracle.com Thu Jan 17 13:56:13 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Jan 2013 21:56:13 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7174978: NPG: Fix bactrace builder for class redefinition Message-ID: <20130117215615.A534B47380@hg.openjdk.java.net> Changeset: b14da2e6f2dc Author: coleenp Date: 2013-01-17 13:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b14da2e6f2dc 7174978: NPG: Fix bactrace builder for class redefinition Summary: Remove Method* from backtrace but save version so redefine classes doesn't give inaccurate line numbers. Removed old Merlin API with duplicate code. Reviewed-by: dholmes, sspitsyn ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp From kurchi.subhra.hazra at oracle.com Thu Jan 17 14:44:57 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Thu, 17 Jan 2013 22:44:57 +0000 Subject: hg: jdk8/tl/jdk: 7171415: java.net.URI.equals/hashCode not consistent for some URIs Message-ID: <20130117224517.A557F4738B@hg.openjdk.java.net> Changeset: e8414d69692c Author: khazra Date: 2013-01-17 14:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8414d69692c 7171415: java.net.URI.equals/hashCode not consistent for some URIs Summary: Rewrite URI.hashCode() to consider encoded characters, also reviewed by vitalyd at gmail.com, schlosna at gmail.com Reviewed-by: chegar ! src/share/classes/java/net/URI.java ! test/java/net/URI/Test.java From fredrik.ohrstrom at oracle.com Thu Jan 17 15:19:22 2013 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Thu, 17 Jan 2013 23:19:22 +0000 Subject: hg: jdk8/tl/langtools: 8004658: Add internal smart javac wrapper to solve JEP 139 Message-ID: <20130117231925.B122947393@hg.openjdk.java.net> Changeset: 22e417cdddee Author: ohrstrom Date: 2013-01-18 00:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/22e417cdddee 8004658: Add internal smart javac wrapper to solve JEP 139 Reviewed-by: jjg ! make/build.properties ! make/build.xml + src/share/classes/com/sun/tools/sjavac/BuildState.java + src/share/classes/com/sun/tools/sjavac/CleanProperties.java + src/share/classes/com/sun/tools/sjavac/CompileChunk.java + src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java + src/share/classes/com/sun/tools/sjavac/CompileProperties.java + src/share/classes/com/sun/tools/sjavac/CopyFile.java + src/share/classes/com/sun/tools/sjavac/JavacState.java + src/share/classes/com/sun/tools/sjavac/Log.java + src/share/classes/com/sun/tools/sjavac/Main.java + src/share/classes/com/sun/tools/sjavac/Module.java + src/share/classes/com/sun/tools/sjavac/Package.java + src/share/classes/com/sun/tools/sjavac/ProblemException.java + src/share/classes/com/sun/tools/sjavac/Source.java + src/share/classes/com/sun/tools/sjavac/Transformer.java + src/share/classes/com/sun/tools/sjavac/Util.java + src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java + src/share/classes/com/sun/tools/sjavac/comp/JavaCompilerWithDeps.java + src/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java + src/share/classes/com/sun/tools/sjavac/comp/ResolveWithDeps.java + src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java + src/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java + src/share/classes/com/sun/tools/sjavac/comp/SmartWriter.java + src/share/classes/com/sun/tools/sjavac/server/CompilerPool.java + src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java + src/share/classes/com/sun/tools/sjavac/server/JavacServer.java + src/share/classes/com/sun/tools/sjavac/server/PortFile.java + src/share/classes/com/sun/tools/sjavac/server/SysInfo.java + test/tools/sjavac/SJavac.java From stuart.marks at oracle.com Thu Jan 17 15:43:10 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 17 Jan 2013 23:43:10 +0000 Subject: hg: jdk8/tl/jdk: 8006534: CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times Message-ID: <20130117234322.E862C47395@hg.openjdk.java.net> Changeset: 79fed1733d4a Author: jgish Date: 2013-01-17 15:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79fed1733d4a 8006534: CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times Summary: Increase number of retries to twice the number of ports in the reserved range Reviewed-by: mduigou ! test/java/rmi/testlibrary/TestLibrary.java From daniel.daugherty at oracle.com Thu Jan 17 18:46:09 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 17 Jan 2013 19:46:09 -0700 Subject: Errors when use "universe" command in CLHSDB In-Reply-To: References: Message-ID: <50F8B771.3080505@oracle.com> Yunda, The Serviceability Agent is maintained by the Serviceability team. I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime alias. Dan On 1/17/13 7:42 PM, ???? wrote: > > Hi all, > > This is Yunda from Alibaba Group(with OCA). > > When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar > sun.jvm.hotspot.CLHSDB) I found two errors below(the second error > occurred after I made some fix). It seemed that some code about CMS in > SA didn??t change accordingly. > > hsdb> universe > > Heap Parameters: > > Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) > space capacity = 140640256, 2.000007736049627 used > > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space > capacity = 17563648, 0.0 used > > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space > capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > > Exception in thread "main" java.lang.ExceptionInInitializerError > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:395) > > at > sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > > at > sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > > at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > > at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > > Caused by: java.lang.RuntimeException: field "_dictionary" not found > in type CompactibleFreeListSpace > > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) > > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) > > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) > > at > sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) > > at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) > > ... 14 more > > hsdb> universe > > Heap Parameters: > > Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) > space capacity = 140640256, 2.000007736049627 used > > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space > capacity = 17563648, 0.0 used > > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space > capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > > free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception > in thread "main" java.lang.ExceptionInInitializerError > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > > at > sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > > at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > > at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > > Caused by: java.lang.RuntimeException: No type named "FreeList" in > database > > at > sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) > > at > sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) > > at > sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) > > at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) > > at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) > > at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) > > at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > > at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) > > ... 11 more > > So I made a patch to fix them and now ??universe?? command works well. > Could someone help to review the patch below? > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > > +++ > b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -0,0 +1,59 @@ > > +/* > > + * @(#)AFLBinaryTreeDictionary.java > > + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights > reserved. > > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > + * > > + * This code is free software; you can redistribute it and/or modify it > > + * under the terms of the GNU General Public License version 2 only, as > > + * published by the Free Software Foundation. > > + * > > + * This code is distributed in the hope that it will be useful, but > WITHOUT > > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > > + * version 2 for more details (a copy is included in the LICENSE file > that > > + * accompanied this code). > > + * > > + * You should have received a copy of the GNU General Public License > version > > + * 2 along with this work; if not, write to the Free Software Foundation, > > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > + * > > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > > + * or visit www.oracle.com if you need additional information or have any > > + * questions. > > + * > > + */ > > + > > +package sun.jvm.hotspot.memory; > > + > > +import java.util.*; > > +import sun.jvm.hotspot.debugger.*; > > +import sun.jvm.hotspot.types.*; > > +import sun.jvm.hotspot.runtime.*; > > + > > +public class AFLBinaryTreeDictionary extends VMObject { > > + static { > > + VM.registerVMInitializedObserver(new Observer() { > > + public void update(Observable o, Object data) { > > + initialize(VM.getVM().getTypeDataBase()); > > + } > > + }); > > + } > > + > > + private static synchronized void initialize(TypeDataBase db) { > > + Type type = db.lookupType("AFLBinaryTreeDictionary"); > > + totalSizeField = type.getCIntegerField("_total_size"); > > + } > > + > > + // Fields > > + private static CIntegerField totalSizeField; > > + > > + // Accessors > > + public long size() { > > + return totalSizeField.getValue(addr); > > + } > > + > > + // Constructor > > + public AFLBinaryTreeDictionary(Address addr) { > > + super(addr); > > + } > > +} > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > > --- > a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 > > @@ -1,59 +0,0 @@ > > -/* > > - * @(#)BinaryTreeDictionary.java > > - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights > reserved. > > - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > - * > > - * This code is free software; you can redistribute it and/or modify it > > - * under the terms of the GNU General Public License version 2 only, as > > - * published by the Free Software Foundation. > > - * > > - * This code is distributed in the hope that it will be useful, but > WITHOUT > > - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > > - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > > - * version 2 for more details (a copy is included in the LICENSE file > that > > - * accompanied this code). > > - * > > - * You should have received a copy of the GNU General Public License > version > > - * 2 along with this work; if not, write to the Free Software Foundation, > > - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > - * > > - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > > - * or visit www.oracle.com if you need additional information or have any > > - * questions. > > - * > > - */ > > - > > -package sun.jvm.hotspot.memory; > > - > > -import java.util.*; > > -import sun.jvm.hotspot.debugger.*; > > -import sun.jvm.hotspot.types.*; > > -import sun.jvm.hotspot.runtime.*; > > - > > -public class BinaryTreeDictionary extends VMObject { > > - static { > > - VM.registerVMInitializedObserver(new Observer() { > > - public void update(Observable o, Object data) { > > - initialize(VM.getVM().getTypeDataBase()); > > - } > > - }); > > - } > > - > > - private static synchronized void initialize(TypeDataBase db) { > > - Type type = db.lookupType("BinaryTreeDictionary"); > > - totalSizeField = type.getCIntegerField("_totalSize"); > > - } > > - > > - // Fields > > - private static CIntegerField totalSizeField; > > - > > - // Accessors > > - public long size() { > > - return totalSizeField.getValue(addr); > > - } > > - > > - // Constructor > > - public BinaryTreeDictionary(Address addr) { > > - super(addr); > > - } > > -} > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > > --- > a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ > b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -117,7 +117,7 @@ > > } > > // large block > > - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) > VMObjectFactory.newObject(BinaryTreeDictionary.class, > > + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) > VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, > > dictionaryField.getValue(addr)); > > size += bfbd.size(); > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > > --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Thu > Jan 17 13:40:31 2013 -0500 > > +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Fri > Jan 18 09:56:06 2013 +0800 > > @@ -41,7 +41,7 @@ > > } > > private static synchronized void initialize(TypeDataBase db) { > > - Type type = db.lookupType("FreeList"); > > + Type type = db.lookupType("FreeList"); > > sizeField = type.getCIntegerField("_size"); > > countField = type.getCIntegerField("_count"); > > headerSize = type.getSize(); > > diff -r b14da2e6f2dc -r 8652e04889a4 > src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > > --- > a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Thu Jan 17 13:40:31 2013 -0500 > > +++ > b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Fri Jan 18 09:56:06 2013 +0800 > > @@ -43,7 +43,8 @@ > > nonstatic_field(LinearAllocBlock, _word_size, size_t) \ > > nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ > > nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], > FreeList) \ > > - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, > LinearAllocBlock) > > + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, > LinearAllocBlock) \ > > + nonstatic_field(CompactibleFreeListSpace, _dictionary, > FreeBlockDictionary*) > > #define VM_TYPES_CMS(declare_type, \ > > Regards, > > Yunda > > > ------------------------------------------------------------------------ > > This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please delete > it immediately and do not copy it or use it for any purpose or > disclose its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????? > ?????????????????????????????????????????????????????????? ?????????? > ???????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130117/80864768/attachment-0001.html From yunda.mly at taobao.com Thu Jan 17 19:54:35 2013 From: yunda.mly at taobao.com (=?gb2312?B?1Ma07w==?=) Date: Fri, 18 Jan 2013 03:54:35 +0000 Subject: =?gb2312?B?tPC4tDogRXJyb3JzIHdoZW4gdXNlICJ1bml2ZXJzZSIgY29tbWFuZCBpbiBD?= =?gb2312?Q?LHSDB?= In-Reply-To: <50F8B771.3080505@oracle.com> References: <50F8B771.3080505@oracle.com> Message-ID: Thanks Dan! Regards, Yunda ??????: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] ????????: 2013??1??18?? 10:46 ??????: ????; serviceability-dev at openjdk.java.net ????: Re: Errors when use "universe" command in CLHSDB Yunda, The Serviceability Agent is maintained by the Serviceability team. I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime alias. Dan On 1/17/13 7:42 PM, ???? wrote: Hi all, This is Yunda from Alibaba Group(with OCA). When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB) I found two errors below(the second error occurred after I made some fix). It seemed that some code about CMS in SA didn??t change accordingly. hsdb> universe Heap Parameters: Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 Gen 1: concurrent mark-sweep generation Exception in thread "main" java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:395) at sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Caused by: java.lang.RuntimeException: field "_dictionary" not found in type CompactibleFreeListSpace at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) at sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) at sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) ... 14 more hsdb> universe Heap Parameters: Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 Gen 1: concurrent mark-sweep generation free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception in thread "main" java.lang.ExceptionInInitializerError at sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Caused by: java.lang.RuntimeException: No type named "FreeList" in database at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) at sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) ... 11 more So I made a patch to fix them and now ??universe?? command works well. Could someone help to review the patch below? diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java Fri Jan 18 09:56:06 2013 +0800 @@ -0,0 +1,59 @@ +/* + * @(#)AFLBinaryTreeDictionary.java + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.memory; + +import java.util.*; +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.types.*; +import sun.jvm.hotspot.runtime.*; + +public class AFLBinaryTreeDictionary extends VMObject { + static { + VM.registerVMInitializedObserver(new Observer() { + public void update(Observable o, Object data) { + initialize(VM.getVM().getTypeDataBase()); + } + }); + } + + private static synchronized void initialize(TypeDataBase db) { + Type type = db.lookupType("AFLBinaryTreeDictionary"); + totalSizeField = type.getCIntegerField("_total_size"); + } + + // Fields + private static CIntegerField totalSizeField; + + // Accessors + public long size() { + return totalSizeField.getValue(addr); + } + + // Constructor + public AFLBinaryTreeDictionary(Address addr) { + super(addr); + } +} diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java Thu Jan 17 13:40:31 2013 -0500 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,59 +0,0 @@ -/* - * @(#)BinaryTreeDictionary.java - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. - * - * This code is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation. - * - * This code is distributed in the hope that it will be useful, but WITHOUT - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - * version 2 for more details (a copy is included in the LICENSE file that - * accompanied this code). - * - * You should have received a copy of the GNU General Public License version - * 2 along with this work; if not, write to the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. - * - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA - * or visit www.oracle.com if you need additional information or have any - * questions. - * - */ - -package sun.jvm.hotspot.memory; - -import java.util.*; -import sun.jvm.hotspot.debugger.*; -import sun.jvm.hotspot.types.*; -import sun.jvm.hotspot.runtime.*; - -public class BinaryTreeDictionary extends VMObject { - static { - VM.registerVMInitializedObserver(new Observer() { - public void update(Observable o, Object data) { - initialize(VM.getVM().getTypeDataBase()); - } - }); - } - - private static synchronized void initialize(TypeDataBase db) { - Type type = db.lookupType("BinaryTreeDictionary"); - totalSizeField = type.getCIntegerField("_totalSize"); - } - - // Fields - private static CIntegerField totalSizeField; - - // Accessors - public long size() { - return totalSizeField.getValue(addr); - } - - // Constructor - public BinaryTreeDictionary(Address addr) { - super(addr); - } -} diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Thu Jan 17 13:40:31 2013 -0500 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Fri Jan 18 09:56:06 2013 +0800 @@ -117,7 +117,7 @@ } // large block - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) VMObjectFactory.newObject(BinaryTreeDictionary.class, + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, dictionaryField.getValue(addr)); size += bfbd.size(); diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Thu Jan 17 13:40:31 2013 -0500 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Fri Jan 18 09:56:06 2013 +0800 @@ -41,7 +41,7 @@ } private static synchronized void initialize(TypeDataBase db) { - Type type = db.lookupType("FreeList"); + Type type = db.lookupType("FreeList"); sizeField = type.getCIntegerField("_size"); countField = type.getCIntegerField("_count"); headerSize = type.getSize(); diff -r b14da2e6f2dc -r 8652e04889a4 src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp --- a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Thu Jan 17 13:40:31 2013 -0500 +++ b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Fri Jan 18 09:56:06 2013 +0800 @@ -43,7 +43,8 @@ nonstatic_field(LinearAllocBlock, _word_size, size_t) \ nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], FreeList) \ - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) \ + nonstatic_field(CompactibleFreeListSpace, _dictionary, FreeBlockDictionary*) #define VM_TYPES_CMS(declare_type, \ Regards, Yunda ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)?????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????? ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130118/e49d4916/attachment-0001.html From mikael.gerdin at oracle.com Fri Jan 18 00:48:55 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 18 Jan 2013 09:48:55 +0100 Subject: =?GB2312?B?tPC4tDogRXJyb3JzIHdoZW4gdXNlICJ1bml2ZXJzZSIgY29tbQ==?= =?GB2312?B?YW5kIGluIENMSFNEQg==?= In-Reply-To: References: <50F8B771.3080505@oracle.com> Message-ID: <50F90C77.5070604@oracle.com> I saw an existing bug reported for this the other day: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005278 I cc:ed Yumin who currently owns the bug. /Mikael On 2013-01-18 04:54, ???? wrote: > Thanks Dan! > > Regards, > > Yunda > > *??????:*Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > *????????:*2013??1??18??10:46 > *??????:*????; serviceability-dev at openjdk.java.net > *????:*Re: Errors when use "universe" command in CLHSDB > > Yunda, > > The Serviceability Agent is maintained by the Serviceability team. > I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime > alias. > > Dan > > On 1/17/13 7:42 PM, ????wrote: > > Hi all, > > This is Yunda > from Alibaba Group(with OCA). > > When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar > sun.jvm.hotspot.CLHSDB) I found two errors below(the second error > occurred after I made some fix). It seemed that some code about CMS > in SA didn??t change accordingly. > > hsdb> universe > > Heap Parameters: > > Gen 0: eden > [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space > capacity = 140640256, 2.000007736049627 used > > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) > space capacity = 17563648, 0.0 used > > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) > space capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > > Exception in thread "main" java.lang.ExceptionInInitializerError > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > at > java.lang.reflect.Constructor.newInstance(Constructor.java:395) > > at > sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > > at > sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > > at > sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > > at > sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > > Caused by: java.lang.RuntimeException: field "_dictionary" not found > in type CompactibleFreeListSpace > > at > sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) > > at > sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) > > at > sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) > > at > sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) > > at > sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) > > ... 14 more > > hsdb> universe > > Heap Parameters: > > Gen 0: eden > [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space > capacity = 140640256, 2.000007736049627 used > > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) > space capacity = 17563648, 0.0 used > > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) > space capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > > free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception > in thread "main" java.lang.ExceptionInInitializerError > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > > at > sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > > at > sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > > at > sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > > Caused by: java.lang.RuntimeException: No type named "FreeList" in > database > > at > sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) > > at > sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) > > at > sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) > > at > sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) > > at > sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) > > at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) > > at > sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > > at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) > > ... 11 more > > So I made a patch to fix them and now ??universe?? command works well. > Could someone help to review the patch below? > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > > +++ > b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -0,0 +1,59 @@ > > +/* > > + * @(#)AFLBinaryTreeDictionary.java > > + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All > rights reserved. > > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > + * > > + * This code is free software; you can redistribute it and/or modify it > > + * under the terms of the GNU General Public License version 2 only, as > > + * published by the Free Software Foundation. > > + * > > + * This code is distributed in the hope that it will be useful, but > WITHOUT > > + * ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or > > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public > License > > + * version 2 for more details (a copy is included in the LICENSE > file that > > + * accompanied this code). > > + * > > + * You should have received a copy of the GNU General Public > License version > > + * 2 along with this work; if not, write to the Free Software > Foundation, > > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > + * > > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > > + * or visit www.oracle.com if you need > additional information or have any > > + * questions. > > + * > > + */ > > + > > +package sun.jvm.hotspot.memory; > > + > > +import java.util.*; > > +import sun.jvm.hotspot.debugger.*; > > +import sun.jvm.hotspot.types.*; > > +import sun.jvm.hotspot.runtime.*; > > + > > +public class AFLBinaryTreeDictionary extends VMObject { > > + static { > > + VM.registerVMInitializedObserver(new Observer() { > > + public void update(Observable o, Object data) { > > + initialize(VM.getVM().getTypeDataBase()); > > + } > > + }); > > + } > > + > > + private static synchronized void initialize(TypeDataBase db) { > > + Type type = db.lookupType("AFLBinaryTreeDictionary"); > > + totalSizeField = type.getCIntegerField("_total_size"); > > + } > > + > > + // Fields > > + private static CIntegerField totalSizeField; > > + > > + // Accessors > > + public long size() { > > + return totalSizeField.getValue(addr); > > + } > > + > > + // Constructor > > + public AFLBinaryTreeDictionary(Address addr) { > > + super(addr); > > + } > > +} > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > > --- > a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 > > @@ -1,59 +0,0 @@ > > -/* > > - * @(#)BinaryTreeDictionary.java > > - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All > rights reserved. > > - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > - * > > - * This code is free software; you can redistribute it and/or modify it > > - * under the terms of the GNU General Public License version 2 only, as > > - * published by the Free Software Foundation. > > - * > > - * This code is distributed in the hope that it will be useful, but > WITHOUT > > - * ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or > > - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public > License > > - * version 2 for more details (a copy is included in the LICENSE > file that > > - * accompanied this code). > > - * > > - * You should have received a copy of the GNU General Public > License version > > - * 2 along with this work; if not, write to the Free Software > Foundation, > > - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > - * > > - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > > - * or visit www.oracle.com if you need > additional information or have any > > - * questions. > > - * > > - */ > > - > > -package sun.jvm.hotspot.memory; > > - > > -import java.util.*; > > -import sun.jvm.hotspot.debugger.*; > > -import sun.jvm.hotspot.types.*; > > -import sun.jvm.hotspot.runtime.*; > > - > > -public class BinaryTreeDictionary extends VMObject { > > - static { > > - VM.registerVMInitializedObserver(new Observer() { > > - public void update(Observable o, Object data) { > > - initialize(VM.getVM().getTypeDataBase()); > > - } > > - }); > > - } > > - > > - private static synchronized void initialize(TypeDataBase db) { > > - Type type = db.lookupType("BinaryTreeDictionary"); > > - totalSizeField = type.getCIntegerField("_totalSize"); > > - } > > - > > - // Fields > > - private static CIntegerField totalSizeField; > > - > > - // Accessors > > - public long size() { > > - return totalSizeField.getValue(addr); > > - } > > - > > - // Constructor > > - public BinaryTreeDictionary(Address addr) { > > - super(addr); > > - } > > -} > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > > --- > a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ > b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -117,7 +117,7 @@ > > } > > // large block > > - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) > VMObjectFactory.newObject(BinaryTreeDictionary.class, > > + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) > VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, > > dictionaryField.getValue(addr)); > > size += bfbd.size(); > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > > --- > a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ > b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -41,7 +41,7 @@ > > } > > private static synchronized void initialize(TypeDataBase db) { > > - Type type = db.lookupType("FreeList"); > > + Type type = db.lookupType("FreeList"); > > sizeField = type.getCIntegerField("_size"); > > countField = type.getCIntegerField("_count"); > > headerSize = type.getSize(); > > diff -r b14da2e6f2dc -r 8652e04889a4 > src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > > --- > a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Thu Jan 17 13:40:31 2013 -0500 > > +++ > b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Fri Jan 18 09:56:06 2013 +0800 > > @@ -43,7 +43,8 @@ > > nonstatic_field(LinearAllocBlock, > _word_size, > size_t) \ > > nonstatic_field(AFLBinaryTreeDictionary, > _total_size, > size_t) \ > > nonstatic_field(CompactibleFreeListSpace, > _indexedFreeList[0], > FreeList) \ > > - nonstatic_field(CompactibleFreeListSpace, > _smallLinearAllocBlock, LinearAllocBlock) > > + nonstatic_field(CompactibleFreeListSpace, > _smallLinearAllocBlock, > LinearAllocBlock) \ > > + nonstatic_field(CompactibleFreeListSpace, > _dictionary, > FreeBlockDictionary*) > > #define > VM_TYPES_CMS(declare_type, \ > > Regards, > > Yunda > > ------------------------------------------------------------------------ > > > This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please > delete it immediately and do not copy it or use it for any purpose > or disclose its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????????? > ???????????????????????? > > > ------------------------------------------------------------------------ > > This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please delete > it immediately and do not copy it or use it for any purpose or disclose > its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????????????? > ???????????????? -- Mikael Gerdin Java SE VM SQE Stockholm From staffan.larsen at oracle.com Fri Jan 18 01:06:38 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Jan 2013 10:06:38 +0100 Subject: Errors when use "universe" command in CLHSDB In-Reply-To: References: <50F8B771.3080505@oracle.com> Message-ID: Yunda, I think this fixes http://bugs.sun.com/view_bug.do?bug_id=8005278 The changes look good to me. I couldn't apply the patch to the code cleanly, however (see below). Perhaps the patch was broken in email? Can you regenerate the patch and include it as a zipped attachment? Thanks, /Staffan file agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java already exists 1 out of 1 hunks FAILED -- saving rejects to file agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java.rej patching file agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Hunk #1 FAILED at 116 Hunk #2 FAILED at 40 2 out of 2 hunks FAILED -- saving rejects to file agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java.rej patching file src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Hunk #1 succeeded at 45 with fuzz 2 (offset 0 lines). patch failed, unable to continue (try -v) patch failed, rejects left in working dir On 18 jan 2013, at 04:54, ???? wrote: > > Thanks Dan! > > Regards, > Yunda > ??????: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > ????????: 2013??1??18?? 10:46 > ??????: ????; serviceability-dev at openjdk.java.net > ????: Re: Errors when use "universe" command in CLHSDB > > Yunda, > > The Serviceability Agent is maintained by the Serviceability team. > I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime > alias. > > Dan > > > On 1/17/13 7:42 PM, ???? wrote: > Hi all, > > This is Yunda from Alibaba Group(with OCA). > > When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB) I found two errors below(the second error occurred after I made some fix). It seemed that some code about CMS in SA didn??t change accordingly. > hsdb> universe > Heap Parameters: > Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > Exception in thread "main" java.lang.ExceptionInInitializerError > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:395) > at sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) > at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) > at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > Caused by: java.lang.RuntimeException: field "_dictionary" not found in type CompactibleFreeListSpace > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) > at sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) > at sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) > at sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) > at sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) > at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > at sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) > ... 14 more > > hsdb> universe > Heap Parameters: > Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception in thread "main" java.lang.ExceptionInInitializerError > at sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) > at sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) > at sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) > at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > Caused by: java.lang.RuntimeException: No type named "FreeList" in database > at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) > at sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) > at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) > at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) > at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) > at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) > at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) > ... 11 more > > So I made a patch to fix them and now ??universe?? command works well. Could someone help to review the patch below? > > diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java Fri Jan 18 09:56:06 2013 +0800 > @@ -0,0 +1,59 @@ > +/* > + * @(#)AFLBinaryTreeDictionary.java > + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + * > + */ > + > +package sun.jvm.hotspot.memory; > + > +import java.util.*; > +import sun.jvm.hotspot.debugger.*; > +import sun.jvm.hotspot.types.*; > +import sun.jvm.hotspot.runtime.*; > + > +public class AFLBinaryTreeDictionary extends VMObject { > + static { > + VM.registerVMInitializedObserver(new Observer() { > + public void update(Observable o, Object data) { > + initialize(VM.getVM().getTypeDataBase()); > + } > + }); > + } > + > + private static synchronized void initialize(TypeDataBase db) { > + Type type = db.lookupType("AFLBinaryTreeDictionary"); > + totalSizeField = type.getCIntegerField("_total_size"); > + } > + > + // Fields > + private static CIntegerField totalSizeField; > + > + // Accessors > + public long size() { > + return totalSizeField.getValue(addr); > + } > + > + // Constructor > + public AFLBinaryTreeDictionary(Address addr) { > + super(addr); > + } > +} > diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > --- a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java Thu Jan 17 13:40:31 2013 -0500 > +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 > @@ -1,59 +0,0 @@ > -/* > - * @(#)BinaryTreeDictionary.java > - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. > - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > - * > - * This code is free software; you can redistribute it and/or modify it > - * under the terms of the GNU General Public License version 2 only, as > - * published by the Free Software Foundation. > - * > - * This code is distributed in the hope that it will be useful, but WITHOUT > - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > - * version 2 for more details (a copy is included in the LICENSE file that > - * accompanied this code). > - * > - * You should have received a copy of the GNU General Public License version > - * 2 along with this work; if not, write to the Free Software Foundation, > - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > - * > - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > - * or visit www.oracle.com if you need additional information or have any > - * questions. > - * > - */ > - > -package sun.jvm.hotspot.memory; > - > -import java.util.*; > -import sun.jvm.hotspot.debugger.*; > -import sun.jvm.hotspot.types.*; > -import sun.jvm.hotspot.runtime.*; > - > -public class BinaryTreeDictionary extends VMObject { > - static { > - VM.registerVMInitializedObserver(new Observer() { > - public void update(Observable o, Object data) { > - initialize(VM.getVM().getTypeDataBase()); > - } > - }); > - } > - > - private static synchronized void initialize(TypeDataBase db) { > - Type type = db.lookupType("BinaryTreeDictionary"); > - totalSizeField = type.getCIntegerField("_totalSize"); > - } > - > - // Fields > - private static CIntegerField totalSizeField; > - > - // Accessors > - public long size() { > - return totalSizeField.getValue(addr); > - } > - > - // Constructor > - public BinaryTreeDictionary(Address addr) { > - super(addr); > - } > -} > diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > --- a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Thu Jan 17 13:40:31 2013 -0500 > +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Fri Jan 18 09:56:06 2013 +0800 > @@ -117,7 +117,7 @@ > } > // large block > - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) VMObjectFactory.newObject(BinaryTreeDictionary.class, > + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, > dictionaryField.getValue(addr)); > size += bfbd.size(); > diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Thu Jan 17 13:40:31 2013 -0500 > +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Fri Jan 18 09:56:06 2013 +0800 > @@ -41,7 +41,7 @@ > } > private static synchronized void initialize(TypeDataBase db) { > - Type type = db.lookupType("FreeList"); > + Type type = db.lookupType("FreeList"); > sizeField = type.getCIntegerField("_size"); > countField = type.getCIntegerField("_count"); > headerSize = type.getSize(); > diff -r b14da2e6f2dc -r 8652e04889a4 src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > --- a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Thu Jan 17 13:40:31 2013 -0500 > +++ b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Fri Jan 18 09:56:06 2013 +0800 > @@ -43,7 +43,8 @@ > nonstatic_field(LinearAllocBlock, _word_size, size_t) \ > nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ > nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], FreeList) \ > - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) > + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) \ > + nonstatic_field(CompactibleFreeListSpace, _dictionary, FreeBlockDictionary*) > > #define VM_TYPES_CMS(declare_type, \ > > > Regards, > Yunda > > > This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. > > ??????(????????????)?????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????? > > > > This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130118/2babcc40/attachment-0001.html From yunda.mly at taobao.com Fri Jan 18 02:22:55 2013 From: yunda.mly at taobao.com (=?gb2312?B?1Ma07w==?=) Date: Fri, 18 Jan 2013 10:22:55 +0000 Subject: =?gb2312?B?tPC4tDogRXJyb3JzIHdoZW4gdXNlICJ1bml2ZXJzZSIgY29tbWFuZCBpbiBD?= =?gb2312?Q?LHSDB?= In-Reply-To: References: <50F8B771.3080505@oracle.com> Message-ID: OK. I diffed it with the latest http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/ and I hope it works. Thanks for the review! Regards, Yunda ??????: Staffan Larsen [mailto:staffan.larsen at oracle.com] ????????: 2013??1??18?? 17:07 ??????: ???? ????: daniel.daugherty at oracle.com; serviceability-dev at openjdk.java.net ????: Re: Errors when use "universe" command in CLHSDB Yunda, I think this fixes http://bugs.sun.com/view_bug.do?bug_id=8005278 The changes look good to me. I couldn't apply the patch to the code cleanly, however (see below). Perhaps the patch was broken in email? Can you regenerate the patch and include it as a zipped attachment? Thanks, /Staffan file agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java already exists 1 out of 1 hunks FAILED -- saving rejects to file agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java.rej patching file agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Hunk #1 FAILED at 116 Hunk #2 FAILED at 40 2 out of 2 hunks FAILED -- saving rejects to file agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java.rej patching file src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Hunk #1 succeeded at 45 with fuzz 2 (offset 0 lines). patch failed, unable to continue (try -v) patch failed, rejects left in working dir On 18 jan 2013, at 04:54, ???? > wrote: Thanks Dan! Regards, Yunda ??????: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] ????????: 2013??1??18?? 10:46 ??????: ????; serviceability-dev at openjdk.java.net ????: Re: Errors when use "universe" command in CLHSDB Yunda, The Serviceability Agent is maintained by the Serviceability team. I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime alias. Dan On 1/17/13 7:42 PM, ???? wrote: Hi all, This is Yunda from Alibaba Group(with OCA). When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB) I found two errors below(the second error occurred after I made some fix). It seemed that some code about CMS in SA didn??t change accordingly. hsdb> universe Heap Parameters: Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 Gen 1: concurrent mark-sweep generation Exception in thread "main" java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:395) at sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Caused by: java.lang.RuntimeException: field "_dictionary" not found in type CompactibleFreeListSpace at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) at sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) at sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) ... 14 more hsdb> universe Heap Parameters: Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 Gen 1: concurrent mark-sweep generation free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception in thread "main" java.lang.ExceptionInInitializerError at sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Caused by: java.lang.RuntimeException: No type named "FreeList" in database at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) at sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) ... 11 more So I made a patch to fix them and now ??universe?? command works well. Could someone help to review the patch below? diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java Fri Jan 18 09:56:06 2013 +0800 @@ -0,0 +1,59 @@ +/* + * @(#)AFLBinaryTreeDictionary.java + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.memory; + +import java.util.*; +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.types.*; +import sun.jvm.hotspot.runtime.*; + +public class AFLBinaryTreeDictionary extends VMObject { + static { + VM.registerVMInitializedObserver(new Observer() { + public void update(Observable o, Object data) { + initialize(VM.getVM().getTypeDataBase()); + } + }); + } + + private static synchronized void initialize(TypeDataBase db) { + Type type = db.lookupType("AFLBinaryTreeDictionary"); + totalSizeField = type.getCIntegerField("_total_size"); + } + + // Fields + private static CIntegerField totalSizeField; + + // Accessors + public long size() { + return totalSizeField.getValue(addr); + } + + // Constructor + public AFLBinaryTreeDictionary(Address addr) { + super(addr); + } +} diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java Thu Jan 17 13:40:31 2013 -0500 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,59 +0,0 @@ -/* - * @(#)BinaryTreeDictionary.java - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. - * - * This code is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation. - * - * This code is distributed in the hope that it will be useful, but WITHOUT - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - * version 2 for more details (a copy is included in the LICENSE file that - * accompanied this code). - * - * You should have received a copy of the GNU General Public License version - * 2 along with this work; if not, write to the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. - * - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA - * or visit www.oracle.com if you need additional information or have any - * questions. - * - */ - -package sun.jvm.hotspot.memory; - -import java.util.*; -import sun.jvm.hotspot.debugger.*; -import sun.jvm.hotspot.types.*; -import sun.jvm.hotspot.runtime.*; - -public class BinaryTreeDictionary extends VMObject { - static { - VM.registerVMInitializedObserver(new Observer() { - public void update(Observable o, Object data) { - initialize(VM.getVM().getTypeDataBase()); - } - }); - } - - private static synchronized void initialize(TypeDataBase db) { - Type type = db.lookupType("BinaryTreeDictionary"); - totalSizeField = type.getCIntegerField("_totalSize"); - } - - // Fields - private static CIntegerField totalSizeField; - - // Accessors - public long size() { - return totalSizeField.getValue(addr); - } - - // Constructor - public BinaryTreeDictionary(Address addr) { - super(addr); - } -} diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Thu Jan 17 13:40:31 2013 -0500 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Fri Jan 18 09:56:06 2013 +0800 @@ -117,7 +117,7 @@ } // large block - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) VMObjectFactory.newObject(BinaryTreeDictionary.class, + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, dictionaryField.getValue(addr)); size += bfbd.size(); diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Thu Jan 17 13:40:31 2013 -0500 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Fri Jan 18 09:56:06 2013 +0800 @@ -41,7 +41,7 @@ } private static synchronized void initialize(TypeDataBase db) { - Type type = db.lookupType("FreeList"); + Type type = db.lookupType("FreeList"); sizeField = type.getCIntegerField("_size"); countField = type.getCIntegerField("_count"); headerSize = type.getSize(); diff -r b14da2e6f2dc -r 8652e04889a4 src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp --- a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Thu Jan 17 13:40:31 2013 -0500 +++ b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Fri Jan 18 09:56:06 2013 +0800 @@ -43,7 +43,8 @@ nonstatic_field(LinearAllocBlock, _word_size, size_t) \ nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], FreeList) \ - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) \ + nonstatic_field(CompactibleFreeListSpace, _dictionary, FreeBlockDictionary*) #define VM_TYPES_CMS(declare_type, \ Regards, Yunda ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)?????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????? ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130118/6fb8d65d/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: tmp.zip Type: application/x-zip-compressed Size: 1943 bytes Desc: tmp.zip Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130118/6fb8d65d/tmp-0001.zip From coleen.phillimore at oracle.com Fri Jan 18 02:35:49 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 18 Jan 2013 10:35:49 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8006548: version wrong in new constantPool code Message-ID: <20130118103557.4EA00473B0@hg.openjdk.java.net> Changeset: b5f6465019f6 Author: coleenp Date: 2013-01-17 22:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b5f6465019f6 8006548: version wrong in new constantPool code Summary: fix increment problem with saved_version Reviewed-by: dholmes ! src/share/vm/oops/constantPool.hpp From staffan.larsen at oracle.com Fri Jan 18 03:58:42 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Jan 2013 12:58:42 +0100 Subject: RFR: 8003348: SA can not read core file on OS X In-Reply-To: <50F86BBB.8000709@oracle.com> References: <50F86BBB.8000709@oracle.com> Message-ID: Thanks for doing this Yumin! I tried to apply you patch and run it, but I can't get SA to open a core file. You can see the exception I get below. Is there some kind of setup I need to do? This is against a jvmg build of Hotspot. I also noticed that you forgot to update BugSpotAgent.java with the same changes as in HotspotAgent.java. This makes the jstack tool fail. I will look at the changes more closely. Thanks, /Staffan Opening core file, please wait... Unable to open core file /cores/core.79028: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:385) at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:287) at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:146) at sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:188) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:55) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) hsdb> Input stream closed. On 17 jan 2013, at 22:23, Yumin Qi wrote: > Hi, > > Please review for the changes for SA to read core file on Mac OS X, this is feature is not implemented on previous releases. > This change made for SA to work on core file on Darwin, but still some function not fixed, such as 'pstack'. This is intended to integrate into 8. > > http://cr.openjdk.java.net/~minqi/8003348/ > > Please take some time since the code change is a little bigger. > > Thanks very much > Yumin From staffan.larsen at oracle.com Fri Jan 18 04:13:55 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Jan 2013 13:13:55 +0100 Subject: Errors when use "universe" command in CLHSDB In-Reply-To: References: <50F8B771.3080505@oracle.com> Message-ID: This patch applied cleanly. I can sponsor this fix, but we still need a review from someone with Reviewer status. Once we have that, I can push the change. Thanks, /Staffan On 18 jan 2013, at 11:22, ???? wrote: > OK. I diffed it with the latest http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/ and I hope it works. Thanks for the review! > > > Regards, > Yunda > ??????: Staffan Larsen [mailto:staffan.larsen at oracle.com] > ????????: 2013??1??18?? 17:07 > ??????: ???? > ????: daniel.daugherty at oracle.com; serviceability-dev at openjdk.java.net > ????: Re: Errors when use "universe" command in CLHSDB > > Yunda, > > I think this fixes http://bugs.sun.com/view_bug.do?bug_id=8005278 > > The changes look good to me. I couldn't apply the patch to the code cleanly, however (see below). Perhaps the patch was broken in email? Can you regenerate the patch and include it as a zipped attachment? > > Thanks, > /Staffan > > > file agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java already exists > 1 out of 1 hunks FAILED -- saving rejects to file agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java.rej > patching file agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Hunk #1 FAILED at 116 > Hunk #2 FAILED at 40 > 2 out of 2 hunks FAILED -- saving rejects to file agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java.rej > patching file src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Hunk #1 succeeded at 45 with fuzz 2 (offset 0 lines). > patch failed, unable to continue (try -v) > patch failed, rejects left in working dir > > On 18 jan 2013, at 04:54, ???? wrote: > > > > Thanks Dan! > > Regards, > Yunda > ??????: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > ????????: 2013??1??18?? 10:46 > ??????: ????; serviceability-dev at openjdk.java.net > ????: Re: Errors when use "universe" command in CLHSDB > > Yunda, > > The Serviceability Agent is maintained by the Serviceability team. > I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime > alias. > > Dan > > On 1/17/13 7:42 PM, ???? wrote: > Hi all, > > This is Yunda from Alibaba Group(with OCA). > > When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB) I found two errors below(the second error occurred after I made some fix). It seemed that some code about CMS in SA didn??t change accordingly. > hsdb> universe > Heap Parameters: > Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > Exception in thread "main" java.lang.ExceptionInInitializerError > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:395) > at sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) > at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) > at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > Caused by: java.lang.RuntimeException: field "_dictionary" not found in type CompactibleFreeListSpace > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) > at sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) > at sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) > at sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) > at sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) > at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > at sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) > ... 14 more > > hsdb> universe > Heap Parameters: > Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception in thread "main" java.lang.ExceptionInInitializerError > at sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) > at sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) > at sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) > at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > Caused by: java.lang.RuntimeException: No type named "FreeList" in database > at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) > at sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) > at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) > at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) > at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) > at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) > at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) > ... 11 more > > So I made a patch to fix them and now ??universe?? command works well. Could someone help to review the patch below? > > diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java Fri Jan 18 09:56:06 2013 +0800 > @@ -0,0 +1,59 @@ > +/* > + * @(#)AFLBinaryTreeDictionary.java > + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + * > + */ > + > +package sun.jvm.hotspot.memory; > + > +import java.util.*; > +import sun.jvm.hotspot.debugger.*; > +import sun.jvm.hotspot.types.*; > +import sun.jvm.hotspot.runtime.*; > + > +public class AFLBinaryTreeDictionary extends VMObject { > + static { > + VM.registerVMInitializedObserver(new Observer() { > + public void update(Observable o, Object data) { > + initialize(VM.getVM().getTypeDataBase()); > + } > + }); > + } > + > + private static synchronized void initialize(TypeDataBase db) { > + Type type = db.lookupType("AFLBinaryTreeDictionary"); > + totalSizeField = type.getCIntegerField("_total_size"); > + } > + > + // Fields > + private static CIntegerField totalSizeField; > + > + // Accessors > + public long size() { > + return totalSizeField.getValue(addr); > + } > + > + // Constructor > + public AFLBinaryTreeDictionary(Address addr) { > + super(addr); > + } > +} > diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > --- a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java Thu Jan 17 13:40:31 2013 -0500 > +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 > @@ -1,59 +0,0 @@ > -/* > - * @(#)BinaryTreeDictionary.java > - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. > - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > - * > - * This code is free software; you can redistribute it and/or modify it > - * under the terms of the GNU General Public License version 2 only, as > - * published by the Free Software Foundation. > - * > - * This code is distributed in the hope that it will be useful, but WITHOUT > - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > - * version 2 for more details (a copy is included in the LICENSE file that > - * accompanied this code). > - * > - * You should have received a copy of the GNU General Public License version > - * 2 along with this work; if not, write to the Free Software Foundation, > - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > - * > - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > - * or visit www.oracle.com if you need additional information or have any > - * questions. > - * > - */ > - > -package sun.jvm.hotspot.memory; > - > -import java.util.*; > -import sun.jvm.hotspot.debugger.*; > -import sun.jvm.hotspot.types.*; > -import sun.jvm.hotspot.runtime.*; > - > -public class BinaryTreeDictionary extends VMObject { > - static { > - VM.registerVMInitializedObserver(new Observer() { > - public void update(Observable o, Object data) { > - initialize(VM.getVM().getTypeDataBase()); > - } > - }); > - } > - > - private static synchronized void initialize(TypeDataBase db) { > - Type type = db.lookupType("BinaryTreeDictionary"); > - totalSizeField = type.getCIntegerField("_totalSize"); > - } > - > - // Fields > - private static CIntegerField totalSizeField; > - > - // Accessors > - public long size() { > - return totalSizeField.getValue(addr); > - } > - > - // Constructor > - public BinaryTreeDictionary(Address addr) { > - super(addr); > - } > -} > diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > --- a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Thu Jan 17 13:40:31 2013 -0500 > +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Fri Jan 18 09:56:06 2013 +0800 > @@ -117,7 +117,7 @@ > } > // large block > - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) VMObjectFactory.newObject(BinaryTreeDictionary.class, > + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, > dictionaryField.getValue(addr)); > size += bfbd.size(); > diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Thu Jan 17 13:40:31 2013 -0500 > +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Fri Jan 18 09:56:06 2013 +0800 > @@ -41,7 +41,7 @@ > } > private static synchronized void initialize(TypeDataBase db) { > - Type type = db.lookupType("FreeList"); > + Type type = db.lookupType("FreeList"); > sizeField = type.getCIntegerField("_size"); > countField = type.getCIntegerField("_count"); > headerSize = type.getSize(); > diff -r b14da2e6f2dc -r 8652e04889a4 src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > --- a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Thu Jan 17 13:40:31 2013 -0500 > +++ b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Fri Jan 18 09:56:06 2013 +0800 > @@ -43,7 +43,8 @@ > nonstatic_field(LinearAllocBlock, _word_size, size_t) \ > nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ > nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], FreeList) \ > - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) > + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) \ > + nonstatic_field(CompactibleFreeListSpace, _dictionary, FreeBlockDictionary*) > > #define VM_TYPES_CMS(declare_type, \ > > > Regards, > Yunda > > > This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. > > ??????(????????????)?????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????? > > > > This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130118/27e4bd24/attachment-0001.html From rickard.backman at oracle.com Fri Jan 18 04:58:01 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 18 Jan 2013 13:58:01 +0100 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock Message-ID: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> Hi all, would some please review the following change? With recent changes in hs24 the ProfileVM_lock is no longer in use. This small change set removes the lock. The changes that lead to this is also on their way into hsx, but are not yet there. If that change would go into hsx without this patch. I will apply it to hsx as well (if approved). http://cr.openjdk.java.net/~rbackman/8006563/ Thanks /R From aleksey.shipilev at oracle.com Fri Jan 18 05:12:44 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 18 Jan 2013 17:12:44 +0400 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> Message-ID: <50F94A4C.4040907@oracle.com> On 01/18/2013 04:58 PM, Rickard B?ckman wrote: > http://cr.openjdk.java.net/~rbackman/8006563/ Looks good to me (not a Reviewer), modulo: a) Are we sure this thing is not acquired in some weird way, i.e. through JVMTI, SA, or whatnot? b) The formatting of the predicate does not follow it's structure, I think it should be: ... this != Interrupt_lock && !(this == Safepoint_lock && contains(locks, Terminator_lock) && SafepointSynchronize::is_synchronizing())) { This way it is more obvious SafepointSynchronize::is_synchronizing()) is the !(...) group. -Aleksey. From rickard.backman at oracle.com Fri Jan 18 05:45:21 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 18 Jan 2013 14:45:21 +0100 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <50F94A4C.4040907@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> Message-ID: <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> Aleksey, thanks for your review! a) It was before on of my own changes used in os_solaris.cpp (I think, for synchronization support for Suspend/Resume). I don't think we wanted something external to mess with that lock. b) I've changed the indentation slightly. Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) /R On Jan 18, 2013, at 2:12 PM, Aleksey Shipilev wrote: > On 01/18/2013 04:58 PM, Rickard B?ckman wrote: >> http://cr.openjdk.java.net/~rbackman/8006563/ > > Looks good to me (not a Reviewer), modulo: > a) Are we sure this thing is not acquired in some weird way, i.e. > through JVMTI, SA, or whatnot? > b) The formatting of the predicate does not follow it's structure, I > think it should be: > ... > this != Interrupt_lock && > !(this == Safepoint_lock && > contains(locks, Terminator_lock) && > SafepointSynchronize::is_synchronizing())) { > > This way it is more obvious SafepointSynchronize::is_synchronizing()) is > the !(...) group. > > -Aleksey. > > From aleksey.shipilev at oracle.com Fri Jan 18 05:47:45 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 18 Jan 2013 17:47:45 +0400 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> Message-ID: <50F95281.7080700@oracle.com> On 01/18/2013 05:45 PM, Rickard B?ckman wrote: > b) I've changed the indentation slightly. > Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) Thumbs up. -Aleksey. From staffan.larsen at oracle.com Fri Jan 18 05:56:55 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Jan 2013 14:56:55 +0100 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> Message-ID: <8386E45F-180E-4753-B323-A1AB7DB67B0F@oracle.com> Looks good! /Staffan On 18 jan 2013, at 14:45, Rickard B?ckman wrote: > Aleksey, > > thanks for your review! > > a) It was before on of my own changes used in os_solaris.cpp (I think, for synchronization support for Suspend/Resume). > I don't think we wanted something external to mess with that lock. > > b) I've changed the indentation slightly. > Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) > > /R > > On Jan 18, 2013, at 2:12 PM, Aleksey Shipilev wrote: > >> On 01/18/2013 04:58 PM, Rickard B?ckman wrote: >>> http://cr.openjdk.java.net/~rbackman/8006563/ >> >> Looks good to me (not a Reviewer), modulo: >> a) Are we sure this thing is not acquired in some weird way, i.e. >> through JVMTI, SA, or whatnot? >> b) The formatting of the predicate does not follow it's structure, I >> think it should be: >> ... >> this != Interrupt_lock && >> !(this == Safepoint_lock && >> contains(locks, Terminator_lock) && >> SafepointSynchronize::is_synchronizing())) { >> >> This way it is more obvious SafepointSynchronize::is_synchronizing()) is >> the !(...) group. >> >> -Aleksey. >> >> > From maurizio.cimadamore at oracle.com Fri Jan 18 07:58:03 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 18 Jan 2013 15:58:03 +0000 Subject: hg: jdk8/tl/langtools: 8006561: Langtools test failure: missing diags/examples Message-ID: <20130118155811.3B471473BF@hg.openjdk.java.net> Changeset: 3d84ae209919 Author: mcimadamore Date: 2013-01-18 15:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d84ae209919 8006561: Langtools test failure: missing diags/examples Summary: forgot to hg add tests Reviewed-by: jjg + test/tools/javac/diags/examples/UnderscoreAsIdentifier.java + test/tools/javac/lambda/WarnUnderscoreAsIdent.java + test/tools/javac/lambda/WarnUnderscoreAsIdent.out From yumin.qi at oracle.com Fri Jan 18 08:19:13 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 18 Jan 2013 08:19:13 -0800 Subject: RFR: 8003348: SA can not read core file on OS X In-Reply-To: References: <50F86BBB.8000709@oracle.com> Message-ID: <50F97601.1080407@oracle.com> This should be essential change in the fix, let me check if I missed file in the list. Thanks Yumin On 1/18/2013 3:58 AM, Staffan Larsen wrote: > Thanks for doing this Yumin! > > I tried to apply you patch and run it, but I can't get SA to open a core file. You can see the exception I get below. Is there some kind of setup I need to do? This is against a jvmg build of Hotspot. > > I also noticed that you forgot to update BugSpotAgent.java with the same changes as in HotspotAgent.java. This makes the jstack tool fail. > > I will look at the changes more closely. > > Thanks, > /Staffan > > > > Opening core file, please wait... > Unable to open core file > /cores/core.79028: > > Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in > remote process) > sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) > at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:385) > at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:287) > at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:146) > at sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:188) > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:55) > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > hsdb> Input stream closed. > > > On 17 jan 2013, at 22:23, Yumin Qi wrote: > >> Hi, >> >> Please review for the changes for SA to read core file on Mac OS X, this is feature is not implemented on previous releases. >> This change made for SA to work on core file on Darwin, but still some function not fixed, such as 'pstack'. This is intended to integrate into 8. >> >> http://cr.openjdk.java.net/~minqi/8003348/ >> >> Please take some time since the code change is a little bigger. >> >> Thanks very much >> Yumin From chris.hegarty at oracle.com Fri Jan 18 09:36:01 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 18 Jan 2013 17:36:01 +0000 Subject: hg: jdk8/tl/jdk: 8005120: Compiler warnings in socket transport native code Message-ID: <20130118173649.6DD71473CC@hg.openjdk.java.net> Changeset: f88e963960ae Author: jzavgren Date: 2013-01-18 17:34 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f88e963960ae 8005120: Compiler warnings in socket transport native code Reviewed-by: chegar, dsamersoff ! src/share/transport/socket/socketTransport.c ! src/share/transport/socket/sysSocket.h ! src/solaris/transport/socket/socket_md.c ! src/windows/transport/socket/socket_md.c From alan.bateman at oracle.com Fri Jan 18 10:50:49 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 18 Jan 2013 18:50:49 +0000 Subject: hg: jdk8/tl/jdk: 6939260: (fs) BasicFileAttributes.lastModifiedTime() should return last modified time with higher precision Message-ID: <20130118185127.5897A473D5@hg.openjdk.java.net> Changeset: 06da87777d0e Author: alanb Date: 2013-01-18 18:48 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06da87777d0e 6939260: (fs) BasicFileAttributes.lastModifiedTime() should return last modified time with higher precision Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c ! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java From yumin.qi at oracle.com Fri Jan 18 12:22:21 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 18 Jan 2013 12:22:21 -0800 Subject: RFR: 8003348: SA can not read core file on OS X In-Reply-To: References: <50F86BBB.8000709@oracle.com> Message-ID: <50F9AEFD.4010301@oracle.com> Hi, Staffan and all I have updated the webrev to reflect the changes of BugSpotAgent.java. Staffan, possibly you did not copy sa-jdi.jar file to your binary to cause this exception. Thanks Yumin On 1/18/2013 3:58 AM, Staffan Larsen wrote: > Thanks for doing this Yumin! > > I tried to apply you patch and run it, but I can't get SA to open a core file. You can see the exception I get below. Is there some kind of setup I need to do? This is against a jvmg build of Hotspot. > > I also noticed that you forgot to update BugSpotAgent.java with the same changes as in HotspotAgent.java. This makes the jstack tool fail. > > I will look at the changes more closely. > > Thanks, > /Staffan > > > > Opening core file, please wait... > Unable to open core file > /cores/core.79028: > > Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in > remote process) > sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) > at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:385) > at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:287) > at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:146) > at sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:188) > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:55) > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > hsdb> Input stream closed. > > > On 17 jan 2013, at 22:23, Yumin Qi wrote: > >> Hi, >> >> Please review for the changes for SA to read core file on Mac OS X, this is feature is not implemented on previous releases. >> This change made for SA to work on core file on Darwin, but still some function not fixed, such as 'pstack'. This is intended to integrate into 8. >> >> http://cr.openjdk.java.net/~minqi/8003348/ >> >> Please take some time since the code change is a little bigger. >> >> Thanks very much >> Yumin From chris.hegarty at oracle.com Sat Jan 19 00:40:34 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 19 Jan 2013 08:40:34 +0000 Subject: hg: jdk8/tl/jdk: 8006568: HTTP protocol handler NLTM Authentication should use Base64 API Message-ID: <20130119084055.AA3A0473F2@hg.openjdk.java.net> Changeset: 33d0175ea8d9 Author: msheppar Date: 2013-01-19 08:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33d0175ea8d9 8006568: HTTP protocol handler NLTM Authentication should use Base64 API Reviewed-by: chegar, alanb ! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! test/sun/net/www/protocol/http/ProxyTunnelServer.java From lance.andersen at oracle.com Sat Jan 19 07:12:19 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Sat, 19 Jan 2013 15:12:19 +0000 Subject: hg: jdk8/tl/jdk: 8006139: add missing methods to javax.sql.rowset.serial.SQLInputImpl, SQLOutputImpl Message-ID: <20130119151254.BFB80473F3@hg.openjdk.java.net> Changeset: 78514544980d Author: lancea Date: 2013-01-19 10:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78514544980d 8006139: add missing methods to javax.sql.rowset.serial.SQLInputImpl, SQLOutputImpl Reviewed-by: naoto, ulfzibis, alanb ! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java From lance.andersen at oracle.com Sat Jan 19 07:53:33 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Sat, 19 Jan 2013 15:53:33 +0000 Subject: hg: jdk8/tl/jdk: 8005080: JDBC 4.2 Core changes Message-ID: <20130119155356.2F255473F4@hg.openjdk.java.net> Changeset: d3da0d29d7cd Author: lancea Date: 2013-01-19 10:53 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3da0d29d7cd 8005080: JDBC 4.2 Core changes Reviewed-by: naoto ! src/share/classes/java/sql/BatchUpdateException.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/Driver.java ! src/share/classes/java/sql/DriverManager.java + src/share/classes/java/sql/JDBCType.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLTimeoutException.java + src/share/classes/java/sql/SQLType.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/sql/Types.java ! src/share/classes/java/sql/package.html ! src/share/classes/javax/sql/DataSource.java ! src/share/classes/javax/sql/XADataSource.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java From chris.hegarty at oracle.com Sun Jan 20 01:39:14 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 20 Jan 2013 09:39:14 +0000 Subject: hg: jdk8/tl/jdk: 8006560: java/net/ipv6tests/B6521014.java fails intermittently Message-ID: <20130120093937.554AE47407@hg.openjdk.java.net> Changeset: bb2ed83676d2 Author: chegar Date: 2013-01-20 09:37 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb2ed83676d2 8006560: java/net/ipv6tests/B6521014.java fails intermittently Reviewed-by: khazra, wetmore ! test/java/net/ipv6tests/B6521014.java From david.holmes at oracle.com Sun Jan 20 17:59:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2013 11:59:48 +1000 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> Message-ID: <50FCA114.7030908@oracle.com> On 18/01/2013 11:45 PM, Rickard B?ckman wrote: > Aleksey, > > thanks for your review! > > a) It was before on of my own changes used in os_solaris.cpp (I think, for synchronization support for Suspend/Resume). > I don't think we wanted something external to mess with that lock. Seems to be used here: ./os/solaris/vm/os_solaris.cpp: 4265 GetThreadPC_Callback cb(ProfileVM_lock); Is this code already undergoing removal as part of the JFR changes? Thanks, David ----- > b) I've changed the indentation slightly. > Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) > > /R > > On Jan 18, 2013, at 2:12 PM, Aleksey Shipilev wrote: > >> On 01/18/2013 04:58 PM, Rickard B?ckman wrote: >>> http://cr.openjdk.java.net/~rbackman/8006563/ >> >> Looks good to me (not a Reviewer), modulo: >> a) Are we sure this thing is not acquired in some weird way, i.e. >> through JVMTI, SA, or whatnot? >> b) The formatting of the predicate does not follow it's structure, I >> think it should be: >> ... >> this != Interrupt_lock&& >> !(this == Safepoint_lock&& >> contains(locks, Terminator_lock)&& >> SafepointSynchronize::is_synchronizing())) { >> >> This way it is more obvious SafepointSynchronize::is_synchronizing()) is >> the !(...) group. >> >> -Aleksey. >> >> > From yunda.mly at taobao.com Sun Jan 20 18:03:37 2013 From: yunda.mly at taobao.com (=?gb2312?B?1Ma07w==?=) Date: Mon, 21 Jan 2013 02:03:37 +0000 Subject: =?gb2312?B?tPC4tDogRXJyb3JzIHdoZW4gdXNlICJ1bml2ZXJzZSIgY29tbWFuZCBpbiBD?= =?gb2312?Q?LHSDB?= In-Reply-To: References: <50F8B771.3080505@oracle.com> Message-ID: Thanks for your review again. Could someone with Reviewer status help me with this? Thanks in advance! Regards, Yunda ??????: Staffan Larsen [mailto:staffan.larsen at oracle.com] ????????: 2013??1??18?? 20:14 ??????: ???? ????: daniel.daugherty at oracle.com; serviceability-dev at openjdk.java.net ????: Re: Errors when use "universe" command in CLHSDB This patch applied cleanly. I can sponsor this fix, but we still need a review from someone with Reviewer status. Once we have that, I can push the change. Thanks, /Staffan On 18 jan 2013, at 11:22, ???? > wrote: OK. I diffed it with the latest http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/ and I hope it works. Thanks for the review! Regards, Yunda ??????: Staffan Larsen [mailto:staffan.larsen at oracle.com] ????????: 2013??1??18?? 17:07 ??????: ???? ????: daniel.daugherty at oracle.com; serviceability-dev at openjdk.java.net ????: Re: Errors when use "universe" command in CLHSDB Yunda, I think this fixes http://bugs.sun.com/view_bug.do?bug_id=8005278 The changes look good to me. I couldn't apply the patch to the code cleanly, however (see below). Perhaps the patch was broken in email? Can you regenerate the patch and include it as a zipped attachment? Thanks, /Staffan file agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java already exists 1 out of 1 hunks FAILED -- saving rejects to file agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java.rej patching file agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Hunk #1 FAILED at 116 Hunk #2 FAILED at 40 2 out of 2 hunks FAILED -- saving rejects to file agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java.rej patching file src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Hunk #1 succeeded at 45 with fuzz 2 (offset 0 lines). patch failed, unable to continue (try -v) patch failed, rejects left in working dir On 18 jan 2013, at 04:54, ???? > wrote: Thanks Dan! Regards, Yunda ??????: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] ????????: 2013??1??18?? 10:46 ??????: ????; serviceability-dev at openjdk.java.net ????: Re: Errors when use "universe" command in CLHSDB Yunda, The Serviceability Agent is maintained by the Serviceability team. I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime alias. Dan On 1/17/13 7:42 PM, ???? wrote: Hi all, This is Yunda from Alibaba Group(with OCA). When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB) I found two errors below(the second error occurred after I made some fix). It seemed that some code about CMS in SA didn??t change accordingly. hsdb> universe Heap Parameters: Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 Gen 1: concurrent mark-sweep generation Exception in thread "main" java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:395) at sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Caused by: java.lang.RuntimeException: field "_dictionary" not found in type CompactibleFreeListSpace at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) at sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) at sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) ... 14 more hsdb> universe Heap Parameters: Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 Gen 1: concurrent mark-sweep generation free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception in thread "main" java.lang.ExceptionInInitializerError at sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Caused by: java.lang.RuntimeException: No type named "FreeList" in database at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) at sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) ... 11 more So I made a patch to fix them and now ??universe?? command works well. Could someone help to review the patch below? diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java Fri Jan 18 09:56:06 2013 +0800 @@ -0,0 +1,59 @@ +/* + * @(#)AFLBinaryTreeDictionary.java + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.memory; + +import java.util.*; +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.types.*; +import sun.jvm.hotspot.runtime.*; + +public class AFLBinaryTreeDictionary extends VMObject { + static { + VM.registerVMInitializedObserver(new Observer() { + public void update(Observable o, Object data) { + initialize(VM.getVM().getTypeDataBase()); + } + }); + } + + private static synchronized void initialize(TypeDataBase db) { + Type type = db.lookupType("AFLBinaryTreeDictionary"); + totalSizeField = type.getCIntegerField("_total_size"); + } + + // Fields + private static CIntegerField totalSizeField; + + // Accessors + public long size() { + return totalSizeField.getValue(addr); + } + + // Constructor + public AFLBinaryTreeDictionary(Address addr) { + super(addr); + } +} diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java Thu Jan 17 13:40:31 2013 -0500 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,59 +0,0 @@ -/* - * @(#)BinaryTreeDictionary.java - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. - * - * This code is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation. - * - * This code is distributed in the hope that it will be useful, but WITHOUT - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - * version 2 for more details (a copy is included in the LICENSE file that - * accompanied this code). - * - * You should have received a copy of the GNU General Public License version - * 2 along with this work; if not, write to the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. - * - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA - * or visit www.oracle.com if you need additional information or have any - * questions. - * - */ - -package sun.jvm.hotspot.memory; - -import java.util.*; -import sun.jvm.hotspot.debugger.*; -import sun.jvm.hotspot.types.*; -import sun.jvm.hotspot.runtime.*; - -public class BinaryTreeDictionary extends VMObject { - static { - VM.registerVMInitializedObserver(new Observer() { - public void update(Observable o, Object data) { - initialize(VM.getVM().getTypeDataBase()); - } - }); - } - - private static synchronized void initialize(TypeDataBase db) { - Type type = db.lookupType("BinaryTreeDictionary"); - totalSizeField = type.getCIntegerField("_totalSize"); - } - - // Fields - private static CIntegerField totalSizeField; - - // Accessors - public long size() { - return totalSizeField.getValue(addr); - } - - // Constructor - public BinaryTreeDictionary(Address addr) { - super(addr); - } -} diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Thu Jan 17 13:40:31 2013 -0500 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Fri Jan 18 09:56:06 2013 +0800 @@ -117,7 +117,7 @@ } // large block - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) VMObjectFactory.newObject(BinaryTreeDictionary.class, + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, dictionaryField.getValue(addr)); size += bfbd.size(); diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Thu Jan 17 13:40:31 2013 -0500 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Fri Jan 18 09:56:06 2013 +0800 @@ -41,7 +41,7 @@ } private static synchronized void initialize(TypeDataBase db) { - Type type = db.lookupType("FreeList"); + Type type = db.lookupType("FreeList"); sizeField = type.getCIntegerField("_size"); countField = type.getCIntegerField("_count"); headerSize = type.getSize(); diff -r b14da2e6f2dc -r 8652e04889a4 src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp --- a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Thu Jan 17 13:40:31 2013 -0500 +++ b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Fri Jan 18 09:56:06 2013 +0800 @@ -43,7 +43,8 @@ nonstatic_field(LinearAllocBlock, _word_size, size_t) \ nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], FreeList) \ - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) \ + nonstatic_field(CompactibleFreeListSpace, _dictionary, FreeBlockDictionary*) #define VM_TYPES_CMS(declare_type, \ Regards, Yunda ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)?????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????? ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130121/a598b326/attachment-0001.html From david.holmes at oracle.com Sun Jan 20 18:44:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2013 12:44:43 +1000 Subject: =?GB2312?B?tPC4tDogRXJyb3JzIHdoZW4gdXNlICJ1bml2ZXJzZSIgY29tbQ==?= =?GB2312?B?YW5kIGluIENMSFNEQg==?= In-Reply-To: References: <50F8B771.3080505@oracle.com> Message-ID: <50FCAB9B.3080107@oracle.com> I couldn't quite understand the problem and fix from the patch. Why do we need to add AFLBinaryTreeDictionary ?? Thanks, David On 21/01/2013 12:03 PM, ???? wrote: > Thanks for your review again. Could someone with Reviewer status help me > with this? Thanks in advance! > > Regards, > > Yunda > > *??????:*Staffan Larsen [mailto:staffan.larsen at oracle.com] > *????????:*2013??1??18??20:14 > *??????:*???? > *????:*daniel.daugherty at oracle.com; serviceability-dev at openjdk.java.net > *????:*Re: Errors when use "universe" command in CLHSDB > > This patch applied cleanly. > > I can sponsor this fix, but we still need a review from someone with > Reviewer status. Once we have that, I can push the change. > > Thanks, > > /Staffan > > On 18 jan 2013, at 11:22, ???? > wrote: > > > > OK. I diffed it with the > latesthttp://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/and I hope it > works. Thanks for the review! > > Regards, > > Yunda > > *??????:*Staffan Larsen [mailto:staffan.larsen at oracle.com > ] > *????????:*2013??1??18??17:07 > *??????:*???? > *????:*daniel.daugherty at oracle.com ; > serviceability-dev at openjdk.java.net > > *????:*Re: Errors when use "universe" command in CLHSDB > > Yunda, > > I think this fixes http://bugs.sun.com/view_bug.do?bug_id=8005278 > > The changes look good to me. I couldn't apply the patch to the code > cleanly, however (see below). Perhaps the patch was broken in email? Can > you regenerate the patch and include it as a zipped attachment? > > Thanks, > > /Staffan > > file > agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > already exists > 1 out of 1 hunks FAILED -- saving rejects to file > agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java.rej > patching file > agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Hunk #1 FAILED at 116 > Hunk #2 FAILED at 40 > 2 out of 2 hunks FAILED -- saving rejects to file > agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java.rej > patching file > src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Hunk #1 succeeded at 45 with fuzz 2 (offset 0 lines). > patch failed, unable to continue (try -v) > patch failed, rejects left in working dir > > On 18 jan 2013, at 04:54,???? > wrote: > > > > > Thanks Dan! > > Regards, > > Yunda > > *??????:*Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com > ] > *????????:*2013??1??18??10:46 > *??????:*????;serviceability-dev at openjdk.java.net > > *????:*Re: Errors when use "universe" command in CLHSDB > > Yunda, > > The Serviceability Agent is maintained by the Serviceability team. > I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime > alias. > > Dan > > On 1/17/13 7:42 PM,????wrote: > > Hi all, > > This is Yunda > from Alibaba Group(with OCA). > > When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar > sun.jvm.hotspot.CLHSDB) I found two errors below(the second error > occurred after I made some fix). It seemed that some code about CMS > in SA didn??t change accordingly. > > hsdb> universe > > Heap Parameters: > > Gen 0: eden > [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space > capacity = 140640256, 2.000007736049627 used > > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) > space capacity = 17563648, 0.0 used > > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space > capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > > Exception in thread "main" java.lang.ExceptionInInitializerError > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:395) > > at > sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > > at > sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > > at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > > at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > > Caused by: java.lang.RuntimeException: field "_dictionary" not found > in type CompactibleFreeListSpace > > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) > > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) > > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) > > at > sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) > > at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) > > ... 14 more > > hsdb> universe > > Heap Parameters: > > Gen 0: eden > [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space > capacity = 140640256, 2.000007736049627 used > > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) > space capacity = 17563648, 0.0 used > > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space > capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > > free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception > in thread "main" java.lang.ExceptionInInitializerError > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > > at > sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > > at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > > at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > > Caused by: java.lang.RuntimeException: No type named "FreeList" in > database > > at > sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) > > at > sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) > > at > sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) > > at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) > > at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) > > at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) > > at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > > at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) > > ... 11 more > > So I made a patch to fix them and now ??universe?? command works well. > Could someone help to review the patch below? > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > > +++ > b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -0,0 +1,59 @@ > > +/* > > + * @(#)AFLBinaryTreeDictionary.java > > + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All > rights reserved. > > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > + * > > + * This code is free software; you can redistribute it and/or modify it > > + * under the terms of the GNU General Public License version 2 only, as > > + * published by the Free Software Foundation. > > + * > > + * This code is distributed in the hope that it will be useful, but > WITHOUT > > + * ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or > > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > > + * version 2 for more details (a copy is included in the LICENSE > file that > > + * accompanied this code). > > + * > > + * You should have received a copy of the GNU General Public > License version > > + * 2 along with this work; if not, write to the Free Software > Foundation, > > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > + * > > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > > + * or visitwww.oracle.com if you need > additional information or have any > > + * questions. > > + * > > + */ > > + > > +package sun.jvm.hotspot.memory; > > + > > +import java.util.*; > > +import sun.jvm.hotspot.debugger.*; > > +import sun.jvm.hotspot.types.*; > > +import sun.jvm.hotspot.runtime.*; > > + > > +public class AFLBinaryTreeDictionary extends VMObject { > > + static { > > + VM.registerVMInitializedObserver(new Observer() { > > + public void update(Observable o, Object data) { > > + initialize(VM.getVM().getTypeDataBase()); > > + } > > + }); > > + } > > + > > + private static synchronized void initialize(TypeDataBase db) { > > + Type type = db.lookupType("AFLBinaryTreeDictionary"); > > + totalSizeField = type.getCIntegerField("_total_size"); > > + } > > + > > + // Fields > > + private static CIntegerField totalSizeField; > > + > > + // Accessors > > + public long size() { > > + return totalSizeField.getValue(addr); > > + } > > + > > + // Constructor > > + public AFLBinaryTreeDictionary(Address addr) { > > + super(addr); > > + } > > +} > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > > --- > a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 > > @@ -1,59 +0,0 @@ > > -/* > > - * @(#)BinaryTreeDictionary.java > > - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All > rights reserved. > > - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > - * > > - * This code is free software; you can redistribute it and/or modify it > > - * under the terms of the GNU General Public License version 2 only, as > > - * published by the Free Software Foundation. > > - * > > - * This code is distributed in the hope that it will be useful, but > WITHOUT > > - * ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or > > - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > > - * version 2 for more details (a copy is included in the LICENSE > file that > > - * accompanied this code). > > - * > > - * You should have received a copy of the GNU General Public > License version > > - * 2 along with this work; if not, write to the Free Software > Foundation, > > - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > - * > > - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > > - * or visitwww.oracle.com if you need > additional information or have any > > - * questions. > > - * > > - */ > > - > > -package sun.jvm.hotspot.memory; > > - > > -import java.util.*; > > -import sun.jvm.hotspot.debugger.*; > > -import sun.jvm.hotspot.types.*; > > -import sun.jvm.hotspot.runtime.*; > > - > > -public class BinaryTreeDictionary extends VMObject { > > - static { > > - VM.registerVMInitializedObserver(new Observer() { > > - public void update(Observable o, Object data) { > > - initialize(VM.getVM().getTypeDataBase()); > > - } > > - }); > > - } > > - > > - private static synchronized void initialize(TypeDataBase db) { > > - Type type = db.lookupType("BinaryTreeDictionary"); > > - totalSizeField = type.getCIntegerField("_totalSize"); > > - } > > - > > - // Fields > > - private static CIntegerField totalSizeField; > > - > > - // Accessors > > - public long size() { > > - return totalSizeField.getValue(addr); > > - } > > - > > - // Constructor > > - public BinaryTreeDictionary(Address addr) { > > - super(addr); > > - } > > -} > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > > --- > a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ > b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -117,7 +117,7 @@ > > } > > // large block > > - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) > VMObjectFactory.newObject(BinaryTreeDictionary.class, > > + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) > VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, > > dictionaryField.getValue(addr)); > > size += bfbd.size(); > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > > --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -41,7 +41,7 @@ > > } > > private static synchronized void initialize(TypeDataBase db) { > > - Type type = db.lookupType("FreeList"); > > + Type type = db.lookupType("FreeList"); > > sizeField = type.getCIntegerField("_size"); > > countField = type.getCIntegerField("_count"); > > headerSize = type.getSize(); > > diff -r b14da2e6f2dc -r 8652e04889a4 > src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > > --- > a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Thu Jan 17 13:40:31 2013 -0500 > > +++ > b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Fri Jan 18 09:56:06 2013 +0800 > > @@ -43,7 +43,8 @@ > > nonstatic_field(LinearAllocBlock, _word_size, size_t) \ > > nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ > > nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], > FreeList) \ > > - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, > LinearAllocBlock) > > + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, > LinearAllocBlock) \ > > + nonstatic_field(CompactibleFreeListSpace, _dictionary, > FreeBlockDictionary*) > > #define VM_TYPES_CMS(declare_type, \ > > Regards, > > Yunda > > ------------------------------------------------------------------------ > > > This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please > delete it immediately and do not copy it or use it for any purpose > or disclose its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????????? > ???????????????????????? > > ------------------------------------------------------------------------ > > > This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please delete > it immediately and do not copy it or use it for any purpose or disclose > its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????????????? > ???????????????? > > > From masayoshi.okutsu at oracle.com Sun Jan 20 19:06:51 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Mon, 21 Jan 2013 03:06:51 +0000 Subject: hg: jdk8/tl/jdk: 4745761: (cal) RFE: Support builder for constructing Calendar Message-ID: <20130121030714.D5F3D47410@hg.openjdk.java.net> Changeset: 6ca6b6f07653 Author: okutsu Date: 2013-01-21 12:04 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ca6b6f07653 4745761: (cal) RFE: Support builder for constructing Calendar Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java + test/java/util/Calendar/Builder/BuilderTest.java ! test/java/util/Calendar/CalendarTypeTest.java From yunda.mly at taobao.com Sun Jan 20 19:06:44 2013 From: yunda.mly at taobao.com (=?gb2312?B?1Ma07w==?=) Date: Mon, 21 Jan 2013 03:06:44 +0000 Subject: =?gb2312?B?tPC4tDogtPC4tDogRXJyb3JzIHdoZW4gdXNlICJ1bml2ZXJzZSIgY29tbWFu?= =?gb2312?Q?d_in_CLHSDB?= In-Reply-To: <50FCAB9B.3080107@oracle.com> References: <50F8B771.3080505@oracle.com> <50FCAB9B.3080107@oracle.com> Message-ID: Actually I just changed "BinaryTreeDictionary" to "AFLBinaryTreeDictionary", since there is no definition of BinaryTreeDictionary in the latest hotspot: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/file/b5f6465019f6/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp , which has been changed to AFLBinaryTreeDictionary. So the code in SA has to change too. The bug is already found here: http://bugs.sun.com/view_bug.do?bug_id=8005278 Regards, Yunda -----????????----- ??????: David Holmes [mailto:david.holmes at oracle.com] ????????: 2013??1??21?? 10:45 ??????: ???? ????: Staffan Larsen; serviceability-dev at openjdk.java.net ????: Re: ????: Errors when use "universe" command in CLHSDB I couldn't quite understand the problem and fix from the patch. Why do we need to add AFLBinaryTreeDictionary ?? Thanks, David On 21/01/2013 12:03 PM, ???? wrote: > Thanks for your review again. Could someone with Reviewer status help > me with this? Thanks in advance! > > Regards, > > Yunda > > *??????:*Staffan Larsen [mailto:staffan.larsen at oracle.com] > *????????:*2013??1??18??20:14 > *??????:*???? > *????:*daniel.daugherty at oracle.com; serviceability-dev at openjdk.java.net > *????:*Re: Errors when use "universe" command in CLHSDB > > This patch applied cleanly. > > I can sponsor this fix, but we still need a review from someone with > Reviewer status. Once we have that, I can push the change. > > Thanks, > > /Staffan > > On 18 jan 2013, at 11:22, ???? > wrote: > > > > OK. I diffed it with the > latesthttp://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/and I hope it > works. Thanks for the review! > > Regards, > > Yunda > > *??????:*Staffan Larsen [mailto:staffan.larsen at oracle.com > ] > *????????:*2013??1??18??17:07 > *??????:*???? > *????:*daniel.daugherty at oracle.com ; > serviceability-dev at openjdk.java.net > > *????:*Re: Errors when use "universe" command in CLHSDB > > Yunda, > > I think this fixes http://bugs.sun.com/view_bug.do?bug_id=8005278 > > The changes look good to me. I couldn't apply the patch to the code > cleanly, however (see below). Perhaps the patch was broken in email? > Can you regenerate the patch and include it as a zipped attachment? > > Thanks, > > /Staffan > > file > agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary > .java > already exists > 1 out of 1 hunks FAILED -- saving rejects to file > agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary > .java.rej > patching file > agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac > e.java > Hunk #1 FAILED at 116 > Hunk #2 FAILED at 40 > 2 out of 2 hunks FAILED -- saving rejects to file > agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac > e.java.rej > patching file > src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Hunk #1 succeeded at 45 with fuzz 2 (offset 0 lines). > patch failed, unable to continue (try -v) patch failed, rejects left > in working dir > > On 18 jan 2013, at 04:54,???? > wrote: > > > > > Thanks Dan! > > Regards, > > Yunda > > *??????:*Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com > ] > *????????:*2013??1??18??10:46 > *??????:*????;serviceability-dev at openjdk.java.net > > *????:*Re: Errors when use "universe" command in CLHSDB > > Yunda, > > The Serviceability Agent is maintained by the Serviceability team. > I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime > alias. > > Dan > > On 1/17/13 7:42 PM,????wrote: > > Hi all, > > This is Yunda > from Alibaba Group(with OCA). > > When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar > sun.jvm.hotspot.CLHSDB) I found two errors below(the second error > occurred after I made some fix). It seemed that some code about CMS > in SA didn??t change accordingly. > > hsdb> universe > > Heap Parameters: > > Gen 0: eden > [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space > capacity = 140640256, 2.000007736049627 used > > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) > space capacity = 17563648, 0.0 used > > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space > capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > > Exception in thread "main" java.lang.ExceptionInInitializerError > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > > at > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructo > rAccessorImpl.java:57) > > at > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo > nstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:395) > > at > > sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java > :58) > > at > > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(Concurre > ntMarkSweepGeneration.java:55) > > at > > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(Concurren > tMarkSweepGeneration.java:79) > > at > > sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java: > 139) > > at > sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > > at > > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: > 1897) > > at > > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: > 1867) > > at > sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > > Caused by: java.lang.RuntimeException: field "_dictionary" not found > in type CompactibleFreeListSpace > > at > sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) > > at > sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) > > at > sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) > > at > > sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:2 > 82) > > at > > sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(Compactible > FreeListSpace.java:69) > > at > > sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(Compactible > FreeListSpace.java:35) > > at > > sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFr > eeListSpace.java:55) > > at > sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > > at > > sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFr > eeListSpace.java:53) > > ... 14 more > > hsdb> universe > > Heap Parameters: > > Gen 0: eden > [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space > capacity = 140640256, 2.000007736049627 used > > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) > space capacity = 17563648, 0.0 used > > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space > capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > > free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception > in thread "main" java.lang.ExceptionInInitializerError > > at > > sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeLi > stSpace.java:112) > > at > > sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeLi > stSpace.java:95) > > at > > sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFre > eListSpace.java:137) > > at > > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(Concurren > tMarkSweepGeneration.java:79) > > at > > sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java: > 139) > > at > sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > > at > > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: > 1897) > > at > > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: > 1867) > > at > sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > > Caused by: java.lang.RuntimeException: No type named "FreeList" in > database > > at > > sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeData > Base.java:80) > > at > > sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.jav > a:134) > > at > > sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeData > Base.java:74) > > at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) > > at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) > > at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) > > at > sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > > at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) > > ... 11 more > > So I made a patch to fix them and now ??universe?? command works well. > Could someone help to review the patch below? > > diff -r b14da2e6f2dc -r 8652e04889a4 > > agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary > .java > > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > > +++ > b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -0,0 +1,59 @@ > > +/* > > + * @(#)AFLBinaryTreeDictionary.java > > + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All > rights reserved. > > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > + * > > + * This code is free software; you can redistribute it and/or > modify it > > + * under the terms of the GNU General Public License version 2 > only, as > > + * published by the Free Software Foundation. > > + * > > + * This code is distributed in the hope that it will be useful, but > WITHOUT > > + * ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or > > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public > License > > + * version 2 for more details (a copy is included in the LICENSE > file that > > + * accompanied this code). > > + * > > + * You should have received a copy of the GNU General Public > License version > > + * 2 along with this work; if not, write to the Free Software > Foundation, > > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > + * > > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > > + * or visitwww.oracle.com if you need > additional information or have any > > + * questions. > > + * > > + */ > > + > > +package sun.jvm.hotspot.memory; > > + > > +import java.util.*; > > +import sun.jvm.hotspot.debugger.*; > > +import sun.jvm.hotspot.types.*; > > +import sun.jvm.hotspot.runtime.*; > > + > > +public class AFLBinaryTreeDictionary extends VMObject { > > + static { > > + VM.registerVMInitializedObserver(new Observer() { > > + public void update(Observable o, Object data) { > > + initialize(VM.getVM().getTypeDataBase()); > > + } > > + }); > > + } > > + > > + private static synchronized void initialize(TypeDataBase db) { > > + Type type = db.lookupType("AFLBinaryTreeDictionary"); > > + totalSizeField = type.getCIntegerField("_total_size"); > > + } > > + > > + // Fields > > + private static CIntegerField totalSizeField; > > + > > + // Accessors > > + public long size() { > > + return totalSizeField.getValue(addr); > > + } > > + > > + // Constructor > > + public AFLBinaryTreeDictionary(Address addr) { > > + super(addr); > > + } > > +} > > diff -r b14da2e6f2dc -r 8652e04889a4 > > agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.ja > va > > --- > a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 > > @@ -1,59 +0,0 @@ > > -/* > > - * @(#)BinaryTreeDictionary.java > > - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All > rights reserved. > > - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > - * > > - * This code is free software; you can redistribute it and/or > modify it > > - * under the terms of the GNU General Public License version 2 > only, as > > - * published by the Free Software Foundation. > > - * > > - * This code is distributed in the hope that it will be useful, but > WITHOUT > > - * ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or > > - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public > License > > - * version 2 for more details (a copy is included in the LICENSE > file that > > - * accompanied this code). > > - * > > - * You should have received a copy of the GNU General Public > License version > > - * 2 along with this work; if not, write to the Free Software > Foundation, > > - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > - * > > - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > > - * or visitwww.oracle.com if you need > additional information or have any > > - * questions. > > - * > > - */ > > - > > -package sun.jvm.hotspot.memory; > > - > > -import java.util.*; > > -import sun.jvm.hotspot.debugger.*; > > -import sun.jvm.hotspot.types.*; > > -import sun.jvm.hotspot.runtime.*; > > - > > -public class BinaryTreeDictionary extends VMObject { > > - static { > > - VM.registerVMInitializedObserver(new Observer() { > > - public void update(Observable o, Object data) { > > - initialize(VM.getVM().getTypeDataBase()); > > - } > > - }); > > - } > > - > > - private static synchronized void initialize(TypeDataBase db) { > > - Type type = db.lookupType("BinaryTreeDictionary"); > > - totalSizeField = type.getCIntegerField("_totalSize"); > > - } > > - > > - // Fields > > - private static CIntegerField totalSizeField; > > - > > - // Accessors > > - public long size() { > > - return totalSizeField.getValue(addr); > > - } > > - > > - // Constructor > > - public BinaryTreeDictionary(Address addr) { > > - super(addr); > > - } > > -} > > diff -r b14da2e6f2dc -r 8652e04889a4 > > agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac > e.java > > --- > a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ > b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -117,7 +117,7 @@ > > } > > // large block > > - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) > VMObjectFactory.newObject(BinaryTreeDictionary.class, > > + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) > VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, > > dictionaryField.getValue(addr)); > > size += bfbd.size(); > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > > --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -41,7 +41,7 @@ > > } > > private static synchronized void initialize(TypeDataBase db) { > > - Type type = db.lookupType("FreeList"); > > + Type type = db.lookupType("FreeList"); > > sizeField = type.getCIntegerField("_size"); > > countField = type.getCIntegerField("_count"); > > headerSize = type.getSize(); > > diff -r b14da2e6f2dc -r 8652e04889a4 > > src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > > --- > a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Thu Jan 17 13:40:31 2013 -0500 > > +++ > b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Fri Jan 18 09:56:06 2013 +0800 > > @@ -43,7 +43,8 @@ > > nonstatic_field(LinearAllocBlock, _word_size, size_t) \ > > nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ > > nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], > FreeList) \ > > - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, > LinearAllocBlock) > > + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, > LinearAllocBlock) \ > > + nonstatic_field(CompactibleFreeListSpace, _dictionary, > FreeBlockDictionary*) > > #define VM_TYPES_CMS(declare_type, \ > > Regards, > > Yunda > > > ---------------------------------------------------------------------- > -- > > > This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please > delete it immediately and do not copy it or use it for any purpose > or disclose its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????????? > ???????????????????????? > > ---------------------------------------------------------------------- > -- > > > This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please delete > it immediately and do not copy it or use it for any purpose or > disclose its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????????????? > ???????????????? > > > ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? From david.holmes at oracle.com Sun Jan 20 20:00:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2013 14:00:14 +1000 Subject: =?GB2312?B?tPC4tDogtPC4tDogRXJyb3JzIHdoZW4gdXNlICJ1bml2ZXJzZQ==?= =?GB2312?B?IiBjb21tYW5kIGluIENMSFNEQg==?= In-Reply-To: References: <50F8B771.3080505@oracle.com> <50FCAB9B.3080107@oracle.com> Message-ID: <50FCBD4E.1050200@oracle.com> On 21/01/2013 1:06 PM, ???? wrote: > Actually I just changed "BinaryTreeDictionary" to "AFLBinaryTreeDictionary", since there is no definition of BinaryTreeDictionary in the latest hotspot: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/file/b5f6465019f6/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp , which has been changed to AFLBinaryTreeDictionary. So the code in SA has to change too. The bug is already found here: http://bugs.sun.com/view_bug.do?bug_id=8005278 I'm still missing some pieces here. We have: typedef BinaryTreeDictionary AFLBinaryTreeDictionary; in vmStructs and we have: ./share/vm/memory/binaryTreeDictionary.hpp/cpp and we have: src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java So I'm unclear what is causing the problem here. Staffan: can you generate a webrev from this patch to make the context clearer please? Thanks, David > Regards, > Yunda > -----????????----- > ??????: David Holmes [mailto:david.holmes at oracle.com] > ????????: 2013??1??21?? 10:45 > ??????: ???? > ????: Staffan Larsen; serviceability-dev at openjdk.java.net > ????: Re: ????: Errors when use "universe" command in CLHSDB > > I couldn't quite understand the problem and fix from the patch. Why do we need to add AFLBinaryTreeDictionary ?? > > Thanks, > David > > On 21/01/2013 12:03 PM, ???? wrote: >> Thanks for your review again. Could someone with Reviewer status help >> me with this? Thanks in advance! >> >> Regards, >> >> Yunda >> >> *??????:*Staffan Larsen [mailto:staffan.larsen at oracle.com] >> *????????:*2013??1??18??20:14 >> *??????:*???? >> *????:*daniel.daugherty at oracle.com; serviceability-dev at openjdk.java.net >> *????:*Re: Errors when use "universe" command in CLHSDB >> >> This patch applied cleanly. >> >> I can sponsor this fix, but we still need a review from someone with >> Reviewer status. Once we have that, I can push the change. >> >> Thanks, >> >> /Staffan >> >> On 18 jan 2013, at 11:22, ????> > wrote: >> >> >> >> OK. I diffed it with the >> latesthttp://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/and I hope it >> works. Thanks for the review! >> >> Regards, >> >> Yunda >> >> *??????:*Staffan Larsen [mailto:staffan.larsen at oracle.com >> ] >> *????????:*2013??1??18??17:07 >> *??????:*???? >> *????:*daniel.daugherty at oracle.com; >> serviceability-dev at openjdk.java.net >> >> *????:*Re: Errors when use "universe" command in CLHSDB >> >> Yunda, >> >> I think this fixes http://bugs.sun.com/view_bug.do?bug_id=8005278 >> >> The changes look good to me. I couldn't apply the patch to the code >> cleanly, however (see below). Perhaps the patch was broken in email? >> Can you regenerate the patch and include it as a zipped attachment? >> >> Thanks, >> >> /Staffan >> >> file >> agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary >> .java >> already exists >> 1 out of 1 hunks FAILED -- saving rejects to file >> agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary >> .java.rej >> patching file >> agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac >> e.java >> Hunk #1 FAILED at 116 >> Hunk #2 FAILED at 40 >> 2 out of 2 hunks FAILED -- saving rejects to file >> agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac >> e.java.rej >> patching file >> src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >> Hunk #1 succeeded at 45 with fuzz 2 (offset 0 lines). >> patch failed, unable to continue (try -v) patch failed, rejects left >> in working dir >> >> On 18 jan 2013, at 04:54,????> > wrote: >> >> >> >> >> Thanks Dan! >> >> Regards, >> >> Yunda >> >> *??????:*Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com >> ] >> *????????:*2013??1??18??10:46 >> *??????:*????;serviceability-dev at openjdk.java.net >> >> *????:*Re: Errors when use "universe" command in CLHSDB >> >> Yunda, >> >> The Serviceability Agent is maintained by the Serviceability team. >> I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime >> alias. >> >> Dan >> >> On 1/17/13 7:42 PM,????wrote: >> >> Hi all, >> >> This is Yunda >> from Alibaba Group(with OCA). >> >> When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar >> sun.jvm.hotspot.CLHSDB) I found two errors below(the second error >> occurred after I made some fix). It seemed that some code about CMS >> in SA didn??t change accordingly. >> >> hsdb> universe >> >> Heap Parameters: >> >> Gen 0: eden >> [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space >> capacity = 140640256, 2.000007736049627 used >> >> from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) >> space capacity = 17563648, 0.0 used >> >> to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space >> capacity = 17563648, 0.0 usedInvocations: 0 >> >> Gen 1: concurrent mark-sweep generation >> >> Exception in thread "main" java.lang.ExceptionInInitializerError >> >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >> Method) >> >> at >> >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructo >> rAccessorImpl.java:57) >> >> at >> >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo >> nstructorAccessorImpl.java:45) >> >> at java.lang.reflect.Constructor.newInstance(Constructor.java:395) >> >> at >> >> sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java >> :58) >> >> at >> >> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(Concurre >> ntMarkSweepGeneration.java:55) >> >> at >> >> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(Concurren >> tMarkSweepGeneration.java:79) >> >> at >> >> sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java: >> 139) >> >> at >> sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) >> >> at >> >> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >> 1897) >> >> at >> >> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >> 1867) >> >> at >> sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) >> >> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) >> >> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) >> >> Caused by: java.lang.RuntimeException: field "_dictionary" not found >> in type CompactibleFreeListSpace >> >> at >> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) >> >> at >> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) >> >> at >> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) >> >> at >> >> sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:2 >> 82) >> >> at >> >> sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(Compactible >> FreeListSpace.java:69) >> >> at >> >> sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(Compactible >> FreeListSpace.java:35) >> >> at >> >> sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFr >> eeListSpace.java:55) >> >> at >> sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) >> >> at >> >> sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFr >> eeListSpace.java:53) >> >> ... 14 more >> >> hsdb> universe >> >> Heap Parameters: >> >> Gen 0: eden >> [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space >> capacity = 140640256, 2.000007736049627 used >> >> from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) >> space capacity = 17563648, 0.0 used >> >> to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space >> capacity = 17563648, 0.0 usedInvocations: 0 >> >> Gen 1: concurrent mark-sweep generation >> >> free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception >> in thread "main" java.lang.ExceptionInInitializerError >> >> at >> >> sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeLi >> stSpace.java:112) >> >> at >> >> sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeLi >> stSpace.java:95) >> >> at >> >> sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFre >> eListSpace.java:137) >> >> at >> >> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(Concurren >> tMarkSweepGeneration.java:79) >> >> at >> >> sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java: >> 139) >> >> at >> sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) >> >> at >> >> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >> 1897) >> >> at >> >> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >> 1867) >> >> at >> sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) >> >> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) >> >> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) >> >> Caused by: java.lang.RuntimeException: No type named "FreeList" in >> database >> >> at >> >> sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeData >> Base.java:80) >> >> at >> >> sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.jav >> a:134) >> >> at >> >> sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeData >> Base.java:74) >> >> at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) >> >> at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) >> >> at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) >> >> at >> sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) >> >> at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) >> >> ... 11 more >> >> So I made a patch to fix them and now ??universe?? command works well. >> Could someone help to review the patch below? >> >> diff -r b14da2e6f2dc -r 8652e04889a4 >> >> agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary >> .java >> >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> >> +++ >> b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java >> Fri Jan 18 09:56:06 2013 +0800 >> >> @@ -0,0 +1,59 @@ >> >> +/* >> >> + * @(#)AFLBinaryTreeDictionary.java >> >> + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All >> rights reserved. >> >> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> >> + * >> >> + * This code is free software; you can redistribute it and/or >> modify it >> >> + * under the terms of the GNU General Public License version 2 >> only, as >> >> + * published by the Free Software Foundation. >> >> + * >> >> + * This code is distributed in the hope that it will be useful, but >> WITHOUT >> >> + * ANY WARRANTY; without even the implied warranty of >> MERCHANTABILITY or >> >> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >> License >> >> + * version 2 for more details (a copy is included in the LICENSE >> file that >> >> + * accompanied this code). >> >> + * >> >> + * You should have received a copy of the GNU General Public >> License version >> >> + * 2 along with this work; if not, write to the Free Software >> Foundation, >> >> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> >> + * >> >> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >> 94065 USA >> >> + * or visitwww.oracle.comif you need >> additional information or have any >> >> + * questions. >> >> + * >> >> + */ >> >> + >> >> +package sun.jvm.hotspot.memory; >> >> + >> >> +import java.util.*; >> >> +import sun.jvm.hotspot.debugger.*; >> >> +import sun.jvm.hotspot.types.*; >> >> +import sun.jvm.hotspot.runtime.*; >> >> + >> >> +public class AFLBinaryTreeDictionary extends VMObject { >> >> + static { >> >> + VM.registerVMInitializedObserver(new Observer() { >> >> + public void update(Observable o, Object data) { >> >> + initialize(VM.getVM().getTypeDataBase()); >> >> + } >> >> + }); >> >> + } >> >> + >> >> + private static synchronized void initialize(TypeDataBase db) { >> >> + Type type = db.lookupType("AFLBinaryTreeDictionary"); >> >> + totalSizeField = type.getCIntegerField("_total_size"); >> >> + } >> >> + >> >> + // Fields >> >> + private static CIntegerField totalSizeField; >> >> + >> >> + // Accessors >> >> + public long size() { >> >> + return totalSizeField.getValue(addr); >> >> + } >> >> + >> >> + // Constructor >> >> + public AFLBinaryTreeDictionary(Address addr) { >> >> + super(addr); >> >> + } >> >> +} >> >> diff -r b14da2e6f2dc -r 8652e04889a4 >> >> agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.ja >> va >> >> --- >> a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java >> Thu Jan 17 13:40:31 2013 -0500 >> >> +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 >> >> @@ -1,59 +0,0 @@ >> >> -/* >> >> - * @(#)BinaryTreeDictionary.java >> >> - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All >> rights reserved. >> >> - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> >> - * >> >> - * This code is free software; you can redistribute it and/or >> modify it >> >> - * under the terms of the GNU General Public License version 2 >> only, as >> >> - * published by the Free Software Foundation. >> >> - * >> >> - * This code is distributed in the hope that it will be useful, but >> WITHOUT >> >> - * ANY WARRANTY; without even the implied warranty of >> MERCHANTABILITY or >> >> - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >> License >> >> - * version 2 for more details (a copy is included in the LICENSE >> file that >> >> - * accompanied this code). >> >> - * >> >> - * You should have received a copy of the GNU General Public >> License version >> >> - * 2 along with this work; if not, write to the Free Software >> Foundation, >> >> - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> >> - * >> >> - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >> 94065 USA >> >> - * or visitwww.oracle.comif you need >> additional information or have any >> >> - * questions. >> >> - * >> >> - */ >> >> - >> >> -package sun.jvm.hotspot.memory; >> >> - >> >> -import java.util.*; >> >> -import sun.jvm.hotspot.debugger.*; >> >> -import sun.jvm.hotspot.types.*; >> >> -import sun.jvm.hotspot.runtime.*; >> >> - >> >> -public class BinaryTreeDictionary extends VMObject { >> >> - static { >> >> - VM.registerVMInitializedObserver(new Observer() { >> >> - public void update(Observable o, Object data) { >> >> - initialize(VM.getVM().getTypeDataBase()); >> >> - } >> >> - }); >> >> - } >> >> - >> >> - private static synchronized void initialize(TypeDataBase db) { >> >> - Type type = db.lookupType("BinaryTreeDictionary"); >> >> - totalSizeField = type.getCIntegerField("_totalSize"); >> >> - } >> >> - >> >> - // Fields >> >> - private static CIntegerField totalSizeField; >> >> - >> >> - // Accessors >> >> - public long size() { >> >> - return totalSizeField.getValue(addr); >> >> - } >> >> - >> >> - // Constructor >> >> - public BinaryTreeDictionary(Address addr) { >> >> - super(addr); >> >> - } >> >> -} >> >> diff -r b14da2e6f2dc -r 8652e04889a4 >> >> agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac >> e.java >> >> --- >> a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java >> Thu Jan 17 13:40:31 2013 -0500 >> >> +++ >> b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java >> Fri Jan 18 09:56:06 2013 +0800 >> >> @@ -117,7 +117,7 @@ >> >> } >> >> // large block >> >> - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) >> VMObjectFactory.newObject(BinaryTreeDictionary.class, >> >> + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) >> VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, >> >> dictionaryField.getValue(addr)); >> >> size += bfbd.size(); >> >> diff -r b14da2e6f2dc -r 8652e04889a4 >> agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >> >> --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >> Thu Jan 17 13:40:31 2013 -0500 >> >> +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >> Fri Jan 18 09:56:06 2013 +0800 >> >> @@ -41,7 +41,7 @@ >> >> } >> >> private static synchronized void initialize(TypeDataBase db) { >> >> - Type type = db.lookupType("FreeList"); >> >> + Type type = db.lookupType("FreeList"); >> >> sizeField = type.getCIntegerField("_size"); >> >> countField = type.getCIntegerField("_count"); >> >> headerSize = type.getSize(); >> >> diff -r b14da2e6f2dc -r 8652e04889a4 >> >> src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >> >> --- >> a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >> Thu Jan 17 13:40:31 2013 -0500 >> >> +++ >> b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >> Fri Jan 18 09:56:06 2013 +0800 >> >> @@ -43,7 +43,8 @@ >> >> nonstatic_field(LinearAllocBlock, _word_size, size_t) \ >> >> nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ >> >> nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >> FreeList) \ >> >> - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >> LinearAllocBlock) >> >> + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >> LinearAllocBlock) \ >> >> + nonstatic_field(CompactibleFreeListSpace, _dictionary, >> FreeBlockDictionary*) >> >> #define VM_TYPES_CMS(declare_type, \ >> >> Regards, >> >> Yunda >> >> >> ---------------------------------------------------------------------- >> -- >> >> >> This email (including any attachments) is confidential and may be >> legally privileged. If you received this email in error, please >> delete it immediately and do not copy it or use it for any purpose >> or disclose its contents to any other person. Thank you. >> >> ??????(????????????)???????????????????????????????????????????????? >> ???????????????????????????????????????????????????????????????????? >> ???????????????????????? >> >> ---------------------------------------------------------------------- >> -- >> >> >> This email (including any attachments) is confidential and may be >> legally privileged. If you received this email in error, please delete >> it immediately and do not copy it or use it for any purpose or >> disclose its contents to any other person. Thank you. >> >> ??????(????????????)???????????????????????????????????????????????????? >> ???????????????????????????????????????????????????????????????????????? >> ???????????????? >> >> >> > > ________________________________ > > This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? From masayoshi.okutsu at oracle.com Sun Jan 20 22:44:38 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Mon, 21 Jan 2013 06:44:38 +0000 Subject: hg: jdk8/tl/jdk: 8004489: Add support for Minguo and Hijrah calendars to CalendarNameProvider SPI; ... Message-ID: <20130121064458.EBD9847413@hg.openjdk.java.net> Changeset: 3c1a440a1e12 Author: okutsu Date: 2013-01-21 15:41 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c1a440a1e12 8004489: Add support for Minguo and Hijrah calendars to CalendarNameProvider SPI 8006509: Add more calendar symbol names from CLDR Reviewed-by: peytoia ! make/tools/src/build/tools/cldrconverter/Bundle.java ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/CalendarType.java ! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java ! src/share/classes/java/util/spi/CalendarNameProvider.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! src/share/classes/sun/text/resources/be/FormatData_be.java ! src/share/classes/sun/text/resources/bg/FormatData_bg.java ! src/share/classes/sun/text/resources/ca/FormatData_ca.java ! src/share/classes/sun/text/resources/cs/FormatData_cs.java ! src/share/classes/sun/text/resources/da/FormatData_da.java ! src/share/classes/sun/text/resources/de/FormatData_de.java ! src/share/classes/sun/text/resources/el/FormatData_el.java ! src/share/classes/sun/text/resources/es/FormatData_es.java ! src/share/classes/sun/text/resources/et/FormatData_et.java ! src/share/classes/sun/text/resources/fi/FormatData_fi.java ! src/share/classes/sun/text/resources/fr/FormatData_fr.java ! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java ! src/share/classes/sun/text/resources/hr/FormatData_hr.java ! src/share/classes/sun/text/resources/hu/FormatData_hu.java ! src/share/classes/sun/text/resources/is/FormatData_is.java ! src/share/classes/sun/text/resources/it/FormatData_it.java ! src/share/classes/sun/text/resources/iw/FormatData_iw.java ! src/share/classes/sun/text/resources/ja/FormatData_ja.java ! src/share/classes/sun/text/resources/ko/FormatData_ko.java ! src/share/classes/sun/text/resources/lt/FormatData_lt.java ! src/share/classes/sun/text/resources/lv/FormatData_lv.java ! src/share/classes/sun/text/resources/mk/FormatData_mk.java ! src/share/classes/sun/text/resources/ms/FormatData_ms.java ! src/share/classes/sun/text/resources/mt/FormatData_mt.java ! src/share/classes/sun/text/resources/nl/FormatData_nl.java ! src/share/classes/sun/text/resources/pl/FormatData_pl.java ! src/share/classes/sun/text/resources/pt/FormatData_pt.java ! src/share/classes/sun/text/resources/ro/FormatData_ro.java ! src/share/classes/sun/text/resources/ru/FormatData_ru.java ! src/share/classes/sun/text/resources/sk/FormatData_sk.java ! src/share/classes/sun/text/resources/sl/FormatData_sl.java ! src/share/classes/sun/text/resources/sr/FormatData_sr.java ! src/share/classes/sun/text/resources/sv/FormatData_sv.java ! src/share/classes/sun/text/resources/th/FormatData_th.java ! src/share/classes/sun/text/resources/tr/FormatData_tr.java ! src/share/classes/sun/text/resources/uk/FormatData_uk.java ! src/share/classes/sun/text/resources/vi/FormatData_vi.java ! src/share/classes/sun/text/resources/zh/FormatData_zh.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java + test/java/util/Calendar/CldrFormatNamesTest.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java From weijun.wang at oracle.com Sun Jan 20 23:06:19 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 21 Jan 2013 07:06:19 +0000 Subject: hg: jdk8/tl/jdk: 8006092: SecurityPermission: printIdentity doesn't exist Message-ID: <20130121070641.C5D8A47414@hg.openjdk.java.net> Changeset: bb940b2107bd Author: juh Date: 2013-01-21 15:05 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb940b2107bd 8006092: SecurityPermission: printIdentity doesn't exist Reviewed-by: weijun ! test/sun/security/tools/policytool/UpdatePermissions.html From staffan.larsen at oracle.com Sun Jan 20 23:11:09 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 21 Jan 2013 08:11:09 +0100 Subject: Errors when use "universe" command in CLHSDB In-Reply-To: <50FCBD4E.1050200@oracle.com> References: <50F8B771.3080505@oracle.com> <50FCAB9B.3080107@oracle.com> <50FCBD4E.1050200@oracle.com> Message-ID: A webrev is here: http://cr.openjdk.java.net/~sla/8005278/webrev.00/ /Staffan On 21 jan 2013, at 05:00, David Holmes wrote: > On 21/01/2013 1:06 PM, ???? wrote: >> Actually I just changed "BinaryTreeDictionary" to "AFLBinaryTreeDictionary", since there is no definition of BinaryTreeDictionary in the latest hotspot: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/file/b5f6465019f6/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp , which has been changed to AFLBinaryTreeDictionary. So the code in SA has to change too. The bug is already found here: http://bugs.sun.com/view_bug.do?bug_id=8005278 > > I'm still missing some pieces here. We have: > > typedef BinaryTreeDictionary > AFLBinaryTreeDictionary; > > in vmStructs and we have: > > ./share/vm/memory/binaryTreeDictionary.hpp/cpp > > and we have: > > src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > > So I'm unclear what is causing the problem here. > > Staffan: can you generate a webrev from this patch to make the context > clearer please? > > Thanks, > David > >> Regards, >> Yunda >> -----????????----- >> ??????: David Holmes [mailto:david.holmes at oracle.com] >> ????????: 2013??1??21?? 10:45 >> ??????: ???? >> ????: Staffan Larsen; serviceability-dev at openjdk.java.net >> ????: Re: ????: Errors when use "universe" command in CLHSDB >> >> I couldn't quite understand the problem and fix from the patch. Why do we need to add AFLBinaryTreeDictionary ?? >> >> Thanks, >> David >> >> On 21/01/2013 12:03 PM, ???? wrote: >>> Thanks for your review again. Could someone with Reviewer status help >>> me with this? Thanks in advance! >>> >>> Regards, >>> >>> Yunda >>> >>> *??????:*Staffan Larsen [mailto:staffan.larsen at oracle.com] >>> *????????:*2013??1??18??20:14 >>> *??????:*???? >>> *????:*daniel.daugherty at oracle.com; serviceability-dev at openjdk.java.net >>> *????:*Re: Errors when use "universe" command in CLHSDB >>> >>> This patch applied cleanly. >>> >>> I can sponsor this fix, but we still need a review from someone with >>> Reviewer status. Once we have that, I can push the change. >>> >>> Thanks, >>> >>> /Staffan >>> >>> On 18 jan 2013, at 11:22, ????>> > wrote: >>> >>> >>> >>> OK. I diffed it with the >>> latesthttp://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/and I hope it >>> works. Thanks for the review! >>> >>> Regards, >>> >>> Yunda >>> >>> *??????:*Staffan Larsen [mailto:staffan.larsen at oracle.com >>> ] >>> *????????:*2013??1??18??17:07 >>> *??????:*???? >>> *????:*daniel.daugherty at oracle.com; >>> serviceability-dev at openjdk.java.net >>> >>> *????:*Re: Errors when use "universe" command in CLHSDB >>> >>> Yunda, >>> >>> I think this fixes http://bugs.sun.com/view_bug.do?bug_id=8005278 >>> >>> The changes look good to me. I couldn't apply the patch to the code >>> cleanly, however (see below). Perhaps the patch was broken in email? >>> Can you regenerate the patch and include it as a zipped attachment? >>> >>> Thanks, >>> >>> /Staffan >>> >>> file >>> agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary >>> .java >>> already exists >>> 1 out of 1 hunks FAILED -- saving rejects to file >>> agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary >>> .java.rej >>> patching file >>> agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac >>> e.java >>> Hunk #1 FAILED at 116 >>> Hunk #2 FAILED at 40 >>> 2 out of 2 hunks FAILED -- saving rejects to file >>> agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac >>> e.java.rej >>> patching file >>> src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>> Hunk #1 succeeded at 45 with fuzz 2 (offset 0 lines). >>> patch failed, unable to continue (try -v) patch failed, rejects left >>> in working dir >>> >>> On 18 jan 2013, at 04:54,????>> > wrote: >>> >>> >>> >>> >>> Thanks Dan! >>> >>> Regards, >>> >>> Yunda >>> >>> *??????:*Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com >>> ] >>> *????????:*2013??1??18??10:46 >>> *??????:*????;serviceability-dev at openjdk.java.net >>> >>> *????:*Re: Errors when use "universe" command in CLHSDB >>> >>> Yunda, >>> >>> The Serviceability Agent is maintained by the Serviceability team. >>> I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime >>> alias. >>> >>> Dan >>> >>> On 1/17/13 7:42 PM,????wrote: >>> >>> Hi all, >>> >>> This is Yunda >>> from Alibaba Group(with OCA). >>> >>> When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar >>> sun.jvm.hotspot.CLHSDB) I found two errors below(the second error >>> occurred after I made some fix). It seemed that some code about CMS >>> in SA didn??t change accordingly. >>> >>> hsdb> universe >>> >>> Heap Parameters: >>> >>> Gen 0: eden >>> [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space >>> capacity = 140640256, 2.000007736049627 used >>> >>> from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) >>> space capacity = 17563648, 0.0 used >>> >>> to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space >>> capacity = 17563648, 0.0 usedInvocations: 0 >>> >>> Gen 1: concurrent mark-sweep generation >>> >>> Exception in thread "main" java.lang.ExceptionInInitializerError >>> >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>> Method) >>> >>> at >>> >>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructo >>> rAccessorImpl.java:57) >>> >>> at >>> >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo >>> nstructorAccessorImpl.java:45) >>> >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:395) >>> >>> at >>> >>> sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java >>> :58) >>> >>> at >>> >>> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(Concurre >>> ntMarkSweepGeneration.java:55) >>> >>> at >>> >>> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(Concurren >>> tMarkSweepGeneration.java:79) >>> >>> at >>> >>> sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java: >>> 139) >>> >>> at >>> sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) >>> >>> at >>> >>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >>> 1897) >>> >>> at >>> >>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >>> 1867) >>> >>> at >>> sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) >>> >>> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) >>> >>> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) >>> >>> Caused by: java.lang.RuntimeException: field "_dictionary" not found >>> in type CompactibleFreeListSpace >>> >>> at >>> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) >>> >>> at >>> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) >>> >>> at >>> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) >>> >>> at >>> >>> sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:2 >>> 82) >>> >>> at >>> >>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(Compactible >>> FreeListSpace.java:69) >>> >>> at >>> >>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(Compactible >>> FreeListSpace.java:35) >>> >>> at >>> >>> sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFr >>> eeListSpace.java:55) >>> >>> at >>> sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) >>> >>> at >>> >>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFr >>> eeListSpace.java:53) >>> >>> ... 14 more >>> >>> hsdb> universe >>> >>> Heap Parameters: >>> >>> Gen 0: eden >>> [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space >>> capacity = 140640256, 2.000007736049627 used >>> >>> from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) >>> space capacity = 17563648, 0.0 used >>> >>> to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space >>> capacity = 17563648, 0.0 usedInvocations: 0 >>> >>> Gen 1: concurrent mark-sweep generation >>> >>> free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception >>> in thread "main" java.lang.ExceptionInInitializerError >>> >>> at >>> >>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeLi >>> stSpace.java:112) >>> >>> at >>> >>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeLi >>> stSpace.java:95) >>> >>> at >>> >>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFre >>> eListSpace.java:137) >>> >>> at >>> >>> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(Concurren >>> tMarkSweepGeneration.java:79) >>> >>> at >>> >>> sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java: >>> 139) >>> >>> at >>> sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) >>> >>> at >>> >>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >>> 1897) >>> >>> at >>> >>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >>> 1867) >>> >>> at >>> sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) >>> >>> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) >>> >>> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) >>> >>> Caused by: java.lang.RuntimeException: No type named "FreeList" in >>> database >>> >>> at >>> >>> sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeData >>> Base.java:80) >>> >>> at >>> >>> sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.jav >>> a:134) >>> >>> at >>> >>> sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeData >>> Base.java:74) >>> >>> at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) >>> >>> at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) >>> >>> at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) >>> >>> at >>> sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) >>> >>> at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) >>> >>> ... 11 more >>> >>> So I made a patch to fix them and now ??universe?? command works well. >>> Could someone help to review the patch below? >>> >>> diff -r b14da2e6f2dc -r 8652e04889a4 >>> >>> agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary >>> .java >>> >>> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >>> >>> +++ >>> b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java >>> Fri Jan 18 09:56:06 2013 +0800 >>> >>> @@ -0,0 +1,59 @@ >>> >>> +/* >>> >>> + * @(#)AFLBinaryTreeDictionary.java >>> >>> + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All >>> rights reserved. >>> >>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> >>> + * >>> >>> + * This code is free software; you can redistribute it and/or >>> modify it >>> >>> + * under the terms of the GNU General Public License version 2 >>> only, as >>> >>> + * published by the Free Software Foundation. >>> >>> + * >>> >>> + * This code is distributed in the hope that it will be useful, but >>> WITHOUT >>> >>> + * ANY WARRANTY; without even the implied warranty of >>> MERCHANTABILITY or >>> >>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>> License >>> >>> + * version 2 for more details (a copy is included in the LICENSE >>> file that >>> >>> + * accompanied this code). >>> >>> + * >>> >>> + * You should have received a copy of the GNU General Public >>> License version >>> >>> + * 2 along with this work; if not, write to the Free Software >>> Foundation, >>> >>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>> >>> + * >>> >>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>> 94065 USA >>> >>> + * or visitwww.oracle.comif you need >>> additional information or have any >>> >>> + * questions. >>> >>> + * >>> >>> + */ >>> >>> + >>> >>> +package sun.jvm.hotspot.memory; >>> >>> + >>> >>> +import java.util.*; >>> >>> +import sun.jvm.hotspot.debugger.*; >>> >>> +import sun.jvm.hotspot.types.*; >>> >>> +import sun.jvm.hotspot.runtime.*; >>> >>> + >>> >>> +public class AFLBinaryTreeDictionary extends VMObject { >>> >>> + static { >>> >>> + VM.registerVMInitializedObserver(new Observer() { >>> >>> + public void update(Observable o, Object data) { >>> >>> + initialize(VM.getVM().getTypeDataBase()); >>> >>> + } >>> >>> + }); >>> >>> + } >>> >>> + >>> >>> + private static synchronized void initialize(TypeDataBase db) { >>> >>> + Type type = db.lookupType("AFLBinaryTreeDictionary"); >>> >>> + totalSizeField = type.getCIntegerField("_total_size"); >>> >>> + } >>> >>> + >>> >>> + // Fields >>> >>> + private static CIntegerField totalSizeField; >>> >>> + >>> >>> + // Accessors >>> >>> + public long size() { >>> >>> + return totalSizeField.getValue(addr); >>> >>> + } >>> >>> + >>> >>> + // Constructor >>> >>> + public AFLBinaryTreeDictionary(Address addr) { >>> >>> + super(addr); >>> >>> + } >>> >>> +} >>> >>> diff -r b14da2e6f2dc -r 8652e04889a4 >>> >>> agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.ja >>> va >>> >>> --- >>> a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java >>> Thu Jan 17 13:40:31 2013 -0500 >>> >>> +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 >>> >>> @@ -1,59 +0,0 @@ >>> >>> -/* >>> >>> - * @(#)BinaryTreeDictionary.java >>> >>> - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All >>> rights reserved. >>> >>> - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> >>> - * >>> >>> - * This code is free software; you can redistribute it and/or >>> modify it >>> >>> - * under the terms of the GNU General Public License version 2 >>> only, as >>> >>> - * published by the Free Software Foundation. >>> >>> - * >>> >>> - * This code is distributed in the hope that it will be useful, but >>> WITHOUT >>> >>> - * ANY WARRANTY; without even the implied warranty of >>> MERCHANTABILITY or >>> >>> - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>> License >>> >>> - * version 2 for more details (a copy is included in the LICENSE >>> file that >>> >>> - * accompanied this code). >>> >>> - * >>> >>> - * You should have received a copy of the GNU General Public >>> License version >>> >>> - * 2 along with this work; if not, write to the Free Software >>> Foundation, >>> >>> - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>> >>> - * >>> >>> - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>> 94065 USA >>> >>> - * or visitwww.oracle.comif you need >>> additional information or have any >>> >>> - * questions. >>> >>> - * >>> >>> - */ >>> >>> - >>> >>> -package sun.jvm.hotspot.memory; >>> >>> - >>> >>> -import java.util.*; >>> >>> -import sun.jvm.hotspot.debugger.*; >>> >>> -import sun.jvm.hotspot.types.*; >>> >>> -import sun.jvm.hotspot.runtime.*; >>> >>> - >>> >>> -public class BinaryTreeDictionary extends VMObject { >>> >>> - static { >>> >>> - VM.registerVMInitializedObserver(new Observer() { >>> >>> - public void update(Observable o, Object data) { >>> >>> - initialize(VM.getVM().getTypeDataBase()); >>> >>> - } >>> >>> - }); >>> >>> - } >>> >>> - >>> >>> - private static synchronized void initialize(TypeDataBase db) { >>> >>> - Type type = db.lookupType("BinaryTreeDictionary"); >>> >>> - totalSizeField = type.getCIntegerField("_totalSize"); >>> >>> - } >>> >>> - >>> >>> - // Fields >>> >>> - private static CIntegerField totalSizeField; >>> >>> - >>> >>> - // Accessors >>> >>> - public long size() { >>> >>> - return totalSizeField.getValue(addr); >>> >>> - } >>> >>> - >>> >>> - // Constructor >>> >>> - public BinaryTreeDictionary(Address addr) { >>> >>> - super(addr); >>> >>> - } >>> >>> -} >>> >>> diff -r b14da2e6f2dc -r 8652e04889a4 >>> >>> agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac >>> e.java >>> >>> --- >>> a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java >>> Thu Jan 17 13:40:31 2013 -0500 >>> >>> +++ >>> b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java >>> Fri Jan 18 09:56:06 2013 +0800 >>> >>> @@ -117,7 +117,7 @@ >>> >>> } >>> >>> // large block >>> >>> - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) >>> VMObjectFactory.newObject(BinaryTreeDictionary.class, >>> >>> + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) >>> VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, >>> >>> dictionaryField.getValue(addr)); >>> >>> size += bfbd.size(); >>> >>> diff -r b14da2e6f2dc -r 8652e04889a4 >>> agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >>> >>> --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >>> Thu Jan 17 13:40:31 2013 -0500 >>> >>> +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >>> Fri Jan 18 09:56:06 2013 +0800 >>> >>> @@ -41,7 +41,7 @@ >>> >>> } >>> >>> private static synchronized void initialize(TypeDataBase db) { >>> >>> - Type type = db.lookupType("FreeList"); >>> >>> + Type type = db.lookupType("FreeList"); >>> >>> sizeField = type.getCIntegerField("_size"); >>> >>> countField = type.getCIntegerField("_count"); >>> >>> headerSize = type.getSize(); >>> >>> diff -r b14da2e6f2dc -r 8652e04889a4 >>> >>> src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>> >>> --- >>> a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>> Thu Jan 17 13:40:31 2013 -0500 >>> >>> +++ >>> b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>> Fri Jan 18 09:56:06 2013 +0800 >>> >>> @@ -43,7 +43,8 @@ >>> >>> nonstatic_field(LinearAllocBlock, _word_size, size_t) \ >>> >>> nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ >>> >>> nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>> FreeList) \ >>> >>> - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >>> LinearAllocBlock) >>> >>> + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >>> LinearAllocBlock) \ >>> >>> + nonstatic_field(CompactibleFreeListSpace, _dictionary, >>> FreeBlockDictionary*) >>> >>> #define VM_TYPES_CMS(declare_type, \ >>> >>> Regards, >>> >>> Yunda >>> >>> >>> ---------------------------------------------------------------------- >>> -- >>> >>> >>> This email (including any attachments) is confidential and may be >>> legally privileged. If you received this email in error, please >>> delete it immediately and do not copy it or use it for any purpose >>> or disclose its contents to any other person. Thank you. >>> >>> ??????(????????????)???????????????????????????????????????????????? >>> ???????????????????????????????????????????????????????????????????? >>> ???????????????????????? >>> >>> ---------------------------------------------------------------------- >>> -- >>> >>> >>> This email (including any attachments) is confidential and may be >>> legally privileged. If you received this email in error, please delete >>> it immediately and do not copy it or use it for any purpose or >>> disclose its contents to any other person. Thank you. >>> >>> ??????(????????????)???????????????????????????????????????????????????? >>> ???????????????????????????????????????????????????????????????????????? >>> ???????????????? >>> >>> >>> >> >> ________________________________ >> >> This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. >> >> ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? From david.holmes at oracle.com Sun Jan 20 23:30:00 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2013 17:30:00 +1000 Subject: Errors when use "universe" command in CLHSDB In-Reply-To: References: <50F8B771.3080505@oracle.com> <50FCAB9B.3080107@oracle.com> <50FCBD4E.1050200@oracle.com> Message-ID: <50FCEE78.1090508@oracle.com> On 21/01/2013 5:11 PM, Staffan Larsen wrote: > A webrev is here: http://cr.openjdk.java.net/~sla/8005278/webrev.00/ Thanks. So based on the error message the actual fix here seems to be in src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp where we add: nonstatic_field(CompactibleFreeListSpace,_dictionary,FreeBlockDictionary*) So I am still missing why we needed to change the BinaryTreeDictionary to AFLBinaryTreeDictionary ? I'm unclear whether the typedef in the vmStructs needs to be used in the SA code or whether the SA should just be referring to the real type ?? Assuming we do need to rename this then hg mv should be used (which seems not to be the case in the webrev) This problem seems to have been introduced with changeset: 3767:685df3c6f84b parent: 3758:d0e7716b179e user: jmasa date: Tue Sep 18 23:35:42 2012 -0700 summary: 7045397: NPG: Add freelists to class loader arenas. So I've added Jon to the cc list. Thanks, David > /Staffan > > On 21 jan 2013, at 05:00, David Holmes wrote: > >> On 21/01/2013 1:06 PM, ???? wrote: >>> Actually I just changed "BinaryTreeDictionary" to "AFLBinaryTreeDictionary", since there is no definition of BinaryTreeDictionary in the latest hotspot: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/file/b5f6465019f6/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp , which has been changed to AFLBinaryTreeDictionary. So the code in SA has to change too. The bug is already found here: http://bugs.sun.com/view_bug.do?bug_id=8005278 >> >> I'm still missing some pieces here. We have: >> >> typedef BinaryTreeDictionary >> AFLBinaryTreeDictionary; >> >> in vmStructs and we have: >> >> ./share/vm/memory/binaryTreeDictionary.hpp/cpp >> >> and we have: >> >> src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java >> >> So I'm unclear what is causing the problem here. >> >> Staffan: can you generate a webrev from this patch to make the context >> clearer please? >> >> Thanks, >> David >> >>> Regards, >>> Yunda >>> -----????????----- >>> ??????: David Holmes [mailto:david.holmes at oracle.com] >>> ????????: 2013??1??21?? 10:45 >>> ??????: ???? >>> ????: Staffan Larsen; serviceability-dev at openjdk.java.net >>> ????: Re: ????: Errors when use "universe" command in CLHSDB >>> >>> I couldn't quite understand the problem and fix from the patch. Why do we need to add AFLBinaryTreeDictionary ?? >>> >>> Thanks, >>> David >>> >>> On 21/01/2013 12:03 PM, ???? wrote: >>>> Thanks for your review again. Could someone with Reviewer status help >>>> me with this? Thanks in advance! >>>> >>>> Regards, >>>> >>>> Yunda >>>> >>>> *??????:*Staffan Larsen [mailto:staffan.larsen at oracle.com] >>>> *????????:*2013??1??18??20:14 >>>> *??????:*???? >>>> *????:*daniel.daugherty at oracle.com; serviceability-dev at openjdk.java.net >>>> *????:*Re: Errors when use "universe" command in CLHSDB >>>> >>>> This patch applied cleanly. >>>> >>>> I can sponsor this fix, but we still need a review from someone with >>>> Reviewer status. Once we have that, I can push the change. >>>> >>>> Thanks, >>>> >>>> /Staffan >>>> >>>> On 18 jan 2013, at 11:22, ????>>> > wrote: >>>> >>>> >>>> >>>> OK. I diffed it with the >>>> latesthttp://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/and I hope it >>>> works. Thanks for the review! >>>> >>>> Regards, >>>> >>>> Yunda >>>> >>>> *??????:*Staffan Larsen [mailto:staffan.larsen at oracle.com >>>> ] >>>> *????????:*2013??1??18??17:07 >>>> *??????:*???? >>>> *????:*daniel.daugherty at oracle.com; >>>> serviceability-dev at openjdk.java.net >>>> >>>> *????:*Re: Errors when use "universe" command in CLHSDB >>>> >>>> Yunda, >>>> >>>> I think this fixes http://bugs.sun.com/view_bug.do?bug_id=8005278 >>>> >>>> The changes look good to me. I couldn't apply the patch to the code >>>> cleanly, however (see below). Perhaps the patch was broken in email? >>>> Can you regenerate the patch and include it as a zipped attachment? >>>> >>>> Thanks, >>>> >>>> /Staffan >>>> >>>> file >>>> agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary >>>> .java >>>> already exists >>>> 1 out of 1 hunks FAILED -- saving rejects to file >>>> agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary >>>> .java.rej >>>> patching file >>>> agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac >>>> e.java >>>> Hunk #1 FAILED at 116 >>>> Hunk #2 FAILED at 40 >>>> 2 out of 2 hunks FAILED -- saving rejects to file >>>> agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac >>>> e.java.rej >>>> patching file >>>> src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>> Hunk #1 succeeded at 45 with fuzz 2 (offset 0 lines). >>>> patch failed, unable to continue (try -v) patch failed, rejects left >>>> in working dir >>>> >>>> On 18 jan 2013, at 04:54,????>>> > wrote: >>>> >>>> >>>> >>>> >>>> Thanks Dan! >>>> >>>> Regards, >>>> >>>> Yunda >>>> >>>> *??????:*Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com >>>> ] >>>> *????????:*2013??1??18??10:46 >>>> *??????:*????;serviceability-dev at openjdk.java.net >>>> >>>> *????:*Re: Errors when use "universe" command in CLHSDB >>>> >>>> Yunda, >>>> >>>> The Serviceability Agent is maintained by the Serviceability team. >>>> I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime >>>> alias. >>>> >>>> Dan >>>> >>>> On 1/17/13 7:42 PM,????wrote: >>>> >>>> Hi all, >>>> >>>> This is Yunda >>>> from Alibaba Group(with OCA). >>>> >>>> When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar >>>> sun.jvm.hotspot.CLHSDB) I found two errors below(the second error >>>> occurred after I made some fix). It seemed that some code about CMS >>>> in SA didn??t change accordingly. >>>> >>>> hsdb> universe >>>> >>>> Heap Parameters: >>>> >>>> Gen 0: eden >>>> [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space >>>> capacity = 140640256, 2.000007736049627 used >>>> >>>> from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) >>>> space capacity = 17563648, 0.0 used >>>> >>>> to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space >>>> capacity = 17563648, 0.0 usedInvocations: 0 >>>> >>>> Gen 1: concurrent mark-sweep generation >>>> >>>> Exception in thread "main" java.lang.ExceptionInInitializerError >>>> >>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>> Method) >>>> >>>> at >>>> >>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructo >>>> rAccessorImpl.java:57) >>>> >>>> at >>>> >>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo >>>> nstructorAccessorImpl.java:45) >>>> >>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:395) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java >>>> :58) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(Concurre >>>> ntMarkSweepGeneration.java:55) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(Concurren >>>> tMarkSweepGeneration.java:79) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java: >>>> 139) >>>> >>>> at >>>> sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >>>> 1897) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >>>> 1867) >>>> >>>> at >>>> sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) >>>> >>>> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) >>>> >>>> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) >>>> >>>> Caused by: java.lang.RuntimeException: field "_dictionary" not found >>>> in type CompactibleFreeListSpace >>>> >>>> at >>>> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) >>>> >>>> at >>>> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) >>>> >>>> at >>>> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:2 >>>> 82) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(Compactible >>>> FreeListSpace.java:69) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(Compactible >>>> FreeListSpace.java:35) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFr >>>> eeListSpace.java:55) >>>> >>>> at >>>> sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFr >>>> eeListSpace.java:53) >>>> >>>> ... 14 more >>>> >>>> hsdb> universe >>>> >>>> Heap Parameters: >>>> >>>> Gen 0: eden >>>> [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space >>>> capacity = 140640256, 2.000007736049627 used >>>> >>>> from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) >>>> space capacity = 17563648, 0.0 used >>>> >>>> to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space >>>> capacity = 17563648, 0.0 usedInvocations: 0 >>>> >>>> Gen 1: concurrent mark-sweep generation >>>> >>>> free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception >>>> in thread "main" java.lang.ExceptionInInitializerError >>>> >>>> at >>>> >>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeLi >>>> stSpace.java:112) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeLi >>>> stSpace.java:95) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFre >>>> eListSpace.java:137) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(Concurren >>>> tMarkSweepGeneration.java:79) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java: >>>> 139) >>>> >>>> at >>>> sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >>>> 1897) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >>>> 1867) >>>> >>>> at >>>> sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) >>>> >>>> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) >>>> >>>> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) >>>> >>>> Caused by: java.lang.RuntimeException: No type named "FreeList" in >>>> database >>>> >>>> at >>>> >>>> sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeData >>>> Base.java:80) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.jav >>>> a:134) >>>> >>>> at >>>> >>>> sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeData >>>> Base.java:74) >>>> >>>> at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) >>>> >>>> at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) >>>> >>>> at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) >>>> >>>> at >>>> sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) >>>> >>>> at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) >>>> >>>> ... 11 more >>>> >>>> So I made a patch to fix them and now ??universe?? command works well. >>>> Could someone help to review the patch below? >>>> >>>> diff -r b14da2e6f2dc -r 8652e04889a4 >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary >>>> .java >>>> >>>> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >>>> >>>> +++ >>>> b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java >>>> Fri Jan 18 09:56:06 2013 +0800 >>>> >>>> @@ -0,0 +1,59 @@ >>>> >>>> +/* >>>> >>>> + * @(#)AFLBinaryTreeDictionary.java >>>> >>>> + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All >>>> rights reserved. >>>> >>>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> >>>> + * >>>> >>>> + * This code is free software; you can redistribute it and/or >>>> modify it >>>> >>>> + * under the terms of the GNU General Public License version 2 >>>> only, as >>>> >>>> + * published by the Free Software Foundation. >>>> >>>> + * >>>> >>>> + * This code is distributed in the hope that it will be useful, but >>>> WITHOUT >>>> >>>> + * ANY WARRANTY; without even the implied warranty of >>>> MERCHANTABILITY or >>>> >>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>> License >>>> >>>> + * version 2 for more details (a copy is included in the LICENSE >>>> file that >>>> >>>> + * accompanied this code). >>>> >>>> + * >>>> >>>> + * You should have received a copy of the GNU General Public >>>> License version >>>> >>>> + * 2 along with this work; if not, write to the Free Software >>>> Foundation, >>>> >>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>> >>>> + * >>>> >>>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>>> 94065 USA >>>> >>>> + * or visitwww.oracle.comif you need >>>> additional information or have any >>>> >>>> + * questions. >>>> >>>> + * >>>> >>>> + */ >>>> >>>> + >>>> >>>> +package sun.jvm.hotspot.memory; >>>> >>>> + >>>> >>>> +import java.util.*; >>>> >>>> +import sun.jvm.hotspot.debugger.*; >>>> >>>> +import sun.jvm.hotspot.types.*; >>>> >>>> +import sun.jvm.hotspot.runtime.*; >>>> >>>> + >>>> >>>> +public class AFLBinaryTreeDictionary extends VMObject { >>>> >>>> + static { >>>> >>>> + VM.registerVMInitializedObserver(new Observer() { >>>> >>>> + public void update(Observable o, Object data) { >>>> >>>> + initialize(VM.getVM().getTypeDataBase()); >>>> >>>> + } >>>> >>>> + }); >>>> >>>> + } >>>> >>>> + >>>> >>>> + private static synchronized void initialize(TypeDataBase db) { >>>> >>>> + Type type = db.lookupType("AFLBinaryTreeDictionary"); >>>> >>>> + totalSizeField = type.getCIntegerField("_total_size"); >>>> >>>> + } >>>> >>>> + >>>> >>>> + // Fields >>>> >>>> + private static CIntegerField totalSizeField; >>>> >>>> + >>>> >>>> + // Accessors >>>> >>>> + public long size() { >>>> >>>> + return totalSizeField.getValue(addr); >>>> >>>> + } >>>> >>>> + >>>> >>>> + // Constructor >>>> >>>> + public AFLBinaryTreeDictionary(Address addr) { >>>> >>>> + super(addr); >>>> >>>> + } >>>> >>>> +} >>>> >>>> diff -r b14da2e6f2dc -r 8652e04889a4 >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.ja >>>> va >>>> >>>> --- >>>> a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java >>>> Thu Jan 17 13:40:31 2013 -0500 >>>> >>>> +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 >>>> >>>> @@ -1,59 +0,0 @@ >>>> >>>> -/* >>>> >>>> - * @(#)BinaryTreeDictionary.java >>>> >>>> - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All >>>> rights reserved. >>>> >>>> - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> >>>> - * >>>> >>>> - * This code is free software; you can redistribute it and/or >>>> modify it >>>> >>>> - * under the terms of the GNU General Public License version 2 >>>> only, as >>>> >>>> - * published by the Free Software Foundation. >>>> >>>> - * >>>> >>>> - * This code is distributed in the hope that it will be useful, but >>>> WITHOUT >>>> >>>> - * ANY WARRANTY; without even the implied warranty of >>>> MERCHANTABILITY or >>>> >>>> - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>> License >>>> >>>> - * version 2 for more details (a copy is included in the LICENSE >>>> file that >>>> >>>> - * accompanied this code). >>>> >>>> - * >>>> >>>> - * You should have received a copy of the GNU General Public >>>> License version >>>> >>>> - * 2 along with this work; if not, write to the Free Software >>>> Foundation, >>>> >>>> - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>> >>>> - * >>>> >>>> - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>>> 94065 USA >>>> >>>> - * or visitwww.oracle.comif you need >>>> additional information or have any >>>> >>>> - * questions. >>>> >>>> - * >>>> >>>> - */ >>>> >>>> - >>>> >>>> -package sun.jvm.hotspot.memory; >>>> >>>> - >>>> >>>> -import java.util.*; >>>> >>>> -import sun.jvm.hotspot.debugger.*; >>>> >>>> -import sun.jvm.hotspot.types.*; >>>> >>>> -import sun.jvm.hotspot.runtime.*; >>>> >>>> - >>>> >>>> -public class BinaryTreeDictionary extends VMObject { >>>> >>>> - static { >>>> >>>> - VM.registerVMInitializedObserver(new Observer() { >>>> >>>> - public void update(Observable o, Object data) { >>>> >>>> - initialize(VM.getVM().getTypeDataBase()); >>>> >>>> - } >>>> >>>> - }); >>>> >>>> - } >>>> >>>> - >>>> >>>> - private static synchronized void initialize(TypeDataBase db) { >>>> >>>> - Type type = db.lookupType("BinaryTreeDictionary"); >>>> >>>> - totalSizeField = type.getCIntegerField("_totalSize"); >>>> >>>> - } >>>> >>>> - >>>> >>>> - // Fields >>>> >>>> - private static CIntegerField totalSizeField; >>>> >>>> - >>>> >>>> - // Accessors >>>> >>>> - public long size() { >>>> >>>> - return totalSizeField.getValue(addr); >>>> >>>> - } >>>> >>>> - >>>> >>>> - // Constructor >>>> >>>> - public BinaryTreeDictionary(Address addr) { >>>> >>>> - super(addr); >>>> >>>> - } >>>> >>>> -} >>>> >>>> diff -r b14da2e6f2dc -r 8652e04889a4 >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac >>>> e.java >>>> >>>> --- >>>> a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java >>>> Thu Jan 17 13:40:31 2013 -0500 >>>> >>>> +++ >>>> b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java >>>> Fri Jan 18 09:56:06 2013 +0800 >>>> >>>> @@ -117,7 +117,7 @@ >>>> >>>> } >>>> >>>> // large block >>>> >>>> - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) >>>> VMObjectFactory.newObject(BinaryTreeDictionary.class, >>>> >>>> + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) >>>> VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, >>>> >>>> dictionaryField.getValue(addr)); >>>> >>>> size += bfbd.size(); >>>> >>>> diff -r b14da2e6f2dc -r 8652e04889a4 >>>> agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >>>> >>>> --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >>>> Thu Jan 17 13:40:31 2013 -0500 >>>> >>>> +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >>>> Fri Jan 18 09:56:06 2013 +0800 >>>> >>>> @@ -41,7 +41,7 @@ >>>> >>>> } >>>> >>>> private static synchronized void initialize(TypeDataBase db) { >>>> >>>> - Type type = db.lookupType("FreeList"); >>>> >>>> + Type type = db.lookupType("FreeList"); >>>> >>>> sizeField = type.getCIntegerField("_size"); >>>> >>>> countField = type.getCIntegerField("_count"); >>>> >>>> headerSize = type.getSize(); >>>> >>>> diff -r b14da2e6f2dc -r 8652e04889a4 >>>> >>>> src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>> >>>> --- >>>> a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>> Thu Jan 17 13:40:31 2013 -0500 >>>> >>>> +++ >>>> b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>> Fri Jan 18 09:56:06 2013 +0800 >>>> >>>> @@ -43,7 +43,8 @@ >>>> >>>> nonstatic_field(LinearAllocBlock, _word_size, size_t) \ >>>> >>>> nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ >>>> >>>> nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>>> FreeList) \ >>>> >>>> - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >>>> LinearAllocBlock) >>>> >>>> + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >>>> LinearAllocBlock) \ >>>> >>>> + nonstatic_field(CompactibleFreeListSpace, _dictionary, >>>> FreeBlockDictionary*) >>>> >>>> #define VM_TYPES_CMS(declare_type, \ >>>> >>>> Regards, >>>> >>>> Yunda >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> -- >>>> >>>> >>>> This email (including any attachments) is confidential and may be >>>> legally privileged. If you received this email in error, please >>>> delete it immediately and do not copy it or use it for any purpose >>>> or disclose its contents to any other person. Thank you. >>>> >>>> ??????(????????????)???????????????????????????????????????????????? >>>> ???????????????????????????????????????????????????????????????????? >>>> ???????????????????????? >>>> >>>> ---------------------------------------------------------------------- >>>> -- >>>> >>>> >>>> This email (including any attachments) is confidential and may be >>>> legally privileged. If you received this email in error, please delete >>>> it immediately and do not copy it or use it for any purpose or >>>> disclose its contents to any other person. Thank you. >>>> >>>> ??????(????????????)???????????????????????????????????????????????????? >>>> ???????????????????????????????????????????????????????????????????????? >>>> ???????????????? >>>> >>>> >>>> >>> >>> ________________________________ >>> >>> This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. >>> >>> ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > From staffan.larsen at oracle.com Sun Jan 20 23:59:41 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 21 Jan 2013 08:59:41 +0100 Subject: Errors when use "universe" command in CLHSDB In-Reply-To: <50FCEE78.1090508@oracle.com> References: <50F8B771.3080505@oracle.com> <50FCAB9B.3080107@oracle.com> <50FCBD4E.1050200@oracle.com> <50FCEE78.1090508@oracle.com> Message-ID: <7E661934-8BA9-4CD6-94A5-88D98DB7AD8E@oracle.com> On 21 jan 2013, at 08:30, David Holmes wrote: > On 21/01/2013 5:11 PM, Staffan Larsen wrote: >> A webrev is here: http://cr.openjdk.java.net/~sla/8005278/webrev.00/ > > Thanks. > > So based on the error message the actual fix here seems to be in > > src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > > where we add: > > nonstatic_field(CompactibleFreeListSpace,_dictionary,FreeBlockDictionary*) Yes, this is the real fix (as well as the fix in agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java). > So I am still missing why we needed to change the BinaryTreeDictionary > to AFLBinaryTreeDictionary ? I'm unclear whether the typedef in the > vmStructs needs to be used in the SA code or whether the SA should just > be referring to the real type ?? Not clear to me, either. The initialize() code in BinaryTreeDictionary.java said 43 Type type = db.lookupType("BinaryTreeDictionary"); 44 totalSizeField = type.getCIntegerField("_totalSize"); This needs to change to 43 Type type = db.lookupType("AFLBinaryTreeDictionary"); 44 totalSizeField = type.getCIntegerField("_total_size"); For the code to work. I think the change on line 43 is because vmStructs_cms.hpp declares "AFLBinaryTreeDictionary" as the exported type name: declare_type(AFLBinaryTreeDictionary, FreeBlockDictionary) vmStructs could have exported "BinaryTreeDictionary" as the type name. In any case BinaryTreeDictionary.java can only be one of the templated instances of BinaryTreeDictionary<> in the C++ code (at least that is how I think it works - are there other examples of how templated classes are handled in SA?). Thus, renaming it to the name of the exported type name makes sense. Thanks, /Staffan > > Assuming we do need to rename this then hg mv should be used (which > seems not to be the case in the webrev) > > This problem seems to have been introduced with > > changeset: 3767:685df3c6f84b > parent: 3758:d0e7716b179e > user: jmasa > date: Tue Sep 18 23:35:42 2012 -0700 > summary: 7045397: NPG: Add freelists to class loader arenas. > > So I've added Jon to the cc list. > > Thanks, > David > >> /Staffan >> >> On 21 jan 2013, at 05:00, David Holmes wrote: >> >>> On 21/01/2013 1:06 PM, ???? wrote: >>>> Actually I just changed "BinaryTreeDictionary" to "AFLBinaryTreeDictionary", since there is no definition of BinaryTreeDictionary in the latest hotspot: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/file/b5f6465019f6/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp , which has been changed to AFLBinaryTreeDictionary. So the code in SA has to change too. The bug is already found here: http://bugs.sun.com/view_bug.do?bug_id=8005278 >>> >>> I'm still missing some pieces here. We have: >>> >>> typedef BinaryTreeDictionary >>> AFLBinaryTreeDictionary; >>> >>> in vmStructs and we have: >>> >>> ./share/vm/memory/binaryTreeDictionary.hpp/cpp >>> >>> and we have: >>> >>> src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java >>> >>> So I'm unclear what is causing the problem here. >>> >>> Staffan: can you generate a webrev from this patch to make the context >>> clearer please? >>> >>> Thanks, >>> David >>> >>>> Regards, >>>> Yunda >>>> -----????????----- >>>> ??????: David Holmes [mailto:david.holmes at oracle.com] >>>> ????????: 2013??1??21?? 10:45 >>>> ??????: ???? >>>> ????: Staffan Larsen; serviceability-dev at openjdk.java.net >>>> ????: Re: ????: Errors when use "universe" command in CLHSDB >>>> >>>> I couldn't quite understand the problem and fix from the patch. Why do we need to add AFLBinaryTreeDictionary ?? >>>> >>>> Thanks, >>>> David >>>> >>>> On 21/01/2013 12:03 PM, ???? wrote: >>>>> Thanks for your review again. Could someone with Reviewer status help >>>>> me with this? Thanks in advance! >>>>> >>>>> Regards, >>>>> >>>>> Yunda >>>>> >>>>> *??????:*Staffan Larsen [mailto:staffan.larsen at oracle.com] >>>>> *????????:*2013??1??18??20:14 >>>>> *??????:*???? >>>>> *????:*daniel.daugherty at oracle.com; serviceability-dev at openjdk.java.net >>>>> *????:*Re: Errors when use "universe" command in CLHSDB >>>>> >>>>> This patch applied cleanly. >>>>> >>>>> I can sponsor this fix, but we still need a review from someone with >>>>> Reviewer status. Once we have that, I can push the change. >>>>> >>>>> Thanks, >>>>> >>>>> /Staffan >>>>> >>>>> On 18 jan 2013, at 11:22, ????>>>> > wrote: >>>>> >>>>> >>>>> >>>>> OK. I diffed it with the >>>>> latesthttp://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/and I hope it >>>>> works. Thanks for the review! >>>>> >>>>> Regards, >>>>> >>>>> Yunda >>>>> >>>>> *??????:*Staffan Larsen [mailto:staffan.larsen at oracle.com >>>>> ] >>>>> *????????:*2013??1??18??17:07 >>>>> *??????:*???? >>>>> *????:*daniel.daugherty at oracle.com; >>>>> serviceability-dev at openjdk.java.net >>>>> >>>>> *????:*Re: Errors when use "universe" command in CLHSDB >>>>> >>>>> Yunda, >>>>> >>>>> I think this fixes http://bugs.sun.com/view_bug.do?bug_id=8005278 >>>>> >>>>> The changes look good to me. I couldn't apply the patch to the code >>>>> cleanly, however (see below). Perhaps the patch was broken in email? >>>>> Can you regenerate the patch and include it as a zipped attachment? >>>>> >>>>> Thanks, >>>>> >>>>> /Staffan >>>>> >>>>> file >>>>> agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary >>>>> .java >>>>> already exists >>>>> 1 out of 1 hunks FAILED -- saving rejects to file >>>>> agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary >>>>> .java.rej >>>>> patching file >>>>> agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac >>>>> e.java >>>>> Hunk #1 FAILED at 116 >>>>> Hunk #2 FAILED at 40 >>>>> 2 out of 2 hunks FAILED -- saving rejects to file >>>>> agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac >>>>> e.java.rej >>>>> patching file >>>>> src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>>> Hunk #1 succeeded at 45 with fuzz 2 (offset 0 lines). >>>>> patch failed, unable to continue (try -v) patch failed, rejects left >>>>> in working dir >>>>> >>>>> On 18 jan 2013, at 04:54,????>>>> > wrote: >>>>> >>>>> >>>>> >>>>> >>>>> Thanks Dan! >>>>> >>>>> Regards, >>>>> >>>>> Yunda >>>>> >>>>> *??????:*Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com >>>>> ] >>>>> *????????:*2013??1??18??10:46 >>>>> *??????:*????;serviceability-dev at openjdk.java.net >>>>> >>>>> *????:*Re: Errors when use "universe" command in CLHSDB >>>>> >>>>> Yunda, >>>>> >>>>> The Serviceability Agent is maintained by the Serviceability team. >>>>> I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime >>>>> alias. >>>>> >>>>> Dan >>>>> >>>>> On 1/17/13 7:42 PM,????wrote: >>>>> >>>>> Hi all, >>>>> >>>>> This is Yunda >>>>> from Alibaba Group(with OCA). >>>>> >>>>> When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar >>>>> sun.jvm.hotspot.CLHSDB) I found two errors below(the second error >>>>> occurred after I made some fix). It seemed that some code about CMS >>>>> in SA didn??t change accordingly. >>>>> >>>>> hsdb> universe >>>>> >>>>> Heap Parameters: >>>>> >>>>> Gen 0: eden >>>>> [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space >>>>> capacity = 140640256, 2.000007736049627 used >>>>> >>>>> from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) >>>>> space capacity = 17563648, 0.0 used >>>>> >>>>> to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space >>>>> capacity = 17563648, 0.0 usedInvocations: 0 >>>>> >>>>> Gen 1: concurrent mark-sweep generation >>>>> >>>>> Exception in thread "main" java.lang.ExceptionInInitializerError >>>>> >>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>>> Method) >>>>> >>>>> at >>>>> >>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructo >>>>> rAccessorImpl.java:57) >>>>> >>>>> at >>>>> >>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo >>>>> nstructorAccessorImpl.java:45) >>>>> >>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:395) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java >>>>> :58) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(Concurre >>>>> ntMarkSweepGeneration.java:55) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(Concurren >>>>> tMarkSweepGeneration.java:79) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java: >>>>> 139) >>>>> >>>>> at >>>>> sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >>>>> 1897) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >>>>> 1867) >>>>> >>>>> at >>>>> sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) >>>>> >>>>> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) >>>>> >>>>> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) >>>>> >>>>> Caused by: java.lang.RuntimeException: field "_dictionary" not found >>>>> in type CompactibleFreeListSpace >>>>> >>>>> at >>>>> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) >>>>> >>>>> at >>>>> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) >>>>> >>>>> at >>>>> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:2 >>>>> 82) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(Compactible >>>>> FreeListSpace.java:69) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(Compactible >>>>> FreeListSpace.java:35) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFr >>>>> eeListSpace.java:55) >>>>> >>>>> at >>>>> sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFr >>>>> eeListSpace.java:53) >>>>> >>>>> ... 14 more >>>>> >>>>> hsdb> universe >>>>> >>>>> Heap Parameters: >>>>> >>>>> Gen 0: eden >>>>> [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space >>>>> capacity = 140640256, 2.000007736049627 used >>>>> >>>>> from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) >>>>> space capacity = 17563648, 0.0 used >>>>> >>>>> to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space >>>>> capacity = 17563648, 0.0 usedInvocations: 0 >>>>> >>>>> Gen 1: concurrent mark-sweep generation >>>>> >>>>> free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception >>>>> in thread "main" java.lang.ExceptionInInitializerError >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeLi >>>>> stSpace.java:112) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeLi >>>>> stSpace.java:95) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFre >>>>> eListSpace.java:137) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(Concurren >>>>> tMarkSweepGeneration.java:79) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java: >>>>> 139) >>>>> >>>>> at >>>>> sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >>>>> 1897) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java: >>>>> 1867) >>>>> >>>>> at >>>>> sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) >>>>> >>>>> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) >>>>> >>>>> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) >>>>> >>>>> Caused by: java.lang.RuntimeException: No type named "FreeList" in >>>>> database >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeData >>>>> Base.java:80) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.jav >>>>> a:134) >>>>> >>>>> at >>>>> >>>>> sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeData >>>>> Base.java:74) >>>>> >>>>> at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) >>>>> >>>>> at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) >>>>> >>>>> at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) >>>>> >>>>> at >>>>> sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) >>>>> >>>>> at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) >>>>> >>>>> ... 11 more >>>>> >>>>> So I made a patch to fix them and now ??universe?? command works well. >>>>> Could someone help to review the patch below? >>>>> >>>>> diff -r b14da2e6f2dc -r 8652e04889a4 >>>>> >>>>> agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary >>>>> .java >>>>> >>>>> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >>>>> >>>>> +++ >>>>> b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java >>>>> Fri Jan 18 09:56:06 2013 +0800 >>>>> >>>>> @@ -0,0 +1,59 @@ >>>>> >>>>> +/* >>>>> >>>>> + * @(#)AFLBinaryTreeDictionary.java >>>>> >>>>> + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> >>>>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> >>>>> + * >>>>> >>>>> + * This code is free software; you can redistribute it and/or >>>>> modify it >>>>> >>>>> + * under the terms of the GNU General Public License version 2 >>>>> only, as >>>>> >>>>> + * published by the Free Software Foundation. >>>>> >>>>> + * >>>>> >>>>> + * This code is distributed in the hope that it will be useful, but >>>>> WITHOUT >>>>> >>>>> + * ANY WARRANTY; without even the implied warranty of >>>>> MERCHANTABILITY or >>>>> >>>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>> License >>>>> >>>>> + * version 2 for more details (a copy is included in the LICENSE >>>>> file that >>>>> >>>>> + * accompanied this code). >>>>> >>>>> + * >>>>> >>>>> + * You should have received a copy of the GNU General Public >>>>> License version >>>>> >>>>> + * 2 along with this work; if not, write to the Free Software >>>>> Foundation, >>>>> >>>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>>> >>>>> + * >>>>> >>>>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>>>> 94065 USA >>>>> >>>>> + * or visitwww.oracle.comif you need >>>>> additional information or have any >>>>> >>>>> + * questions. >>>>> >>>>> + * >>>>> >>>>> + */ >>>>> >>>>> + >>>>> >>>>> +package sun.jvm.hotspot.memory; >>>>> >>>>> + >>>>> >>>>> +import java.util.*; >>>>> >>>>> +import sun.jvm.hotspot.debugger.*; >>>>> >>>>> +import sun.jvm.hotspot.types.*; >>>>> >>>>> +import sun.jvm.hotspot.runtime.*; >>>>> >>>>> + >>>>> >>>>> +public class AFLBinaryTreeDictionary extends VMObject { >>>>> >>>>> + static { >>>>> >>>>> + VM.registerVMInitializedObserver(new Observer() { >>>>> >>>>> + public void update(Observable o, Object data) { >>>>> >>>>> + initialize(VM.getVM().getTypeDataBase()); >>>>> >>>>> + } >>>>> >>>>> + }); >>>>> >>>>> + } >>>>> >>>>> + >>>>> >>>>> + private static synchronized void initialize(TypeDataBase db) { >>>>> >>>>> + Type type = db.lookupType("AFLBinaryTreeDictionary"); >>>>> >>>>> + totalSizeField = type.getCIntegerField("_total_size"); >>>>> >>>>> + } >>>>> >>>>> + >>>>> >>>>> + // Fields >>>>> >>>>> + private static CIntegerField totalSizeField; >>>>> >>>>> + >>>>> >>>>> + // Accessors >>>>> >>>>> + public long size() { >>>>> >>>>> + return totalSizeField.getValue(addr); >>>>> >>>>> + } >>>>> >>>>> + >>>>> >>>>> + // Constructor >>>>> >>>>> + public AFLBinaryTreeDictionary(Address addr) { >>>>> >>>>> + super(addr); >>>>> >>>>> + } >>>>> >>>>> +} >>>>> >>>>> diff -r b14da2e6f2dc -r 8652e04889a4 >>>>> >>>>> agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.ja >>>>> va >>>>> >>>>> --- >>>>> a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java >>>>> Thu Jan 17 13:40:31 2013 -0500 >>>>> >>>>> +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 >>>>> >>>>> @@ -1,59 +0,0 @@ >>>>> >>>>> -/* >>>>> >>>>> - * @(#)BinaryTreeDictionary.java >>>>> >>>>> - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> >>>>> - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> >>>>> - * >>>>> >>>>> - * This code is free software; you can redistribute it and/or >>>>> modify it >>>>> >>>>> - * under the terms of the GNU General Public License version 2 >>>>> only, as >>>>> >>>>> - * published by the Free Software Foundation. >>>>> >>>>> - * >>>>> >>>>> - * This code is distributed in the hope that it will be useful, but >>>>> WITHOUT >>>>> >>>>> - * ANY WARRANTY; without even the implied warranty of >>>>> MERCHANTABILITY or >>>>> >>>>> - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>> License >>>>> >>>>> - * version 2 for more details (a copy is included in the LICENSE >>>>> file that >>>>> >>>>> - * accompanied this code). >>>>> >>>>> - * >>>>> >>>>> - * You should have received a copy of the GNU General Public >>>>> License version >>>>> >>>>> - * 2 along with this work; if not, write to the Free Software >>>>> Foundation, >>>>> >>>>> - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>>> >>>>> - * >>>>> >>>>> - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>>>> 94065 USA >>>>> >>>>> - * or visitwww.oracle.comif you need >>>>> additional information or have any >>>>> >>>>> - * questions. >>>>> >>>>> - * >>>>> >>>>> - */ >>>>> >>>>> - >>>>> >>>>> -package sun.jvm.hotspot.memory; >>>>> >>>>> - >>>>> >>>>> -import java.util.*; >>>>> >>>>> -import sun.jvm.hotspot.debugger.*; >>>>> >>>>> -import sun.jvm.hotspot.types.*; >>>>> >>>>> -import sun.jvm.hotspot.runtime.*; >>>>> >>>>> - >>>>> >>>>> -public class BinaryTreeDictionary extends VMObject { >>>>> >>>>> - static { >>>>> >>>>> - VM.registerVMInitializedObserver(new Observer() { >>>>> >>>>> - public void update(Observable o, Object data) { >>>>> >>>>> - initialize(VM.getVM().getTypeDataBase()); >>>>> >>>>> - } >>>>> >>>>> - }); >>>>> >>>>> - } >>>>> >>>>> - >>>>> >>>>> - private static synchronized void initialize(TypeDataBase db) { >>>>> >>>>> - Type type = db.lookupType("BinaryTreeDictionary"); >>>>> >>>>> - totalSizeField = type.getCIntegerField("_totalSize"); >>>>> >>>>> - } >>>>> >>>>> - >>>>> >>>>> - // Fields >>>>> >>>>> - private static CIntegerField totalSizeField; >>>>> >>>>> - >>>>> >>>>> - // Accessors >>>>> >>>>> - public long size() { >>>>> >>>>> - return totalSizeField.getValue(addr); >>>>> >>>>> - } >>>>> >>>>> - >>>>> >>>>> - // Constructor >>>>> >>>>> - public BinaryTreeDictionary(Address addr) { >>>>> >>>>> - super(addr); >>>>> >>>>> - } >>>>> >>>>> -} >>>>> >>>>> diff -r b14da2e6f2dc -r 8652e04889a4 >>>>> >>>>> agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpac >>>>> e.java >>>>> >>>>> --- >>>>> a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java >>>>> Thu Jan 17 13:40:31 2013 -0500 >>>>> >>>>> +++ >>>>> b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java >>>>> Fri Jan 18 09:56:06 2013 +0800 >>>>> >>>>> @@ -117,7 +117,7 @@ >>>>> >>>>> } >>>>> >>>>> // large block >>>>> >>>>> - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) >>>>> VMObjectFactory.newObject(BinaryTreeDictionary.class, >>>>> >>>>> + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) >>>>> VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, >>>>> >>>>> dictionaryField.getValue(addr)); >>>>> >>>>> size += bfbd.size(); >>>>> >>>>> diff -r b14da2e6f2dc -r 8652e04889a4 >>>>> agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >>>>> >>>>> --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >>>>> Thu Jan 17 13:40:31 2013 -0500 >>>>> >>>>> +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >>>>> Fri Jan 18 09:56:06 2013 +0800 >>>>> >>>>> @@ -41,7 +41,7 @@ >>>>> >>>>> } >>>>> >>>>> private static synchronized void initialize(TypeDataBase db) { >>>>> >>>>> - Type type = db.lookupType("FreeList"); >>>>> >>>>> + Type type = db.lookupType("FreeList"); >>>>> >>>>> sizeField = type.getCIntegerField("_size"); >>>>> >>>>> countField = type.getCIntegerField("_count"); >>>>> >>>>> headerSize = type.getSize(); >>>>> >>>>> diff -r b14da2e6f2dc -r 8652e04889a4 >>>>> >>>>> src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>>> >>>>> --- >>>>> a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>>> Thu Jan 17 13:40:31 2013 -0500 >>>>> >>>>> +++ >>>>> b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>>> Fri Jan 18 09:56:06 2013 +0800 >>>>> >>>>> @@ -43,7 +43,8 @@ >>>>> >>>>> nonstatic_field(LinearAllocBlock, _word_size, size_t) \ >>>>> >>>>> nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ >>>>> >>>>> nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>>>> FreeList) \ >>>>> >>>>> - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >>>>> LinearAllocBlock) >>>>> >>>>> + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >>>>> LinearAllocBlock) \ >>>>> >>>>> + nonstatic_field(CompactibleFreeListSpace, _dictionary, >>>>> FreeBlockDictionary*) >>>>> >>>>> #define VM_TYPES_CMS(declare_type, \ >>>>> >>>>> Regards, >>>>> >>>>> Yunda >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> -- >>>>> >>>>> >>>>> This email (including any attachments) is confidential and may be >>>>> legally privileged. If you received this email in error, please >>>>> delete it immediately and do not copy it or use it for any purpose >>>>> or disclose its contents to any other person. Thank you. >>>>> >>>>> ??????(????????????)???????????????????????????????????????????????? >>>>> ???????????????????????????????????????????????????????????????????? >>>>> ???????????????????????? >>>>> >>>>> ---------------------------------------------------------------------- >>>>> -- >>>>> >>>>> >>>>> This email (including any attachments) is confidential and may be >>>>> legally privileged. If you received this email in error, please delete >>>>> it immediately and do not copy it or use it for any purpose or >>>>> disclose its contents to any other person. Thank you. >>>>> >>>>> ??????(????????????)???????????????????????????????????????????????????? >>>>> ???????????????????????????????????????????????????????????????????????? >>>>> ???????????????? >>>>> >>>>> >>>>> >>>> >>>> ________________________________ >>>> >>>> This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. >>>> >>>> ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> From bengt.rutisson at oracle.com Mon Jan 21 02:37:04 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Mon, 21 Jan 2013 10:37:04 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large Message-ID: <20130121103708.EC3134741D@hg.openjdk.java.net> Changeset: c07c102cbad7 Author: brutisso Date: 2013-01-21 09:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c07c102cbad7 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large Summary: Use HW_MEMSIZE instead of HW_USERMEM to get a 64 bit value of the physical memory on the machine. Also reviewed by vitalyd at gmail.com. Reviewed-by: sla, dholmes, dlong, mikael ! src/os/bsd/vm/os_bsd.cpp From Alan.Bateman at oracle.com Mon Jan 21 05:21:15 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Jan 2013 13:21:15 +0000 Subject: 8006565: java.lang.instrument specification should make it clear that -javaagent is optional Message-ID: <50FD40CB.9000709@oracle.com> The optionally of JVM TI is clear in its specification, the status of java.lang.management, or more specifically the -javaagent option is less clear. The change proposed here is to make it very clear that -javaagent is not required to be supported. The motive is small environments where it should not be necessary to have a way to start tool agents even though there may be command-line support. Thanks, -Alan diff --git a/src/share/classes/java/lang/instrument/package.html b/src/share/classes/java/lang/instrument/package.html --- a/src/share/classes/java/lang/instrument/package.html +++ b/src/share/classes/java/lang/instrument/package.html @@ -53,8 +53,10 @@

Command-Line Interface

-On implementations with a command-line interface, an agent is started by -adding this option to the command-line: +An implementation is not required to provide a way to start agents from the +command-line. Where an implementation does provide a way to start agents from +the command-line, then an agent is started by adding this option to the +command-line:

-javaagent:jarpath[=options]
From staffan.larsen at oracle.com Mon Jan 21 05:44:13 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 21 Jan 2013 14:44:13 +0100 Subject: 8006565: java.lang.instrument specification should make it clear that -javaagent is optional In-Reply-To: <50FD40CB.9000709@oracle.com> References: <50FD40CB.9000709@oracle.com> Message-ID: Looks good. /Staffan On 21 jan 2013, at 14:21, Alan Bateman wrote: > > The optionally of JVM TI is clear in its specification, the status of java.lang.management, or more specifically the -javaagent option is less clear. The change proposed here is to make it very clear that -javaagent is not required to be supported. The motive is small environments where it should not be necessary to have a way to start tool agents even though there may be command-line support. > > Thanks, > > -Alan > > > diff --git a/src/share/classes/java/lang/instrument/package.html b/src/share/classes/java/lang/instrument/package.html > --- a/src/share/classes/java/lang/instrument/package.html > +++ b/src/share/classes/java/lang/instrument/package.html > @@ -53,8 +53,10 @@ >

Command-Line Interface

> >

> -On implementations with a command-line interface, an agent is started by > -adding this option to the command-line: > +An implementation is not required to provide a way to start agents from the > +command-line. Where an implementation does provide a way to start agents from > +the command-line, then an agent is started by adding this option to the > +command-line: >

> -javaagent:jarpath[=options] >
From chris.hegarty at oracle.com Mon Jan 21 05:51:26 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 21 Jan 2013 13:51:26 +0000 Subject: hg: jdk8/tl/jdk: 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder Message-ID: <20130121135207.0FE2947420@hg.openjdk.java.net> Changeset: f21a3c273fb2 Author: dl Date: 2013-01-21 13:50 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f21a3c273fb2 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder Reviewed-by: chegar, darcy, goetz ! make/java/java/FILES_java.gmk + src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java + src/share/classes/java/util/concurrent/atomic/DoubleAdder.java + src/share/classes/java/util/concurrent/atomic/LongAccumulator.java + src/share/classes/java/util/concurrent/atomic/LongAdder.java + src/share/classes/java/util/concurrent/atomic/Striped64.java + test/java/util/concurrent/atomic/DoubleAdderDemo.java + test/java/util/concurrent/atomic/LongAdderDemo.java From rickard.backman at oracle.com Mon Jan 21 06:09:19 2013 From: rickard.backman at oracle.com (=?utf-8?Q?Rickard_B=C3=A4ckman?=) Date: Mon, 21 Jan 2013 15:09:19 +0100 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <50FCA114.7030908@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> <50FCA114.7030908@oracle.com> Message-ID: Yes, that code has changed. Checked in to hs24. /R 21 jan 2013 kl. 02:59 skrev David Holmes : > On 18/01/2013 11:45 PM, Rickard B?ckman wrote: >> Aleksey, >> >> thanks for your review! >> >> a) It was before on of my own changes used in os_solaris.cpp (I think, for synchronization support for Suspend/Resume). >> I don't think we wanted something external to mess with that lock. > > Seems to be used here: > > ./os/solaris/vm/os_solaris.cpp: > > 4265 GetThreadPC_Callback cb(ProfileVM_lock); > > Is this code already undergoing removal as part of the JFR changes? > > Thanks, > David > ----- > > >> b) I've changed the indentation slightly. >> Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) >> >> /R >> >> On Jan 18, 2013, at 2:12 PM, Aleksey Shipilev wrote: >> >>> On 01/18/2013 04:58 PM, Rickard B?ckman wrote: >>>> http://cr.openjdk.java.net/~rbackman/8006563/ >>> >>> Looks good to me (not a Reviewer), modulo: >>> a) Are we sure this thing is not acquired in some weird way, i.e. >>> through JVMTI, SA, or whatnot? >>> b) The formatting of the predicate does not follow it's structure, I >>> think it should be: >>> ... >>> this != Interrupt_lock&& >>> !(this == Safepoint_lock&& >>> contains(locks, Terminator_lock)&& >>> SafepointSynchronize::is_synchronizing())) { >>> >>> This way it is more obvious SafepointSynchronize::is_synchronizing()) is >>> the !(...) group. >>> >>> -Aleksey. >> From daniel.daugherty at oracle.com Mon Jan 21 06:41:01 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 21 Jan 2013 07:41:01 -0700 Subject: 8006565: java.lang.instrument specification should make it clear that -javaagent is optional In-Reply-To: <50FD40CB.9000709@oracle.com> References: <50FD40CB.9000709@oracle.com> Message-ID: <50FD537D.6030504@oracle.com> Thumbs up! Dan On 1/21/13 6:21 AM, Alan Bateman wrote: > > The optionally of JVM TI is clear in its specification, the status of > java.lang.management, or more specifically the -javaagent option is > less clear. The change proposed here is to make it very clear that > -javaagent is not required to be supported. The motive is small > environments where it should not be necessary to have a way to start > tool agents even though there may be command-line support. > > Thanks, > > -Alan > > > diff --git a/src/share/classes/java/lang/instrument/package.html > b/src/share/classes/java/lang/instrument/package.html > --- a/src/share/classes/java/lang/instrument/package.html > +++ b/src/share/classes/java/lang/instrument/package.html > @@ -53,8 +53,10 @@ >

Command-Line Interface

> >

> -On implementations with a command-line interface, an agent is started by > -adding this option to the command-line: > +An implementation is not required to provide a way to start agents > from the > +command-line. Where an implementation does provide a way to start > agents from > +the command-line, then an agent is started by adding this option to the > +command-line: >

> -javaagent:jarpath[=options] > >
From jonathan.gibbons at oracle.com Mon Jan 21 10:01:30 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 21 Jan 2013 18:01:30 +0000 Subject: hg: jdk8/tl/langtools: 8006263: Supplementary test cases needed for doclint Message-ID: <20130121180135.C92B34742C@hg.openjdk.java.net> Changeset: 4a3cfc970c6f Author: jjg Date: 2013-01-21 10:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a3cfc970c6f 8006263: Supplementary test cases needed for doclint Reviewed-by: mcimadamore Contributed-by: peter.jensen at oracle.com ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/Entity.java ! src/share/classes/com/sun/tools/doclint/HtmlTag.java + test/tools/doclint/CoverageExtras.java ! test/tools/doclint/DocLintTester.java + test/tools/doclint/html/EntitiesTest.java + test/tools/doclint/html/EntitiesTest.out + test/tools/doclint/tool/HelpTest.java + test/tools/doclint/tool/HelpTest.out + test/tools/doclint/tool/MaxDiagsTest.java + test/tools/doclint/tool/MaxDiagsTest.out + test/tools/doclint/tool/PathsTest.java + test/tools/doclint/tool/RunTest.java + test/tools/doclint/tool/StatsTest.java + test/tools/doclint/tool/StatsTest.out From jonathan.gibbons at oracle.com Mon Jan 21 10:07:48 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 21 Jan 2013 18:07:48 +0000 Subject: hg: jdk8/tl/langtools: 8006251: doclint: incorrect position for diagnostic for illegal text in tags Message-ID: <20130121180751.01A7D4742D@hg.openjdk.java.net> Changeset: 967052c425a1 Author: jjg Date: 2013-01-21 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/967052c425a1 8006251: doclint: incorrect position for diagnostic for illegal text in tags Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! test/tools/doclint/HtmlTagsTest.java ! test/tools/doclint/HtmlTagsTest.out + test/tools/doclint/html/BlockTagsTest.java + test/tools/doclint/html/InlineTagsTest.java + test/tools/doclint/html/ListTagsTest.java + test/tools/doclint/html/OtherTagsTest.java + test/tools/doclint/html/OtherTagsTest.out + test/tools/doclint/html/TableTagsTest.java + test/tools/doclint/html/TagNotAllowed.java + test/tools/doclint/html/TagNotAllowed.out + test/tools/doclint/html/TextNotAllowed.java + test/tools/doclint/html/TextNotAllowed.out ! test/tools/doclint/tidy/ParaInPre.out ! test/tools/doclint/tidy/TextNotAllowed.out From mandy.chung at oracle.com Mon Jan 21 10:39:03 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 21 Jan 2013 10:39:03 -0800 Subject: 8006565: java.lang.instrument specification should make it clear that -javaagent is optional In-Reply-To: <50FD40CB.9000709@oracle.com> References: <50FD40CB.9000709@oracle.com> Message-ID: <50FD8B47.1040603@oracle.com> On 1/21/2013 5:21 AM, Alan Bateman wrote: > > The optionally of JVM TI is clear in its specification, the status of > java.lang.management, You meant java.lang.instrument (as in the subject). > or more specifically the -javaagent option is less clear. The change > proposed here is to make it very clear that -javaagent is not required > to be supported. The motive is small environments where it should not > be necessary to have a way to start tool agents even though there may > be command-line support. The change looks good to me. Mandy From krystal.mo at oracle.com Mon Jan 21 10:43:22 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Tue, 22 Jan 2013 02:43:22 +0800 Subject: Request for review (XS): JDK-8006641: JDK-8003985 broke InstanceKlass.getFieldOffset() in SA Message-ID: <50FD8C4A.7040607@oracle.com> Hi all, Could someone review this small patch, please? JDK-8006641: JDK-8003985 broke InstanceKlass.getFieldOffset() in SA Webrev: http://cr.openjdk.java.net/~kmo/8006641/webrev.00/ Bug: https://jbs.oracle.com/bugs/browse/JDK-8006641 (public bug will be available soon at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006641) Description: JDK-8003985 introduced "packed offsets" in InstanceKlass' fields array, so code accessing field offset in InstanceKlass was changed accordingly. But the change in the SA part mistakenly used FIELDINFO_TAG_SIZE instead of FIELDINFO_TAG_MASK for masking in InstanceKlass.getFieldOffset(), which broke a couple of utils in SA, e.g. PStack This change aligns the SA code back in sync with the VM code for InstanceKlass.getFieldOffset(). Tested with a simple test case that would fail before the fix. Thanks, Kris (The scenario I tested with is described below) I was trying to hunt down a 292 bug and when I used the pstack command in clhsdb, I got: hsdb> pstack -v Error: java.lang.RuntimeException: should not reach here java.lang.RuntimeException: should not reach here at sun.jvm.hotspot.oops.InstanceKlass.getFieldOffset(InstanceKlass.java:327) at sun.jvm.hotspot.oops.Field.(Field.java:47) at sun.jvm.hotspot.oops.OopField.(OopField.java:42) at sun.jvm.hotspot.oops.NarrowOopField.(NarrowOopField.java:40) at sun.jvm.hotspot.oops.InstanceKlass.newField(InstanceKlass.java:913) at sun.jvm.hotspot.oops.InstanceKlass.findLocalField(InstanceKlass.java:628) at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:665) at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:689) at sun.jvm.hotspot.oops.OopUtilities.initAbsOwnSyncFields(OopUtilities.java:305) at sun.jvm.hotspot.oops.OopUtilities.abstractOwnableSynchronizerGetOwnerThread(OopUtilities.java:312) at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.getOwnerThread(ConcurrentLocksPrinter.java:55) at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.access$000(ConcurrentLocksPrinter.java:32) at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter$1.doObj(ConcurrentLocksPrinter.java:72) at sun.jvm.hotspot.oops.ObjectHeap.iterateLiveRegions(ObjectHeap.java:354) at sun.jvm.hotspot.oops.ObjectHeap.iterateSubtypes(ObjectHeap.java:287) at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass(ObjectHeap.java:187) at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks(ConcurrentLocksPrinter.java:70) at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.(ConcurrentLocksPrinter.java:36) at sun.jvm.hotspot.tools.PStack.run(PStack.java:68) at sun.jvm.hotspot.tools.PStack.run(PStack.java:57) at sun.jvm.hotspot.CommandProcessor$31.doit(CommandProcessor.java:1084) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Which led me to finding this bug. After the fix, the pstack command ran fine again: hsdb> pstack -v Deadlock Detection: No deadlocks found. ----------------- 10912 ----------------- 0x00007fc87d037d84 __pthread_cond_wait + 0xc4 0x00007fc87beb9657 _ZN7Monitor5IWaitEP6Threadl + 0x127 0x00007fc87bebbaf9 _ZN7Monitor4waitEblb + 0x319 0x00007fc87b951467 _ZN12CompileQueue3getEv + 0x107 0x00007fc87b957074 _ZN13CompileBroker20compiler_thread_loopEv + 0x274 0x00007fc87c11ce6e _ZN10JavaThread17thread_main_innerEv + 0x18e 0x00007fc87c11d0ef _ZN10JavaThread3runEv + 0x23f 0x00007fc87bf154c2 _ZL10java_startP6Thread + 0x132 Locked ownable synchronizers: - None ----------------- 10914 ----------------- 0x00007fc87d0380fe __pthread_cond_timedwait + 0x13e 0x00007fc87beb9a87 _ZN7Monitor5IWaitEP6Threadl + 0x557 0x00007fc87bebb93c _ZN7Monitor4waitEblb + 0x15c 0x00007fc87c1105e3 _ZNK13WatcherThread5sleepEv + 0x73 0x00007fc87c110755 _ZN13WatcherThread3runEv + 0xd5 0x00007fc87bf154c2 _ZL10java_startP6Thread + 0x132 ----------------- 10909 ----------------- 0x00007fc87d039fd0 sem_wait + 0x30 0x00007fc87bf11cb9 _ZL19signal_thread_entryP10JavaThreadP6Thread + 0x59 0x00007fc87c11ce6e _ZN10JavaThread17thread_main_innerEv + 0x18e 0x00007fc87c11d0ef _ZN10JavaThread3runEv + 0x23f 0x00007fc87bf154c2 _ZL10java_startP6Thread + 0x132 Locked ownable synchronizers: - None ----------------- 10906 ----------------- 0x00007fc87d0380fe __pthread_cond_timedwait + 0x13e 0x00007fc87beb9a87 _ZN7Monitor5IWaitEP6Threadl + 0x557 0x00007fc87bebb93c _ZN7Monitor4waitEblb + 0x15c 0x00007fc87c1b0960 _ZN8VMThread4loopEv + 0x3f0 0x00007fc87c1b0db1 _ZN8VMThread3runEv + 0xb1 0x00007fc87bf154c2 _ZL10java_startP6Thread + 0x132 ----------------- 10908 ----------------- 0x00007fc87d037d84 __pthread_cond_wait + 0xc4 0x00007fc87befcae5 _ZN13ObjectMonitor4waitElbP6Thread + 0xb75 0x00007fc87bc72db0 JVM_MonitorWait + 0x1b0 0x00007fc86e023d42 * java.lang.Object.wait(long) bci:0 Method*:0x00007fc879793c60 (Interpreted frame) 0x00007fc86e006278 * java.lang.ref.ReferenceQueue.remove(long) bci:44 line:135 Method*:0x00007fc87984b1e0 (Interpreted frame) 0x00007fc86e006453 * java.lang.ref.ReferenceQueue.remove() bci:2 line:151 Method*:0x00007fc87984b2b0 (Interpreted frame) 0x00007fc86e006453 * java.lang.ref.Finalizer$FinalizerThread.run() bci:3 line:177 Method*:0x00007fc87984c210 (Interpreted frame) 0x00007fc86e000681 0x00007fc87bbef138 _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread + 0x1b18 0x00007fc87bbeb64f _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandleP6SymbolS4_P17JavaCallArgumentsP6Thread + 0x5cf 0x00007fc87bbebe7a _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandleP6SymbolS5_P6Thread + 0x5a 0x00007fc87bc6f92e _ZL12thread_entryP10JavaThreadP6Thread + 0x7e 0x00007fc87c11ce6e _ZN10JavaThread17thread_main_innerEv + 0x18e 0x00007fc87c11d0ef _ZN10JavaThread3runEv + 0x23f 0x00007fc87bf154c2 _ZL10java_startP6Thread + 0x132 Locked ownable synchronizers: - None ----------------- 10910 ----------------- 0x00007fc87d037d84 __pthread_cond_wait + 0xc4 0x00007fc87beb9657 _ZN7Monitor5IWaitEP6Threadl + 0x127 0x00007fc87bebbaf9 _ZN7Monitor4waitEblb + 0x319 0x00007fc87b951467 _ZN12CompileQueue3getEv + 0x107 0x00007fc87b957074 _ZN13CompileBroker20compiler_thread_loopEv + 0x274 0x00007fc87c11ce6e _ZN10JavaThread17thread_main_innerEv + 0x18e 0x00007fc87c11d0ef _ZN10JavaThread3runEv + 0x23f 0x00007fc87bf154c2 _ZL10java_startP6Thread + 0x132 Locked ownable synchronizers: - None ----------------- 10911 ----------------- 0x00007fc87d037d84 __pthread_cond_wait + 0xc4 0x00007fc87beb9657 _ZN7Monitor5IWaitEP6Threadl + 0x127 0x00007fc87bebbaf9 _ZN7Monitor4waitEblb + 0x319 0x00007fc87b951467 _ZN12CompileQueue3getEv + 0x107 0x00007fc87b957074 _ZN13CompileBroker20compiler_thread_loopEv + 0x274 0x00007fc87c11ce6e _ZN10JavaThread17thread_main_innerEv + 0x18e 0x00007fc87c11d0ef _ZN10JavaThread3runEv + 0x23f 0x00007fc87bf154c2 _ZL10java_startP6Thread + 0x132 Locked ownable synchronizers: - None ----------------- 10907 ----------------- 0x00007fc87d037d84 __pthread_cond_wait + 0xc4 0x00007fc87befcae5 _ZN13ObjectMonitor4waitElbP6Thread + 0xb75 0x00007fc87bc72db0 JVM_MonitorWait + 0x1b0 0x00007fc86e023d42 * java.lang.Object.wait(long) bci:0 Method*:0x00007fc879793c60 (Interpreted frame) 0x00007fc86e006278 * java.lang.Object.wait() bci:2 line:502 Method*:0x00007fc879793e50 (Interpreted frame) 0x00007fc86e006278 * java.lang.ref.Reference$ReferenceHandler.run() bci:36 line:142 Method*:0x00007fc87984a5d0 (Interpreted frame) 0x00007fc86e000681 0x00007fc87bbef138 _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread + 0x1b18 0x00007fc87bbeb64f _ZN9JavaCalls12call_virtualEP9JavaValue11KlassHandleP6SymbolS4_P17JavaCallArgumentsP6Thread + 0x5cf 0x00007fc87bbebe7a _ZN9JavaCalls12call_virtualEP9JavaValue6Handle11KlassHandleP6SymbolS5_P6Thread + 0x5a 0x00007fc87bc6f92e _ZL12thread_entryP10JavaThreadP6Thread + 0x7e 0x00007fc87c11ce6e _ZN10JavaThread17thread_main_innerEv + 0x18e 0x00007fc87c11d0ef _ZN10JavaThread3runEv + 0x23f 0x00007fc87bf154c2 _ZL10java_startP6Thread + 0x132 Locked ownable synchronizers: - None ----------------- 10905 ----------------- 0x00007fc87d037d84 __pthread_cond_wait + 0xc4 0x00007fc87beb9657 _ZN7Monitor5IWaitEP6Threadl + 0x127 0x00007fc87bebb93c _ZN7Monitor4waitEblb + 0x15c 0x00007fc87bae7eb2 _ZN13GCTaskManager8get_taskEj + 0x72 0x00007fc87baeab5f _ZN12GCTaskThread3runEv + 0x25f 0x00007fc87bf154c2 _ZL10java_startP6Thread + 0x132 ----------------- 10904 ----------------- 0x00007fc87d037d84 __pthread_cond_wait + 0xc4 0x00007fc87beb9657 _ZN7Monitor5IWaitEP6Threadl + 0x127 0x00007fc87bebb93c _ZN7Monitor4waitEblb + 0x15c 0x00007fc87bae7eb2 _ZN13GCTaskManager8get_taskEj + 0x72 0x00007fc87baeab5f _ZN12GCTaskThread3runEv + 0x25f 0x00007fc87bf154c2 _ZL10java_startP6Thread + 0x132 ----------------- 10900 ----------------- 0x00007fc87d035148 pthread_join + 0xb8 0x00007fc87d448700 ???????? 0x00007fc87ce1b63a ContinueInNewThread + 0x7a 0x00007fc87ce1e240 JLI_Launch + 0x480 0x00000000004006d6 main + 0x76 ----------------- 10903 ----------------- 0x00007fc87d037d84 __pthread_cond_wait + 0xc4 0x00007fc87beb9657 _ZN7Monitor5IWaitEP6Threadl + 0x127 0x00007fc87bebb93c _ZN7Monitor4waitEblb + 0x15c 0x00007fc87bae7eb2 _ZN13GCTaskManager8get_taskEj + 0x72 0x00007fc87baeab5f _ZN12GCTaskThread3runEv + 0x25f 0x00007fc87bf154c2 _ZL10java_startP6Thread + 0x132 ----------------- 10902 ----------------- 0x00007fc87d037d84 __pthread_cond_wait + 0xc4 0x00007fc87beb9657 _ZN7Monitor5IWaitEP6Threadl + 0x127 0x00007fc87bebb93c _ZN7Monitor4waitEblb + 0x15c 0x00007fc87bae7eb2 _ZN13GCTaskManager8get_taskEj + 0x72 0x00007fc87baeab5f _ZN12GCTaskThread3runEv + 0x25f 0x00007fc87bf154c2 _ZL10java_startP6Thread + 0x132 ----------------- 10913 ----------------- 0x00007fc87d037d84 __pthread_cond_wait + 0xc4 0x00007fc87beb9657 _ZN7Monitor5IWaitEP6Threadl + 0x127 0x00007fc87bebb93c _ZN7Monitor4waitEblb + 0x15c 0x00007fc87c021ba5 _ZN13ServiceThread20service_thread_entryEP10JavaThreadP6Thread + 0x275 0x00007fc87c11ce6e _ZN10JavaThread17thread_main_innerEv + 0x18e 0x00007fc87c11d0ef _ZN10JavaThread3runEv + 0x23f 0x00007fc87bf154c2 _ZL10java_startP6Thread + 0x132 Locked ownable synchronizers: - None ----------------- 10901 ----------------- 0x00007fc87c888425 gsignal + 0x35 0x00007fc87c18c7c0 _ZN7VMError14report_and_dieEv + 0x750 0x00007fc87b9ceecc _Z15report_vm_errorPKciS0_S0_ + 0x7c 0x00007fc87bd92269 _ZN8CallInfo10set_handleE12methodHandle6HandleS1_P6Thread.constprop.146 + 0x89 0x00007fc87bd92585 _ZN12LinkResolver19resolve_handle_callER8CallInfo11KlassHandleP6SymbolS4_S2_P6Thread + 0x155 0x00007fc87bd926f6 _ZN12LinkResolver20resolve_invokehandleER8CallInfo18constantPoolHandleiP6Thread + 0x126 0x00007fc87bd996b4 _ZN12LinkResolver14resolve_invokeER8CallInfo6Handle18constantPoolHandleiN9Bytecodes4CodeEP6Thread + 0x154 0x00007fc87bbe1d26 _ZN18InterpreterRuntime20resolve_invokehandleEP10JavaThread + 0x226 0x00007fc86e043475 * Test6990212.main(java.lang.String[]) bci:26 line:50 Method*:0x00007fc879b937b0 (Interpreted frame) 0x00007fc86e000681 0x00007fc87bbef138 _ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread + 0x1b18 0x00007fc87bc3e99e _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread.isra.188.constprop.193 + 0x70e 0x00007fc87bc443a4 jni_CallStaticVoidMethod + 0x1b4 0x00007fc87ce1c7e4 JavaMain + 0x844 Locked ownable synchronizers: - None From aleksey.shipilev at oracle.com Mon Jan 21 10:55:53 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 21 Jan 2013 22:55:53 +0400 Subject: Request for review (XS): JDK-8006641: JDK-8003985 broke InstanceKlass.getFieldOffset() in SA In-Reply-To: <50FD8C4A.7040607@oracle.com> References: <50FD8C4A.7040607@oracle.com> Message-ID: <50FD8F39.3090103@oracle.com> Hi Krystal, On 01/21/2013 10:43 PM, Krystal Mo wrote: > Could someone review this small patch, please? > JDK-8006641: JDK-8003985 broke InstanceKlass.getFieldOffset() in SA This is the duplicate for https://jbs.oracle.com/bugs/browse/JDK-8006403 ...which was already fixed: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e94ed1591b42 -Aleksey. From lance.andersen at oracle.com Mon Jan 21 11:09:16 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Mon, 21 Jan 2013 19:09:16 +0000 Subject: hg: jdk8/tl/jdk: 8006642: Fix javadoc warnings due to Integer.MAX_VALUE Message-ID: <20130121190938.951684742F@hg.openjdk.java.net> Changeset: de30e46250c5 Author: lancea Date: 2013-01-21 14:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de30e46250c5 8006642: Fix javadoc warnings due to Integer.MAX_VALUE Reviewed-by: alanb ! src/share/classes/java/sql/BatchUpdateException.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/Statement.java From lana.steuck at oracle.com Mon Jan 21 11:22:20 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:20 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130121192237.0070A47433@hg.openjdk.java.net> Changeset: 56c97aff46bb Author: katleman Date: 2013-01-16 12:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/56c97aff46bb Added tag jdk8-b73 for changeset 8d0baee36c71 ! .hgtags Changeset: b450959b42ff Author: lana Date: 2013-01-20 23:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b450959b42ff Merge Changeset: 1985e35e97b2 Author: lana Date: 2013-01-21 11:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1985e35e97b2 Merge From lana.steuck at oracle.com Mon Jan 21 11:22:13 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:13 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b73 for changeset 191afde59e7b Message-ID: <20130121192216.0181147430@hg.openjdk.java.net> Changeset: 2132845cf5f7 Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2132845cf5f7 Added tag jdk8-b73 for changeset 191afde59e7b ! .hgtags From lana.steuck at oracle.com Mon Jan 21 11:22:13 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:13 +0000 Subject: hg: jdk8/tl: 28 new changesets Message-ID: <20130121192216.AFCED47431@hg.openjdk.java.net> Changeset: 4090847a5444 Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4090847a5444 Added tag jdk8-b73 for changeset 93b9664f97ee ! .hgtags Changeset: 77f062a41850 Author: erikj Date: 2012-12-27 20:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/77f062a41850 8001942: build-infra: General permission problems on Windows/cygwin Summary: Added sanity check for file permissions in configure Reviewed-by: tbell, ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: d2c1f80118de Author: erikj Date: 2012-12-27 20:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d2c1f80118de 8005540: build-infra: Improve incremental build speed on windows by caching find results Reviewed-by: ohair ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/NativeCompilation.gmk Changeset: d5f3a6f60d51 Author: erikj Date: 2012-12-27 20:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d5f3a6f60d51 8005548: build-infra: Fix docs target on windows Summary: Fix path sep variable Reviewed-by: tbell ! common/makefiles/javadoc/Javadoc.gmk Changeset: ef6adbf511cc Author: erikj Date: 2012-12-28 09:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ef6adbf511cc 8005549: build-infra: Merge NewMakefile.gmk and common/makefiles/Makefile Reviewed-by: ohair, tbell ! NewMakefile.gmk ! common/autoconf/Makefile.in ! common/autoconf/generated-configure.sh + common/makefiles/Jprt.gmk ! common/makefiles/Main.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/Makefile Changeset: 2d9bb72b4e34 Author: erikj Date: 2012-12-30 12:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2d9bb72b4e34 8004490: build-infra: mac: hotspot is always built in product, regardless of --with-debug-level setting Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: abc8078e070b Author: erikj Date: 2013-01-01 14:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/abc8078e070b 8001895: build-infra: Make JDK_BUILD_NUMBER and MILESTONE customizable Summary: Added configure params Reviewed-by: ohair ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/version.numbers Changeset: 14d7ebe42c8d Author: erikj Date: 2013-01-02 11:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/14d7ebe42c8d 8005347: build-infra: Verify 'gnumake source' at the top level works ok Reviewed-by: tbell, ohair, dholmes ! common/autoconf/basics.m4 - common/autoconf/closed.version.numbers ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in = common/autoconf/version-numbers < common/autoconf/version.numbers Changeset: 348a881c6da0 Author: erikj Date: 2013-01-02 15:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/348a881c6da0 8005355: build-infra: Java security signing (need a top-level make target). Reviewed-by: tbell, ohair ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: befbad2e4d87 Author: erikj Date: 2013-01-03 20:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/befbad2e4d87 8005635: build-infra: Support building install in jprt Reviewed-by: ohair Contributed-by: tim.bell at oracle.com, erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl ! common/makefiles/Jprt.gmk ! common/src/fixpath.c Changeset: 39194e004ade Author: erikj Date: 2013-01-04 11:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/39194e004ade 8005575: build-infra: Three JCK tests fails on Solaris with new RE Autoconf-Based build Reviewed-by: ohair ! common/autoconf/compare.sh.in ! common/bin/compare.sh Changeset: 9263657c2756 Author: erikj Date: 2013-01-04 16:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9263657c2756 8005692: build-infra: Target "all" should do the right thing Reviewed-by: tbell ! common/makefiles/Main.gmk Changeset: c874a8a27933 Author: erikj Date: 2013-01-04 17:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c874a8a27933 8005597: build-infra: bridgeBuild broken for pure openjdk build Reviewed-by: tbell ! common/makefiles/Jprt.gmk Changeset: 7b9c42f14281 Author: erikj Date: 2013-01-04 17:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7b9c42f14281 8005654: build-infra: Create sec-bin.zip Reviewed-by: tbell ! common/bin/compare.sh ! common/makefiles/JavaCompilation.gmk Changeset: 2597feac57c0 Author: erikj Date: 2013-01-04 22:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2597feac57c0 8005723: build-infra: in new infra build, sec-windows-bin-zip and jgss-windows-*-bin.zip are missing Reviewed-by: tbell ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl Changeset: 5cf7750c8c43 Author: ohair Date: 2013-01-04 21:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5cf7750c8c43 8004229: build-infra: Umbrella for switch of default "make" to new makefiles Reviewed-by: erikj, tbell ! Makefile ! make/jprt.properties Changeset: 7a3c6ffdf1fb Author: tbell Date: 2013-01-07 14:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7a3c6ffdf1fb 8005442: autogen.sh sets DATE_WHEN_GENERATED to empty string on Solaris version 11 or later Reviewed-by: ohair ! common/autoconf/autogen.sh Changeset: 64a9ebad39fe Author: katleman Date: 2013-01-08 13:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/64a9ebad39fe Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers Changeset: b284980b7d9a Author: tbell Date: 2013-01-08 16:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b284980b7d9a 8005794: in new infra, how do we change java -version? Summary: Added configure parameter --with-user-release-suffix Reviewed-by: ohair, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: db3984e4eb97 Author: erikj Date: 2013-01-10 12:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/db3984e4eb97 8005858: build-infra: Add missed comparison of sec-windows-bin.zip and friends to compare.sh Reviewed-by: tbell, ohair ! common/bin/compare.sh Changeset: 6f8f7a5449f6 Author: erikj Date: 2013-01-11 10:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6f8f7a5449f6 8005850: build-infra: Make --enable-openjdk-only really disable custom Reviewed-by: ohair, dholmes ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: b66c81dfa291 Author: ohair Date: 2013-01-14 16:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b66c81dfa291 8005284: build-infra: nonstandard copyright headers under common/autoconf/build-aux Reviewed-by: katleman ! common/autoconf/build-aux/autoconf-config.guess ! common/autoconf/build-aux/config.sub ! common/autoconf/build-aux/pkg.m4 Changeset: 3540aa40c868 Author: erikj Date: 2013-01-14 13:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3540aa40c868 8006074: build-infra: Configure fails to find SetEnv.Cmd in microsoft sdk Reviewed-by: tbell, ohair ! common/autoconf/basics_windows.m4 ! common/autoconf/generated-configure.sh Changeset: 6e822b534678 Author: erikj Date: 2013-01-14 15:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6e822b534678 8006100: build-infra: Bundle up the correct images in jprt Reviewed-by: tbell ! NewMakefile.gmk ! common/makefiles/Jprt.gmk Changeset: 52cce3326649 Author: erikj Date: 2013-01-15 09:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/52cce3326649 Merge Changeset: fe1c94aca5a8 Author: katleman Date: 2013-01-15 10:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fe1c94aca5a8 Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers Changeset: dc84b505b408 Author: katleman Date: 2013-01-16 22:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dc84b505b408 Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers ! common/bin/compare_exceptions.sh.incl Changeset: 2e12a508d7ae Author: lana Date: 2013-01-20 23:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2e12a508d7ae Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers ! common/makefiles/javadoc/Javadoc.gmk From lana.steuck at oracle.com Mon Jan 21 11:22:19 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:19 +0000 Subject: hg: jdk8/tl/hotspot: 2 new changesets Message-ID: <20130121192230.9073F47432@hg.openjdk.java.net> Changeset: 41ccb2e737fb Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/41ccb2e737fb Added tag jdk8-b73 for changeset 11619f33cd68 ! .hgtags Changeset: 1a3e54283c54 Author: katleman Date: 2013-01-16 20:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a3e54283c54 Merge ! .hgtags From lana.steuck at oracle.com Mon Jan 21 11:22:16 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:16 +0000 Subject: hg: jdk8/tl/jaxp: 6 new changesets Message-ID: <20130121192241.8359D47435@hg.openjdk.java.net> Changeset: cf0917c0d771 Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cf0917c0d771 Added tag jdk8-b73 for changeset 84946404d1e1 ! .hgtags Changeset: 278a2f60c55b Author: erikj Date: 2013-01-04 11:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/278a2f60c55b 8005575: build-infra: Three JCK tests fails on Solaris with new RE Autoconf-Based build Reviewed-by: ohair ! makefiles/BuildJaxp.gmk Changeset: 2e4d87e6662e Author: katleman Date: 2013-01-08 13:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2e4d87e6662e Merge Changeset: a317d3e1bbac Author: katleman Date: 2013-01-15 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a317d3e1bbac Merge Changeset: 2087e24a4357 Author: katleman Date: 2013-01-16 22:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2087e24a4357 Merge Changeset: 4e049aa2495f Author: lana Date: 2013-01-20 23:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4e049aa2495f Merge From lana.steuck at oracle.com Mon Jan 21 11:22:24 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:24 +0000 Subject: hg: jdk8/tl/jaxws: 5 new changesets Message-ID: <20130121192241.2371647434@hg.openjdk.java.net> Changeset: 68f508979ffe Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/68f508979ffe Added tag jdk8-b73 for changeset c606f644a5d9 ! .hgtags Changeset: 51f3117e2b75 Author: erikj Date: 2013-01-04 11:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/51f3117e2b75 8005575: build-infra: Three JCK tests fails on Solaris with new RE Autoconf-Based build Reviewed-by: ohair ! makefiles/BuildJaxws.gmk Changeset: dd7473082690 Author: katleman Date: 2013-01-08 13:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/dd7473082690 Merge Changeset: b8fd32e44c26 Author: katleman Date: 2013-01-15 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b8fd32e44c26 Merge Changeset: 12db3c5a3393 Author: katleman Date: 2013-01-16 22:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/12db3c5a3393 Merge From lana.steuck at oracle.com Mon Jan 21 11:22:51 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:51 +0000 Subject: hg: jdk8/tl/jdk: 18 new changesets Message-ID: <20130121192706.4089847436@hg.openjdk.java.net> Changeset: 965e89e2abd3 Author: katleman Date: 2013-01-16 12:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/965e89e2abd3 Added tag jdk8-b73 for changeset 733885f57e14 ! .hgtags Changeset: e91caf05f441 Author: erikj Date: 2012-12-27 20:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e91caf05f441 8005540: build-infra: Improve incremental build speed on windows by caching find results Reviewed-by: ohair ! makefiles/BuildJdk.gmk ! makefiles/CompileDemos.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Tools.gmk Changeset: 368fa50469da Author: erikj Date: 2012-12-28 09:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/368fa50469da 8005549: build-infra: Merge NewMakefile.gmk and common/makefiles/Makefile Reviewed-by: ohair, tbell ! makefiles/BuildJdk.gmk Changeset: 461b069100fa Author: erikj Date: 2013-01-02 15:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/461b069100fa 8005355: build-infra: Java security signing (need a top-level make target). Reviewed-by: tbell, ohair ! makefiles/BuildJdk.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk + makefiles/SignJars.gmk Changeset: 3841da683703 Author: erikj Date: 2013-01-03 20:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3841da683703 8005635: build-infra: Support building install in jprt Reviewed-by: ohair Contributed-by: tim.bell at oracle.com, erik.joelsson at oracle.com ! make/common/shared/Defs-windows.gmk ! makefiles/BuildJdk.gmk ! makefiles/Bundles.gmk ! makefiles/Images.gmk ! makefiles/Tools.gmk Changeset: a8d25b689563 Author: erikj Date: 2013-01-04 16:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8d25b689563 8005694: build-infra: Cleanup of misc changes in build-infra Reviewed-by: tbell ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk Changeset: 3824d8469dcf Author: erikj Date: 2013-01-04 17:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3824d8469dcf 8005654: build-infra: Create sec-bin.zip Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: d98e73b7bc78 Author: erikj Date: 2013-01-04 22:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d98e73b7bc78 8005723: build-infra: in new infra build, sec-windows-bin-zip and jgss-windows-*-bin.zip are missing Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: 244e481f538b Author: katleman Date: 2013-01-08 13:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/244e481f538b Merge ! makefiles/CreateJars.gmk Changeset: 1868bde529b8 Author: ohrstrom Date: 2013-01-09 13:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1868bde529b8 8005096: Move a few source files in swing/beaninfo and in a demo. Reviewed-by: ohair, erikj, malenkov ! make/javax/swing/beaninfo/SwingBeans.gmk - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java + make/tools/swing-beans/javax/swing/SwingBeanInfoBase.java + make/tools/swing-beans/sun/swing/BeanInfoUtils.java ! makefiles/CompileJavaClasses.gmk ! makefiles/GensrcSwing.gmk - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java + src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethod.java + src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethodDescriptor.java Changeset: 2cc29d0b9eaf Author: erikj Date: 2013-01-09 16:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cc29d0b9eaf 8005903: build-infra: bad symlink: j2sdk-bundle/jdk1.8.0.jdk/Contents/MacOS/libjli.dylib Reviewed-by: tbell ! makefiles/Bundles.gmk Changeset: f92ab6dbbff8 Author: erikj Date: 2013-01-10 12:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f92ab6dbbff8 8005856: build-infra: Remove special handling of base module classes header generation Reviewed-by: alanb, tbell, ohair Contributed-by: fredrik.ohrstrom at oracle.com ! makefiles/CompileJavaClasses.gmk ! src/share/classes/java/io/FileSystem.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/net/SocketOptions.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/windows/classes/sun/nio/ch/PollArrayWrapper.java Changeset: 4d80ab394efa Author: erikj Date: 2013-01-15 16:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d80ab394efa 8006296: build-infra: Unsigned sunmscapi.jar is missing manifest. Reviewed-by: alanb, tbell ! makefiles/CreateJars.gmk Changeset: 6d1a3d43851d Author: katleman Date: 2013-01-15 10:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d1a3d43851d Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: 3eef1e0540c4 Author: erikj Date: 2013-01-16 16:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3eef1e0540c4 8006385: build-infra: linux and solaris *-debuginfo-*.zip file created from the new makefile has extra HUDSON direcotry in jre/lib/i386/server Reviewed-by: tbell ! makefiles/Import.gmk Changeset: 54bbeb149525 Author: katleman Date: 2013-01-16 22:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54bbeb149525 Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk ! src/share/classes/java/lang/Integer.java - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: 8b1857409159 Author: lana Date: 2013-01-20 23:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b1857409159 Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: 7f4e3da76ec1 Author: lana Date: 2013-01-21 11:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f4e3da76ec1 Merge From maurizio.cimadamore at oracle.com Mon Jan 21 12:21:51 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 21 Jan 2013 20:21:51 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20130121202204.8A33747438@hg.openjdk.java.net> Changeset: 7873d37f5b37 Author: mcimadamore Date: 2013-01-21 20:13 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7873d37f5b37 8005244: Implement overload resolution as per latest spec EDR Summary: Add support for stuck expressions and provisional applicability Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CyclicInference.java - test/tools/javac/diags/examples/InferredDoNotConformToLower.java - test/tools/javac/diags/examples/NoUniqueMaximalInstance.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/generics/diamond/T6939780.out ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg10.java ! test/tools/javac/generics/diamond/neg/Neg10.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/lambda/MethodReference25.java + test/tools/javac/lambda/MethodReference25.out ! test/tools/javac/lambda/MethodReference26.java - test/tools/javac/lambda/MethodReference26.out ! test/tools/javac/lambda/MethodReference43.java ! test/tools/javac/lambda/TargetType01.java + test/tools/javac/lambda/TargetType01.out ! test/tools/javac/lambda/TargetType06.java - test/tools/javac/lambda/TargetType06.out ! test/tools/javac/lambda/TargetType10.out ! test/tools/javac/lambda/TargetType11.java - test/tools/javac/lambda/TargetType11.out ! test/tools/javac/lambda/TargetType14.out ! test/tools/javac/lambda/TargetType21.java ! test/tools/javac/lambda/TargetType21.out ! test/tools/javac/lambda/TargetType26.out ! test/tools/javac/lambda/TargetType27.out ! test/tools/javac/lambda/TargetType28.out ! test/tools/javac/lambda/TargetType39.out ! test/tools/javac/lambda/TargetType45.java - test/tools/javac/lambda/TargetType45.out ! test/tools/javac/lambda/TargetType50.out + test/tools/javac/lambda/TargetType51.java + test/tools/javac/lambda/TargetType52.java + test/tools/javac/lambda/TargetType52.out ! test/tools/javac/lambda/VoidCompatibility.java - test/tools/javac/lambda/VoidCompatibility.out ! test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReference/SamConversionComboTest.java ! test/tools/javac/lambda/typeInference/InferenceTest_neg5.out ! test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java Changeset: c7c41a044e7c Author: mcimadamore Date: 2013-01-21 20:14 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c7c41a044e7c 8006566: Remove transient lambda-related guards from JavacParser Summary: Remove transitional internal flag for allowing intersection types in cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/cast/intersection/IntersectionTypeParserTest.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java ! test/tools/javac/lambda/Intersection01.java ! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java Changeset: b12ffdfa1341 Author: mcimadamore Date: 2013-01-21 20:15 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b12ffdfa1341 8005851: Remove support for synchronized interface methods Summary: Synchronized default methods are no longer supported Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java Changeset: cf84b07a82db Author: mcimadamore Date: 2013-01-21 20:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cf84b07a82db 8005166: Add support for static interface methods Summary: Support public static interface methods Reviewed-by: jjg ! 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/Symbol.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/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/static/Static01.java + test/tools/javac/defaultMethods/static/Static02.java + test/tools/javac/defaultMethods/static/Static02.out + test/tools/javac/defaultMethods/static/hiding/InterfaceMethodHidingTest.java + test/tools/javac/defaultMethods/static/import/StaticImport1.java + test/tools/javac/defaultMethods/static/import/StaticImport2.java + test/tools/javac/defaultMethods/static/import/StaticImport2.out + test/tools/javac/defaultMethods/static/import/StaticImport3.java + test/tools/javac/defaultMethods/static/import/StaticImport3.out + test/tools/javac/defaultMethods/static/import/pkg/A.java + test/tools/javac/defaultMethods/static/import/pkg/B.java + test/tools/javac/defaultMethods/static/import/pkg/C.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java + test/tools/javac/diags/examples/IllegalStaticIntfMethCall.java + test/tools/javac/diags/examples/StaticIntfMethodNotSupported.java From david.holmes at oracle.com Mon Jan 21 14:33:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Jan 2013 08:33:32 +1000 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> <50FCA114.7030908@oracle.com> Message-ID: <50FDC23C.1040204@oracle.com> On 22/01/2013 12:09 AM, Rickard B?ckman wrote: > Yes, that code has changed. Checked in to hs24. Okay but this is a review for hs25 ;-) So I assume that change will be there "real soon now". :) David > /R > > 21 jan 2013 kl. 02:59 skrev David Holmes: > >> On 18/01/2013 11:45 PM, Rickard B?ckman wrote: >>> Aleksey, >>> >>> thanks for your review! >>> >>> a) It was before on of my own changes used in os_solaris.cpp (I think, for synchronization support for Suspend/Resume). >>> I don't think we wanted something external to mess with that lock. >> >> Seems to be used here: >> >> ./os/solaris/vm/os_solaris.cpp: >> >> 4265 GetThreadPC_Callback cb(ProfileVM_lock); >> >> Is this code already undergoing removal as part of the JFR changes? >> >> Thanks, >> David >> ----- >> >> >>> b) I've changed the indentation slightly. >>> Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) >>> >>> /R >>> >>> On Jan 18, 2013, at 2:12 PM, Aleksey Shipilev wrote: >>> >>>> On 01/18/2013 04:58 PM, Rickard B?ckman wrote: >>>>> http://cr.openjdk.java.net/~rbackman/8006563/ >>>> >>>> Looks good to me (not a Reviewer), modulo: >>>> a) Are we sure this thing is not acquired in some weird way, i.e. >>>> through JVMTI, SA, or whatnot? >>>> b) The formatting of the predicate does not follow it's structure, I >>>> think it should be: >>>> ... >>>> this != Interrupt_lock&& >>>> !(this == Safepoint_lock&& >>>> contains(locks, Terminator_lock)&& >>>> SafepointSynchronize::is_synchronizing())) { >>>> >>>> This way it is more obvious SafepointSynchronize::is_synchronizing()) is >>>> the !(...) group. >>>> >>>> -Aleksey. >>> From karen.kinnear at oracle.com Mon Jan 21 15:45:15 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Mon, 21 Jan 2013 23:45:15 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 63 new changesets Message-ID: <20130121234723.4235247443@hg.openjdk.java.net> Changeset: e51c9860cf66 Author: jmasa Date: 2012-12-03 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e51c9860cf66 8005082: NPG: Add specialized Metachunk sizes for reflection and anonymous classloaders Reviewed-by: johnc, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/globals.hpp Changeset: 1de1b145f6bc Author: jmasa Date: 2012-12-26 15:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1de1b145f6bc 8005486: NPG: Incorrect assertion in ChunkManager::list_index() Reviewed-by: coleenp ! src/share/vm/memory/metaspace.cpp Changeset: b735136e0d82 Author: johnc Date: 2013-01-02 11:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b735136e0d82 8004132: SerialGC: ValidateMarkSweep broken when running GCOld Summary: Remove bit-rotten ValidateMarkSweep functionality and flag. Reviewed-by: johnc, jmasa Contributed-by: tamao ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp Changeset: 37f7535e5f18 Author: johnc Date: 2012-12-21 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/37f7535e5f18 8001424: G1: Rename certain G1-specific flags Summary: Rename G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, and G1OldCSetRegionLiveThresholdPercent to G1NewSizePercent, G1MaxNewSizePercent, and G1MixedGCLiveThresholdPercent respectively. The previous names are no longer accepted. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: d275c3dc73e6 Author: johnc Date: 2013-01-03 16:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d275c3dc73e6 8004816: G1: Kitchensink failures after marking stack changes Summary: Reset the marking state, including the mark stack overflow flag, in the event of a marking stack overflow during serial reference processing. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: ca0a78017dc7 Author: brutisso Date: 2012-12-30 08:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ca0a78017dc7 8005396: Use ParNew with only one thread instead of DefNew as default for CMS on single CPU machines Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/runtime/arguments.cpp Changeset: e0ab18eafbde Author: brutisso Date: 2013-01-04 11:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e0ab18eafbde 8003820: Deprecate untested and rarely used GC combinations Summary: Log warning messages for DefNew+CMS and ParNew+SerialOld Reviewed-by: ysr, jwilhelm, jcoomes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: c98b676a98b4 Author: brutisso Date: 2013-01-04 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c98b676a98b4 8003822: Deprecate the incremental mode of CMS Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp Changeset: 6e9174173e00 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6e9174173e00 8000325: Change default for CMSClassUnloadingEnabled to true Reviewed-by: stefank, ysr ! src/share/vm/runtime/globals.hpp Changeset: 0b54ffe4c2d3 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0b54ffe4c2d3 8005672: Clean up some changes to GC logging with GCCause's Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: 1f6d10b4cc0c Author: acorn Date: 2013-01-09 18:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1f6d10b4cc0c Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 608b2e8a0063 Author: bpittore Date: 2013-01-03 15:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/608b2e8a0063 8004051: assert(_oprs_len[mode] < maxNumberOfOperands) failed: array overflow Summary: assert is triggered when number of register based arguments passed to a java method exceeds 16. Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.hpp Changeset: 0c8717a92b2d Author: jiangli Date: 2013-01-08 13:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0c8717a92b2d 8001341: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. Summary: Use methodHandle. Reviewed-by: coleenp, acorn, twisti, sspitsyn ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 18c3c3fa291b Author: dlong Date: 2013-01-09 21:18 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/18c3c3fa291b Merge ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 4c8bf5e55392 Author: brutisso Date: 2013-01-09 09:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4c8bf5e55392 8005489: VM hangs during GC with ParallelGC and ParallelGCThreads=0 Summary: Print an error message and exit the VM if UseParallalGC is combined with ParllelGCThreads==0. Also reviewed by vitalyd at gmail.com. Reviewed-by: stefank, ehelin ! src/share/vm/runtime/arguments.cpp Changeset: b2fef6b220e9 Author: jmasa Date: 2013-01-10 07:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b2fef6b220e9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: d092d1b31229 Author: roland Date: 2012-12-23 17:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d092d1b31229 8005071: Incremental inlining for JSR 292 Summary: post parse inlining driven by number of live nodes. Reviewed-by: twisti, kvn, jrose ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 00af3a3a8df4 Author: kvn Date: 2013-01-03 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/00af3a3a8df4 8005522: use fast-string instructions on x86 for zeroing Summary: use 'rep stosb' instead of 'rep stosq' when fast-string operations are available. Reviewed-by: twisti, roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/memnode.cpp Changeset: e2e6bf86682c Author: kvn Date: 2013-01-03 16:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e2e6bf86682c 8005544: Use 256bit YMM registers in arraycopy stubs on x86 Summary: Use YMM registers in arraycopy and array_fill stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: ffa87474d7a4 Author: twisti Date: 2013-01-07 14:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ffa87474d7a4 8004537: replace AbstractAssembler emit_long with emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.hpp Changeset: 038dd2875b94 Author: kvn Date: 2013-01-08 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/038dd2875b94 8005419: Improve intrinsics code performance on x86 by using AVX2 Summary: use 256bit vpxor,vptest instructions in String.compareTo() and equals() intrinsics. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp + test/compiler/8005419/Test8005419.java Changeset: 5698813d45eb Author: twisti Date: 2013-01-09 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5698813d45eb 8005418: JSR 292: virtual dispatch bug in 292 impl Reviewed-by: jrose, kvn ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: f1c06dcee0b5 Author: kvn Date: 2013-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f1c06dcee0b5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 79f492f184d0 Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/79f492f184d0 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciField.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstance.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMetadata.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/BitData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/RetData.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallDynamicJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java ! agent/src/share/classes/sun/jvm/hotspot/opto/HaltNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java ! agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java ! agent/src/share/classes/sun/jvm/hotspot/opto/LoopNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachIfNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachReturnNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachSafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MultiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Phase.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseRegAlloc.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/ProjNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RegionNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RootNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/SafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/TypeNode.java ! agent/src/share/classes/sun/jvm/hotspot/prims/JvmtiExport.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GrowableArray.java ! agent/src/share/native/sadis.c ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/runtime/os_ext.hpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! test/runtime/7158804/Test7158804.sh Changeset: e94068d4ff52 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e94068d4ff52 Merge ! src/share/vm/classfile/classLoaderData.hpp Changeset: 0847210f8548 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0847210f8548 Added tag jdk8-b70 for changeset e94068d4ff52 ! .hgtags Changeset: d5cb5830f570 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d5cb5830f570 Added tag jdk8-b71 for changeset 0847210f8548 ! .hgtags Changeset: 11619f33cd68 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/11619f33cd68 Added tag jdk8-b72 for changeset d5cb5830f570 ! .hgtags Changeset: 1e129851479e Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1e129851479e Merge Changeset: b5e6bec76f4a Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b5e6bec76f4a Added tag hs25-b15 for changeset 1e129851479e ! .hgtags Changeset: d58b7b43031b Author: amurillo Date: 2013-01-11 02:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d58b7b43031b 8006034: new hotspot build - hs25-b16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 92d4b5d8dde4 Author: acorn Date: 2013-01-16 18:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/92d4b5d8dde4 Merge ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 337e1dd9d902 Author: jiangli Date: 2013-01-11 16:55 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/337e1dd9d902 8005895: Inefficient InstanceKlass field packing wasts memory. Summary: Pack _misc_has_default_methods into the _misc_flags, move _idnum_allocated_count. Reviewed-by: coleenp, shade ! src/share/vm/oops/instanceKlass.hpp Changeset: 94fa3c4e7643 Author: vladidan Date: 2013-01-14 13:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/94fa3c4e7643 8005639: Move InlineSynchronizedMethods flag from develop to product Summary: Move InlineSynchronizedMethods flag from develop to product Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/c1/c1_globals.hpp Changeset: 9deda4d8e126 Author: vladidan Date: 2013-01-14 13:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9deda4d8e126 8005204: Code Cache Reduction: command line options implementation Summary: Adding more detailed output on CodeCache usage Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 212c5b9c38e7 Author: dlong Date: 2013-01-17 01:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/212c5b9c38e7 Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: a3f92e6c0274 Author: twisti Date: 2013-01-11 14:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a3f92e6c0274 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: f9bda35f4226 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9bda35f4226 8005816: Shark: fix volatile float field access Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkBlock.cpp Changeset: c566b81b3323 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c566b81b3323 8005817: Shark: implement deoptimization support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: c095a7f289aa Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c095a7f289aa 8005818: Shark: fix OSR for non-empty incoming stack Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkInvariants.hpp Changeset: 606eada1bf86 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/606eada1bf86 8005820: Shark: enable JSR292 support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 6d1f5516534e Author: twisti Date: 2013-01-11 20:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6d1f5516534e 8006127: remove printing code added with 8006031 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: d92fa52a5d03 Author: vlivanov Date: 2013-01-14 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d92fa52a5d03 8006095: C1: SIGSEGV w/ -XX:+LogCompilation Summary: avoid printing inlining decision when compilation fails Reviewed-by: kvn, roland ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f1de9dbc914e Author: twisti Date: 2013-01-15 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f1de9dbc914e 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types Reviewed-by: kvn ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/opto/doCall.cpp Changeset: 5b8548391bf3 Author: kvn Date: 2013-01-15 14:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5b8548391bf3 8005821: C2: -XX:+PrintIntrinsics is broken Summary: Check all print inlining flags when processing inlining list. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! src/share/vm/opto/compile.cpp Changeset: bf623b2d5508 Author: kvn Date: 2013-01-16 14:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bf623b2d5508 8006204: please JTREGify test/compiler/7190310/Test7190310.java Summary: Add proper jtreg annotations in the preceding comment, including an explicit timeout. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! test/compiler/7190310/Test7190310.java Changeset: eab4f9ed602c Author: kvn Date: 2013-01-17 18:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/eab4f9ed602c Merge ! src/share/vm/compiler/compileBroker.cpp Changeset: 689e1218d7fe Author: brutisso Date: 2013-01-14 09:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/689e1218d7fe 8004018: Remove old initialization flags Reviewed-by: dholmes, stefank Contributed-by: erik.helin at oracle.com ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: a30e7b564541 Author: brutisso Date: 2013-01-14 21:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a30e7b564541 8005972: ParNew should not update the tenuring threshold when promotion failed has occurred Reviewed-by: ysr, johnc, jwilhelm ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp Changeset: ed6154d7d259 Author: stefank Date: 2013-01-15 13:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ed6154d7d259 8005590: java_lang_Class injected field resolved_constructor appears unused Reviewed-by: coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ff0a7943fd29 Author: stefank Date: 2013-01-15 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ff0a7943fd29 8005994: Method annotations are allocated unnecessarily during class file parsing Summary: Also reviewed by: vitalyd at gmail.com Reviewed-by: coleenp, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvm.cpp Changeset: 4967eb4f67a9 Author: johnc Date: 2013-01-15 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4967eb4f67a9 8001425: G1: Change the default values for certain G1 specific flags Summary: Changes to default and ergonomic flag values recommended by performance team. Changes were also reviewed by Monica Beckwith . Reviewed-by: brutisso, huntch ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2dce7c34c564 Author: stefank Date: 2013-01-17 11:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2dce7c34c564 8006513: Null pointer in DefaultMethods::generate_default_methods when merging annotations Reviewed-by: brutisso, jfranck ! src/share/vm/classfile/defaultMethods.cpp Changeset: 59a58e20dc60 Author: jmasa Date: 2013-01-17 19:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/59a58e20dc60 8006537: Assert when dumping archive with default methods Reviewed-by: coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/metadataFactory.hpp Changeset: f422634e5828 Author: brutisso Date: 2013-01-18 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f422634e5828 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 41ccb2e737fb Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/41ccb2e737fb Added tag jdk8-b73 for changeset 11619f33cd68 ! .hgtags Changeset: 1a3e54283c54 Author: katleman Date: 2013-01-16 20:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1a3e54283c54 Merge ! .hgtags Changeset: 70c89bd6b895 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/70c89bd6b895 Merge Changeset: 2b878edabfc0 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2b878edabfc0 Added tag hs25-b16 for changeset 70c89bd6b895 ! .hgtags Changeset: 46e60405583b Author: amurillo Date: 2013-01-18 05:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/46e60405583b 8006511: new hotspot build - hs25-b17 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 557bda927cc2 Author: sla Date: 2013-01-18 14:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/557bda927cc2 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: 617b18aadb33 Author: sla Date: 2013-01-18 19:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/617b18aadb33 Merge Changeset: c73c3f2c5b3b Author: acorn Date: 2013-01-21 16:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c73c3f2c5b3b Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/services/diagnosticArgument.cpp From krystal.mo at oracle.com Mon Jan 21 18:34:44 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Tue, 22 Jan 2013 10:34:44 +0800 Subject: Request for review (XS): JDK-8006641: JDK-8003985 broke InstanceKlass.getFieldOffset() in SA In-Reply-To: <50FD8F39.3090103@oracle.com> References: <50FD8C4A.7040607@oracle.com> <50FD8F39.3090103@oracle.com> Message-ID: <50FDFAC4.108@oracle.com> Hi Aleksey, Thanks for the info. Sorry about the fuss, but apparently that fix hasn't landed in hotspot-comp yet. I should have checked other repos first, though. JDK-8006403 should have been linked to JDK-8003985 as "related to" on JBS, that way I would have noticed the fix was in already. I've modified the bug to show that relationship. Thanks, Kris On 2013/1/22 2:55, Aleksey Shipilev wrote: > Hi Krystal, > > On 01/21/2013 10:43 PM, Krystal Mo wrote: >> Could someone review this small patch, please? >> JDK-8006641: JDK-8003985 broke InstanceKlass.getFieldOffset() in SA > This is the duplicate for > https://jbs.oracle.com/bugs/browse/JDK-8006403 > > ...which was already fixed: > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e94ed1591b42 > > -Aleksey. From stefan.karlsson at oracle.com Tue Jan 22 05:11:59 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 22 Jan 2013 14:11:59 +0100 Subject: Review Request: 8006506: Add test for redefining methods in backtraces to java/lang/instrument tests Message-ID: <50FE901F.4050806@oracle.com> http://cr.openjdk.java.net/~stefank/8006506/webrev.00/ This test provokes the JVM crash described in bug: JDK-7174978. I intend to push this to: http://hg.openjdk.java.net/jdk8/tl/jdk thanks, StefanK From stefan.karlsson at oracle.com Tue Jan 22 06:37:36 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 22 Jan 2013 15:37:36 +0100 Subject: Review Request: 8006506: Add test for redefining methods in backtraces to java/lang/instrument tests In-Reply-To: <50FE901F.4050806@oracle.com> References: <50FE901F.4050806@oracle.com> Message-ID: <50FEA430.1080001@oracle.com> http://cr.openjdk.java.net/~stefank/8006506/webrev.02 After some feedback from Alan Bateman, I've updated to how the java classes are compiled, to match the behavior of similar jtreg tests. thanks, StefanK On 01/22/2013 02:11 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8006506/webrev.00/ > > This test provokes the JVM crash described in bug: JDK-7174978. > > I intend to push this to: > http://hg.openjdk.java.net/jdk8/tl/jdk > > thanks, > StefanK > > From stefan.karlsson at oracle.com Tue Jan 22 06:39:50 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 22 Jan 2013 15:39:50 +0100 Subject: Review Request: 7140852: Add test for 7022100 Message-ID: <50FEA4B6.90507@oracle.com> http://cr.openjdk.java.net/~stefank/7140852/webrev.00/ This test provoked the bug in: 7022100: Method annotations are incorrectly set when redefining classes thanks, StefanK From maurizio.cimadamore at oracle.com Tue Jan 22 08:29:26 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 22 Jan 2013 16:29:26 +0000 Subject: hg: jdk8/tl/langtools: 8006673: TargetType52 fails because of bad golden file Message-ID: <20130122162931.87DFD47461@hg.openjdk.java.net> Changeset: be443002e970 Author: mcimadamore Date: 2013-01-22 16:23 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/be443002e970 8006673: TargetType52 fails because of bad golden file Summary: Fix golden file in negative test Reviewed-by: jjg ! test/tools/javac/lambda/TargetType52.out From maurizio.cimadamore at oracle.com Tue Jan 22 08:40:15 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 22 Jan 2013 16:40:15 +0000 Subject: hg: jdk8/tl/langtools: 8006684: Compiler produces java.lang.VerifyError: Bad type on operand stack Message-ID: <20130122164020.3A9D347463@hg.openjdk.java.net> Changeset: b61e5f801f7c Author: mcimadamore Date: 2013-01-22 16:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b61e5f801f7c 8006684: Compiler produces java.lang.VerifyError: Bad type on operand stack Summary: Lambda desugaring generates spurious references to 'this' in static contexts Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaExpr21.java From daniel.daugherty at oracle.com Tue Jan 22 10:34:59 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 22 Jan 2013 18:34:59 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20130122183508.765AC47470@hg.openjdk.java.net> Changeset: f3184f32ce0b Author: dcubed Date: 2013-01-22 05:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f3184f32ce0b 6444286: Possible naked oop related to biased locking revocation safepoint in jni_exit() Summary: Add missing Handle. Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/synchronizer.cpp Changeset: 22ba8c8ce6a6 Author: dcubed Date: 2013-01-22 05:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/22ba8c8ce6a6 8004902: correctness fixes motivated by contended locking work (6607129) Summary: misc correctness fixes Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: dave.dice at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.inline.hpp Changeset: 5ce621176715 Author: dcubed Date: 2013-01-22 05:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5ce621176715 8004903: VMThread::execute() calls Thread::check_for_valid_safepoint_state() on concurrent VM ops Summary: check_for_valid_safepoint_state() only applies to blocking VM ops Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/vmThread.cpp From vincent.x.ryan at oracle.com Tue Jan 22 15:41:13 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Tue, 22 Jan 2013 23:41:13 +0000 Subject: hg: jdk8/tl/jdk: 6263419: No way to clean the memory for a java.security.Key Message-ID: <20130122234135.62D744748F@hg.openjdk.java.net> Changeset: 8ee6d45348ba Author: vinnie Date: 2013-01-22 23:32 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8ee6d45348ba 6263419: No way to clean the memory for a java.security.Key Reviewed-by: mullan ! src/share/classes/java/security/PrivateKey.java ! src/share/classes/javax/crypto/SecretKey.java ! src/share/classes/javax/security/auth/Destroyable.java + test/javax/security/auth/Destroyable/KeyDestructionTest.java From serguei.spitsyn at oracle.com Tue Jan 22 16:07:38 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 22 Jan 2013 16:07:38 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <50F71FB2.4020702@oracle.com> References: <50F71FB2.4020702@oracle.com> Message-ID: <50FF29CA.9000009@oracle.com> Please, review the fix for: https://jbs.oracle.com/bugs/browse/JDK-8006542 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ Summary: Need a support for invokedynamic entry kinds when new and old constant pools are merged. Testing: vm/mlvm/indy/func/jvmti/redefineClassInBootstrap Asked the VM SQE team to develop new INDY tests for better coverage. Thanks, Serguei From stuart.marks at oracle.com Tue Jan 22 18:33:32 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Wed, 23 Jan 2013 02:33:32 +0000 Subject: hg: jdk8/tl/jdk: 8005646: TEST_BUG: java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup leaves process running Message-ID: <20130123023343.64B0D47496@hg.openjdk.java.net> Changeset: c18f28312c49 Author: smarks Date: 2013-01-22 18:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c18f28312c49 8005646: TEST_BUG: java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup leaves process running Reviewed-by: mchung ! test/java/rmi/activation/ActivationSystem/unregisterGroup/ActivateMe.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy From jonathan.gibbons at oracle.com Tue Jan 22 18:43:47 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Jan 2013 02:43:47 +0000 Subject: hg: jdk8/tl/langtools: 8006723: sjavac test fails to compile on clean build Message-ID: <20130123024349.A433C47497@hg.openjdk.java.net> Changeset: 8943b4213f59 Author: jjg Date: 2013-01-22 18:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8943b4213f59 8006723: sjavac test fails to compile on clean build Reviewed-by: ksrini ! test/tools/sjavac/SJavac.java + test/tools/sjavac/SJavacWrapper.java From jonathan.gibbons at oracle.com Tue Jan 22 19:07:23 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Jan 2013 03:07:23 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130123030731.0EB3747498@hg.openjdk.java.net> Changeset: f5b70712e0d5 Author: jjg Date: 2013-01-22 19:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f5b70712e0d5 8006728: temporarily workaround jtreg problems for doclint tests in othervm Reviewed-by: jjh + test/tools/doclint/html/AAA.java + test/tools/doclint/tidy/AAA.java + test/tools/doclint/tool/AAA.java Changeset: 385828dd5604 Author: jjg Date: 2013-01-22 19:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/385828dd5604 Merge From zhengyu.gu at oracle.com Tue Jan 22 19:16:22 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 23 Jan 2013 03:16:22 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130123031628.C4CB74749B@hg.openjdk.java.net> Changeset: edd23b35b1a5 Author: zgu Date: 2013-01-22 14:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/edd23b35b1a5 6871190: Don't terminate JVM if it is running in a non-interactive session Summary: Don't handle CTRL_LOGOFF_EVENT event when the process is running in a non-interactive session Reviewed-by: ctornqvi, acorn ! src/os/windows/vm/os_windows.cpp Changeset: 2ef7061f13b4 Author: zgu Date: 2013-01-22 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2ef7061f13b4 Merge ! src/os/windows/vm/os_windows.cpp From xueming.shen at oracle.com Tue Jan 22 20:54:43 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 23 Jan 2013 04:54:43 +0000 Subject: hg: jdk8/tl/jdk: 8003680: JSR 310 Date/Time API Message-ID: <20130123045504.5A781474A3@hg.openjdk.java.net> Changeset: 919afffa70b0 Author: sherman Date: 2013-01-22 20:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/919afffa70b0 8003680: JSR 310 Date/Time API Summary: Integration of JSR310 Date/Time API for M6 Reviewed-by: alanb, naoto, dholmes Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, richard.warburton at gmail.com, misterm at gmail.com ! make/docs/CORE_PKGS.gmk ! make/java/Makefile + make/java/time/Makefile ! make/jprt.properties ! make/sun/Makefile + make/sun/tzdb/Makefile ! make/tools/Makefile + make/tools/src/build/tools/tzdb/ChronoField.java + make/tools/src/build/tools/tzdb/DateTimeException.java + make/tools/src/build/tools/tzdb/LocalDate.java + make/tools/src/build/tools/tzdb/LocalDateTime.java + make/tools/src/build/tools/tzdb/LocalTime.java + make/tools/src/build/tools/tzdb/TimeDefinition.java + make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java + make/tools/src/build/tools/tzdb/Utils.java + make/tools/src/build/tools/tzdb/ZoneOffset.java + make/tools/src/build/tools/tzdb/ZoneOffsetTransition.java + make/tools/src/build/tools/tzdb/ZoneOffsetTransitionRule.java + make/tools/src/build/tools/tzdb/ZoneRules.java + make/tools/src/build/tools/tzdb/ZoneRulesBuilder.java + make/tools/tzdb/Makefile ! makefiles/CreateJars.gmk + makefiles/GendataTZDB.gmk ! makefiles/GenerateData.gmk ! makefiles/Tools.gmk + src/share/classes/java/time/Clock.java + src/share/classes/java/time/DateTimeException.java + src/share/classes/java/time/DayOfWeek.java + src/share/classes/java/time/Duration.java + src/share/classes/java/time/Instant.java + src/share/classes/java/time/LocalDate.java + src/share/classes/java/time/LocalDateTime.java + src/share/classes/java/time/LocalTime.java + src/share/classes/java/time/Month.java + src/share/classes/java/time/Period.java + src/share/classes/java/time/PeriodParser.java + src/share/classes/java/time/Ser.java + src/share/classes/java/time/ZoneId.java + src/share/classes/java/time/ZoneOffset.java + src/share/classes/java/time/ZoneRegion.java + src/share/classes/java/time/ZonedDateTime.java + src/share/classes/java/time/calendar/ChronoDateImpl.java + src/share/classes/java/time/calendar/HijrahChrono.java + src/share/classes/java/time/calendar/HijrahDate.java + src/share/classes/java/time/calendar/HijrahDeviationReader.java + src/share/classes/java/time/calendar/HijrahEra.java + src/share/classes/java/time/calendar/JapaneseChrono.java + src/share/classes/java/time/calendar/JapaneseDate.java + src/share/classes/java/time/calendar/JapaneseEra.java + src/share/classes/java/time/calendar/MinguoChrono.java + src/share/classes/java/time/calendar/MinguoDate.java + src/share/classes/java/time/calendar/MinguoEra.java + src/share/classes/java/time/calendar/Ser.java + src/share/classes/java/time/calendar/ThaiBuddhistChrono.java + src/share/classes/java/time/calendar/ThaiBuddhistDate.java + src/share/classes/java/time/calendar/ThaiBuddhistEra.java + src/share/classes/java/time/calendar/package-info.java + src/share/classes/java/time/format/DateTimeBuilder.java + src/share/classes/java/time/format/DateTimeFormatStyleProvider.java + src/share/classes/java/time/format/DateTimeFormatSymbols.java + src/share/classes/java/time/format/DateTimeFormatter.java + src/share/classes/java/time/format/DateTimeFormatterBuilder.java + src/share/classes/java/time/format/DateTimeFormatters.java + src/share/classes/java/time/format/DateTimeParseContext.java + src/share/classes/java/time/format/DateTimeParseException.java + src/share/classes/java/time/format/DateTimePrintContext.java + src/share/classes/java/time/format/DateTimePrintException.java + src/share/classes/java/time/format/DateTimeTextProvider.java + src/share/classes/java/time/format/FormatStyle.java + src/share/classes/java/time/format/SignStyle.java + src/share/classes/java/time/format/TextStyle.java + src/share/classes/java/time/format/package-info.java + src/share/classes/java/time/overview.html + src/share/classes/java/time/package-info.java + src/share/classes/java/time/temporal/Adjusters.java + src/share/classes/java/time/temporal/Chrono.java + src/share/classes/java/time/temporal/ChronoField.java + src/share/classes/java/time/temporal/ChronoLocalDate.java + src/share/classes/java/time/temporal/ChronoLocalDateTime.java + src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java + src/share/classes/java/time/temporal/ChronoUnit.java + src/share/classes/java/time/temporal/ChronoZonedDateTime.java + src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java + src/share/classes/java/time/temporal/Era.java + src/share/classes/java/time/temporal/ISOChrono.java + src/share/classes/java/time/temporal/ISOEra.java + src/share/classes/java/time/temporal/ISOFields.java + src/share/classes/java/time/temporal/JulianFields.java + src/share/classes/java/time/temporal/MonthDay.java + src/share/classes/java/time/temporal/OffsetDate.java + src/share/classes/java/time/temporal/OffsetDateTime.java + src/share/classes/java/time/temporal/OffsetTime.java + src/share/classes/java/time/temporal/Queries.java + src/share/classes/java/time/temporal/Ser.java + src/share/classes/java/time/temporal/SimplePeriod.java + src/share/classes/java/time/temporal/Temporal.java + src/share/classes/java/time/temporal/TemporalAccessor.java + src/share/classes/java/time/temporal/TemporalAdder.java + src/share/classes/java/time/temporal/TemporalAdjuster.java + src/share/classes/java/time/temporal/TemporalField.java + src/share/classes/java/time/temporal/TemporalQuery.java + src/share/classes/java/time/temporal/TemporalSubtractor.java + src/share/classes/java/time/temporal/TemporalUnit.java + src/share/classes/java/time/temporal/ValueRange.java + src/share/classes/java/time/temporal/WeekFields.java + src/share/classes/java/time/temporal/Year.java + src/share/classes/java/time/temporal/YearMonth.java + src/share/classes/java/time/temporal/package-info.java + src/share/classes/java/time/zone/Ser.java + src/share/classes/java/time/zone/TzdbZoneRulesProvider.java + src/share/classes/java/time/zone/ZoneOffsetTransition.java + src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java + src/share/classes/java/time/zone/ZoneRules.java + src/share/classes/java/time/zone/ZoneRulesException.java + src/share/classes/java/time/zone/ZoneRulesProvider.java + src/share/classes/java/time/zone/package-info.java ! src/share/classes/java/util/Formatter.java ! test/Makefile + test/java/time/META-INF/services/java.time.temporal.Chrono + test/java/time/TEST.properties + test/java/time/tck/java/time/AbstractDateTimeTest.java + test/java/time/tck/java/time/AbstractTCKTest.java + test/java/time/tck/java/time/TCKClock.java + test/java/time/tck/java/time/TCKClock_Fixed.java + test/java/time/tck/java/time/TCKClock_Offset.java + test/java/time/tck/java/time/TCKClock_System.java + test/java/time/tck/java/time/TCKClock_Tick.java + test/java/time/tck/java/time/TCKDayOfWeek.java + test/java/time/tck/java/time/TCKDuration.java + test/java/time/tck/java/time/TCKInstant.java + test/java/time/tck/java/time/TCKLocalDate.java + test/java/time/tck/java/time/TCKLocalDateTime.java + test/java/time/tck/java/time/TCKLocalTime.java + test/java/time/tck/java/time/TCKMonth.java + test/java/time/tck/java/time/TCKZoneId.java + test/java/time/tck/java/time/TCKZoneOffset.java + test/java/time/tck/java/time/TCKZonedDateTime.java + test/java/time/tck/java/time/calendar/CopticChrono.java + test/java/time/tck/java/time/calendar/CopticDate.java + test/java/time/tck/java/time/calendar/CopticEra.java + test/java/time/tck/java/time/calendar/TestChronoLocalDate.java + test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java + test/java/time/tck/java/time/calendar/TestHijrahChrono.java + test/java/time/tck/java/time/calendar/TestJapaneseChrono.java + test/java/time/tck/java/time/calendar/TestMinguoChrono.java + test/java/time/tck/java/time/calendar/TestServiceLoader.java + test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java + test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java + test/java/time/tck/java/time/format/TCKDateTimeFormatter.java + test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java + test/java/time/tck/java/time/format/TCKDateTimeFormatters.java + test/java/time/tck/java/time/format/TCKDateTimePrintException.java + test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java + test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java + test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java + test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java + test/java/time/tck/java/time/temporal/TCKISOFields.java + test/java/time/tck/java/time/temporal/TCKJulianFields.java + test/java/time/tck/java/time/temporal/TCKMonthDay.java + test/java/time/tck/java/time/temporal/TCKOffsetDate.java + test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java + test/java/time/tck/java/time/temporal/TCKOffsetTime.java + test/java/time/tck/java/time/temporal/TCKSimplePeriod.java + test/java/time/tck/java/time/temporal/TCKWeekFields.java + test/java/time/tck/java/time/temporal/TCKYear.java + test/java/time/tck/java/time/temporal/TCKYearMonth.java + test/java/time/tck/java/time/temporal/TestChrono.java + test/java/time/tck/java/time/temporal/TestChronoLocalDate.java + test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java + test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java + test/java/time/tck/java/time/temporal/TestISOChrono.java + test/java/time/tck/java/time/zone/TCKFixedZoneRules.java + test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java + test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java + test/java/time/tck/java/time/zone/TCKZoneRules.java + test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java + test/java/time/test/java/time/AbstractTest.java + test/java/time/test/java/time/MockSimplePeriod.java + test/java/time/test/java/time/TestClock_Fixed.java + test/java/time/test/java/time/TestClock_Offset.java + test/java/time/test/java/time/TestClock_System.java + test/java/time/test/java/time/TestClock_Tick.java + test/java/time/test/java/time/TestDuration.java + test/java/time/test/java/time/TestInstant.java + test/java/time/test/java/time/TestLocalDate.java + test/java/time/test/java/time/TestLocalDateTime.java + test/java/time/test/java/time/TestLocalTime.java + test/java/time/test/java/time/TestPeriod.java + test/java/time/test/java/time/TestPeriodParser.java + test/java/time/test/java/time/TestZoneId.java + test/java/time/test/java/time/TestZoneOffset.java + test/java/time/test/java/time/TestZonedDateTime.java + test/java/time/test/java/time/format/AbstractTestPrinterParser.java + test/java/time/test/java/time/format/MockIOExceptionAppendable.java + test/java/time/test/java/time/format/TestCharLiteralParser.java + test/java/time/test/java/time/format/TestCharLiteralPrinter.java + test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java + test/java/time/test/java/time/format/TestDateTimeFormatter.java + test/java/time/test/java/time/format/TestDateTimeFormatters.java + test/java/time/test/java/time/format/TestDateTimePrintException.java + test/java/time/test/java/time/format/TestDateTimeTextProvider.java + test/java/time/test/java/time/format/TestFractionPrinterParser.java + test/java/time/test/java/time/format/TestNumberParser.java + test/java/time/test/java/time/format/TestNumberPrinter.java + test/java/time/test/java/time/format/TestPadParserDecorator.java + test/java/time/test/java/time/format/TestPadPrinterDecorator.java + test/java/time/test/java/time/format/TestReducedParser.java + test/java/time/test/java/time/format/TestReducedPrinter.java + test/java/time/test/java/time/format/TestSettingsParser.java + test/java/time/test/java/time/format/TestStringLiteralParser.java + test/java/time/test/java/time/format/TestStringLiteralPrinter.java + test/java/time/test/java/time/format/TestTextParser.java + test/java/time/test/java/time/format/TestTextPrinter.java + test/java/time/test/java/time/format/TestZoneIdParser.java + test/java/time/test/java/time/format/TestZoneOffsetParser.java + test/java/time/test/java/time/format/TestZoneOffsetPrinter.java + test/java/time/test/java/time/format/TestZoneTextPrinterParser.java + test/java/time/test/java/time/temporal/MockFieldNoValue.java + test/java/time/test/java/time/temporal/MockFieldValue.java + test/java/time/test/java/time/temporal/TestChronoUnit.java + test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java + test/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java + test/java/time/test/java/time/temporal/TestDateTimeValueRange.java + test/java/time/test/java/time/temporal/TestISOChronoImpl.java + test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java + test/java/time/test/java/time/temporal/TestMonthDay.java + test/java/time/test/java/time/temporal/TestOffsetDate.java + test/java/time/test/java/time/temporal/TestOffsetDateTime.java + test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java + test/java/time/test/java/time/temporal/TestOffsetTime.java + test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java + test/java/time/test/java/time/temporal/TestYear.java + test/java/time/test/java/time/temporal/TestYearMonth.java + test/java/time/test/java/time/zone/TestFixedZoneRules.java + test/java/time/test/java/util/TestFormatter.java From xueming.shen at oracle.com Tue Jan 22 20:57:27 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 23 Jan 2013 04:57:27 +0000 Subject: hg: jdk8/tl: 8003680: JSR 310 Date/Time API Message-ID: <20130123045727.7D1AD474A4@hg.openjdk.java.net> Changeset: 8209c91b751d Author: sherman Date: 2013-01-22 21:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8209c91b751d 8003680: JSR 310 Date/Time API Summary: Integration of JSR310 Date/Time API for M6 Reviewed-by: alanb, naoto, dholmes Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, richard.warburton at gmail.com, misterm at gmail.com ! common/makefiles/javadoc/CORE_PKGS.gmk ! make/jprt.properties ! test/Makefile From yumin.qi at oracle.com Tue Jan 22 22:35:10 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 22 Jan 2013 22:35:10 -0800 Subject: RFR: 8003348: SA can not read core file on OS X In-Reply-To: References: <50F86BBB.8000709@oracle.com> Message-ID: <50FF849E.7030104@oracle.com> Hi, Staffan (and Serguei) Made some clean for code. 1) added mach-o file fat header parsing as you suggested. 2) modified get_real_path as you indicated it could run with jre/bin/java 3) moved output information from CommandProcessor.java to PStack.java for printing out pstack not available for Darwin. 4) code clean, file header update. Please take a look at same location. Thanks Yumin On 1/18/2013 3:58 AM, Staffan Larsen wrote: > Thanks for doing this Yumin! > > I tried to apply you patch and run it, but I can't get SA to open a core file. You can see the exception I get below. Is there some kind of setup I need to do? This is against a jvmg build of Hotspot. > > I also noticed that you forgot to update BugSpotAgent.java with the same changes as in HotspotAgent.java. This makes the jstack tool fail. > > I will look at the changes more closely. > > Thanks, > /Staffan > > > > Opening core file, please wait... > Unable to open core file > /cores/core.79028: > > Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in > remote process) > sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) > at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:385) > at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:287) > at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:146) > at sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:188) > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:55) > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > hsdb> Input stream closed. > > > On 17 jan 2013, at 22:23, Yumin Qi wrote: > >> Hi, >> >> Please review for the changes for SA to read core file on Mac OS X, this is feature is not implemented on previous releases. >> This change made for SA to work on core file on Darwin, but still some function not fixed, such as 'pstack'. This is intended to integrate into 8. >> >> http://cr.openjdk.java.net/~minqi/8003348/ >> >> Please take some time since the code change is a little bigger. >> >> Thanks very much >> Yumin From vincent.x.ryan at oracle.com Wed Jan 23 01:50:00 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 23 Jan 2013 09:50:00 +0000 Subject: hg: jdk8/tl/jdk: 8006741: javadoc cleanup for 6263419 Message-ID: <20130123095040.D74E1474C5@hg.openjdk.java.net> Changeset: 71691b9d45ab Author: vinnie Date: 2013-01-23 09:49 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71691b9d45ab 8006741: javadoc cleanup for 6263419 Reviewed-by: alanb ! src/share/classes/java/security/PrivateKey.java ! src/share/classes/javax/crypto/SecretKey.java From alexey.utkin at oracle.com Wed Jan 23 03:10:35 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Wed, 23 Jan 2013 11:10:35 +0000 Subject: hg: jdk8/tl/jdk: 6519127: user.home property not set correctly Message-ID: <20130123111048.B7CBD474C6@hg.openjdk.java.net> Changeset: 01b36b400145 Author: uta Date: 2013-01-23 15:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b36b400145 6519127: user.home property not set correctly Summary: Registry-based approach was changed to SHGetKnownFolderPath/SHGetFolderPathW Reviewed-by: alanb, anthony ! src/windows/native/java/lang/java_props_md.c From chris.hegarty at oracle.com Wed Jan 23 06:47:31 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 23 Jan 2013 14:47:31 +0000 Subject: hg: jdk8/tl/jdk: 8006669: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails on mac Message-ID: <20130123144822.C9D6A474CB@hg.openjdk.java.net> Changeset: bf2a14ebb6e9 Author: chegar Date: 2013-01-23 14:45 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf2a14ebb6e9 8006669: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails on mac Reviewed-by: alanb ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java From maurizio.cimadamore at oracle.com Wed Jan 23 07:08:44 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 23 Jan 2013 15:08:44 +0000 Subject: hg: jdk8/tl/langtools: 8006692: jdk/test/java/util/Collections/BigBinarySearch.java fails to compile Message-ID: <20130123150849.81DF2474CD@hg.openjdk.java.net> Changeset: 97bd5e7151bc Author: mcimadamore Date: 2013-01-23 15:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/97bd5e7151bc 8006692: jdk/test/java/util/Collections/BigBinarySearch.java fails to compile Summary: Missing boxing cause spurious inference failure Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8006692/T8006692.java From alan.bateman at oracle.com Wed Jan 23 07:14:46 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 23 Jan 2013 15:14:46 +0000 Subject: hg: jdk8/tl/jdk: 8006764: FunctionalInterface missing from rt.jar (old build) Message-ID: <20130123151511.AFF7C474CE@hg.openjdk.java.net> Changeset: 53064bbaeec5 Author: alanb Date: 2013-01-23 15:12 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53064bbaeec5 8006764: FunctionalInterface missing from rt.jar (old build) Reviewed-by: lancea, forax ! make/java/java/FILES_java.gmk From rob.mckenna at oracle.com Wed Jan 23 10:00:35 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Wed, 23 Jan 2013 18:00:35 +0000 Subject: hg: jdk8/tl/jdk: 8004729: Add java.lang.reflect.Parameter and related changes for parameter reflection Message-ID: <20130123180114.08DA3474D4@hg.openjdk.java.net> Changeset: c9eb1d3ef37f Author: robm Date: 2013-01-23 17:54 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9eb1d3ef37f 8004729: Add java.lang.reflect.Parameter and related changes for parameter reflection Reviewed-by: darcy, forax, psandoz, dholmes, tbell ! make/java/java/Exportedfiles.gmk ! make/java/java/FILES_c.gmk ! make/java/java/mapfile-vers ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java + src/share/classes/java/lang/reflect/Parameter.java ! src/share/javavm/export/jvm.h + src/share/native/java/lang/reflect/Executable.c + test/java/lang/reflect/Parameter/WithParameters.java + test/java/lang/reflect/Parameter/WithoutParameters.java From xueming.shen at oracle.com Wed Jan 23 10:26:36 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 23 Jan 2013 18:26:36 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130123182710.1873D474D5@hg.openjdk.java.net> Changeset: e0552f13f4a2 Author: sherman Date: 2013-01-23 10:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0552f13f4a2 8006773: test/java/util/zip/ZipFile/FinalizeZipFile.java failing intermittently Summary: fixed the test case Reviewed-by: alanb ! test/java/util/zip/ZipFile/FinalizeZipFile.java Changeset: 87f5569effdd Author: sherman Date: 2013-01-23 10:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/87f5569effdd Merge From vicente.romero at oracle.com Wed Jan 23 13:00:05 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 23 Jan 2013 21:00:05 +0000 Subject: hg: jdk8/tl/langtools: 8006694: temporarily workaround combo tests are causing time out in several platforms Message-ID: <20130123210011.5DE04474E4@hg.openjdk.java.net> Changeset: 5c956be64b9e Author: vromero Date: 2013-01-23 20:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5c956be64b9e 8006694: temporarily workaround combo tests are causing time out in several platforms Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! test/Makefile ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/T7093325.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java ! test/tools/javac/lambda/LambdaParserTest.java ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java ! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java ! test/tools/javac/lib/JavacTestingAbstractThreadedTest.java ! test/tools/javac/multicatch/7030606/DisjunctiveTypeWellFormednessTest.java ! test/tools/javac/varargs/7042566/T7042566.java ! test/tools/javac/varargs/warning/Warn4.java ! test/tools/javac/varargs/warning/Warn5.java From vincent.x.ryan at oracle.com Wed Jan 23 13:27:34 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 23 Jan 2013 21:27:34 +0000 Subject: hg: jdk8/tl/jdk: 8006591: Protect keystore entries using stronger PBE algorithms Message-ID: <20130123212752.E5816474E5@hg.openjdk.java.net> Changeset: 0c86df653029 Author: vinnie Date: 2013-01-23 21:25 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c86df653029 8006591: Protect keystore entries using stronger PBE algorithms Reviewed-by: mullan ! src/share/classes/java/security/KeyStore.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java + test/java/security/KeyStore/PBETest.java From jonathan.gibbons at oracle.com Wed Jan 23 13:28:05 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Jan 2013 21:28:05 +0000 Subject: hg: jdk8/tl/langtools: 8006775: JSR 308: Compiler changes in JDK8 Message-ID: <20130123212807.D5A39474E6@hg.openjdk.java.net> Changeset: 71f35e4b93a5 Author: jjg Date: 2013-01-23 13:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/71f35e4b93a5 8006775: JSR 308: Compiler changes in JDK8 Reviewed-by: jjg Contributed-by: mernst at cs.washington.edu, wmdietl at cs.washington.edu, mpapi at csail.mit.edu, mahmood at notnoop.com + src/share/classes/com/sun/javadoc/AnnotatedType.java ! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java ! src/share/classes/com/sun/javadoc/Type.java ! src/share/classes/com/sun/javadoc/TypeVariable.java + src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java + src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/TypeAnnotation.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Printer.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/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/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/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/JNIWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! 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/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java + src/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.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/CodeWriter.java ! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java + src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! src/share/classes/javax/lang/model/SourceVersion.java + src/share/classes/javax/lang/model/type/AnnotatedType.java ! src/share/classes/javax/lang/model/type/ExecutableType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/Types.java + test/com/sun/javadoc/testAnnotationOptional/TestAnnotationOptional.java + test/com/sun/javadoc/testAnnotationOptional/pkg/AnnotationOptional.java + test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java + test/com/sun/javadoc/typeAnnotations/smoke/pkg/TargetTypes.java ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/7129225/TestImportStar.ref ! test/tools/javac/T6873845.java + test/tools/javac/T6985181.java ! test/tools/javac/annotations/6881115/T6881115.java ! test/tools/javac/annotations/6881115/T6881115.out + test/tools/javac/annotations/typeAnnotations/6967002/T6967002.java + test/tools/javac/annotations/typeAnnotations/6967002/T6967002.out + test/tools/javac/annotations/typeAnnotations/InnerClass.java + test/tools/javac/annotations/typeAnnotations/MultipleTargets.java + test/tools/javac/annotations/typeAnnotations/TargetTypes.java + test/tools/javac/annotations/typeAnnotations/TypeParameterTarget.java + test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java + test/tools/javac/annotations/typeAnnotations/TypeUseTarget.java + test/tools/javac/annotations/typeAnnotations/api/AnnotatedArrayOrder.java + test/tools/javac/annotations/typeAnnotations/api/ArrayCreationTree.java + test/tools/javac/annotations/typeAnnotations/api/ArrayPositionConsistency.java + test/tools/javac/annotations/typeAnnotations/attribution/Scopes.java + test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java + test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java + test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java + test/tools/javac/annotations/typeAnnotations/classfile/DeadCode.java + test/tools/javac/annotations/typeAnnotations/classfile/NewTypeArguments.java + test/tools/javac/annotations/typeAnnotations/classfile/NoTargetAnnotations.java + test/tools/javac/annotations/typeAnnotations/classfile/TypeCasts.java + test/tools/javac/annotations/typeAnnotations/classfile/Wildcards.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.out + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.out + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.out + test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.out + test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion7.out + test/tools/javac/annotations/typeAnnotations/failures/BadCast.java + test/tools/javac/annotations/typeAnnotations/failures/BadCast.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out + test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.java + test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.out + test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.java + test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.out + test/tools/javac/annotations/typeAnnotations/failures/IndexArray.java + test/tools/javac/annotations/typeAnnotations/failures/IndexArray.out + test/tools/javac/annotations/typeAnnotations/failures/LintCast.java + test/tools/javac/annotations/typeAnnotations/failures/LintCast.out + test/tools/javac/annotations/typeAnnotations/failures/OldArray.java + test/tools/javac/annotations/typeAnnotations/failures/Scopes.java + test/tools/javac/annotations/typeAnnotations/failures/Scopes.out + test/tools/javac/annotations/typeAnnotations/failures/StaticFields.java + test/tools/javac/annotations/typeAnnotations/failures/StaticFields.out + test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.java + test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.out + test/tools/javac/annotations/typeAnnotations/failures/TypeAndField.java + test/tools/javac/annotations/typeAnnotations/failures/VoidGenericMethod.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/BrokenAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/BrokenAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/Nesting.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/target/Constructor.java + test/tools/javac/annotations/typeAnnotations/failures/target/Constructor.out + test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java + test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.out + test/tools/javac/annotations/typeAnnotations/failures/target/IncompleteArray.java + test/tools/javac/annotations/typeAnnotations/failures/target/IncompleteArray.out + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeParameter.java + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeParameter.out + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeUse.java + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeUse.out + test/tools/javac/annotations/typeAnnotations/failures/target/VoidMethod.java + test/tools/javac/annotations/typeAnnotations/failures/target/VoidMethod.out + test/tools/javac/annotations/typeAnnotations/newlocations/BasicTest.java + test/tools/javac/annotations/typeAnnotations/newlocations/ClassExtends.java + test/tools/javac/annotations/typeAnnotations/newlocations/ClassParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/ConstructorTypeArgs.java + test/tools/javac/annotations/typeAnnotations/newlocations/ExceptionParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/Expressions.java + test/tools/javac/annotations/typeAnnotations/newlocations/Fields.java + test/tools/javac/annotations/typeAnnotations/newlocations/LocalVariables.java + test/tools/javac/annotations/typeAnnotations/newlocations/MethodReturnType.java + test/tools/javac/annotations/typeAnnotations/newlocations/MethodTypeArgs.java + test/tools/javac/annotations/typeAnnotations/newlocations/MethodTypeParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java + test/tools/javac/annotations/typeAnnotations/newlocations/NestedTypes.java + test/tools/javac/annotations/typeAnnotations/newlocations/Parameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/Receivers.java + test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java + test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out + test/tools/javac/annotations/typeAnnotations/newlocations/ResourceVariables.java + test/tools/javac/annotations/typeAnnotations/newlocations/Throws.java + test/tools/javac/annotations/typeAnnotations/newlocations/TopLevelBlocks.java + test/tools/javac/annotations/typeAnnotations/newlocations/TypeCasts.java + test/tools/javac/annotations/typeAnnotations/newlocations/TypeParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java + test/tools/javac/annotations/typeAnnotations/newlocations/Wildcards.java + test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java + test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/Anno.java + test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/MyClass.java + test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/package-info.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassExtends.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassTypeParam.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/ExceptionParameters.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/FromSpecification.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReceivers.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReturns.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodThrows.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodTypeParam.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/NewObjects.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/RepeatingTypeAnnotations.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeTests.java ! test/tools/javac/api/EndPositions.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/CantAnnotateNestedType.java + test/tools/javac/diags/examples/CantAnnotateStaticClass.java + test/tools/javac/diags/examples/IncorrectReceiverType.java + test/tools/javac/diags/examples/NoAnnotationsOnDotClass.java + test/tools/javac/diags/examples/ThisAsIdentifier.java + test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/processing/6994946/SemanticErrorTest.2.out ! test/tools/javac/processing/model/element/TestAnonClassNames.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java + test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.ref ! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java + test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.ref ! test/tools/javac/tree/TreeKindTest.java ! test/tools/javac/tree/TreePosTest.java + test/tools/javac/treeannotests/AnnoTreeTests.java ! test/tools/javac/treeannotests/TestProcessor.java - test/tools/javac/typeAnnotations/newlocations/BasicTest.java - test/tools/javac/typeAnnotations/newlocations/BasicTest.out + test/tools/javap/typeAnnotations/JSR175Annotations.java + test/tools/javap/typeAnnotations/NewArray.java + test/tools/javap/typeAnnotations/Presence.java + test/tools/javap/typeAnnotations/PresenceInner.java + test/tools/javap/typeAnnotations/T6855990.java + test/tools/javap/typeAnnotations/TypeCasts.java + test/tools/javap/typeAnnotations/Visibility.java + test/tools/javap/typeAnnotations/Wildcards.java From vincent.x.ryan at oracle.com Wed Jan 23 15:14:41 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 23 Jan 2013 23:14:41 +0000 Subject: hg: jdk8/tl/jdk: 8005408: KeyStore API enhancements Message-ID: <20130123231505.DF6E7474F6@hg.openjdk.java.net> Changeset: 1da93663f8f3 Author: vinnie Date: 2013-01-23 23:13 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1da93663f8f3 8005408: KeyStore API enhancements Reviewed-by: mullan ! src/share/classes/java/security/KeyStore.java + src/share/classes/java/security/PKCS12Attribute.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/pkcs12/StorePasswordTest.java + test/sun/security/pkcs12/StoreSecretKeyTest.java + test/sun/security/pkcs12/StoreTrustedCertTest.java + test/sun/security/pkcs12/trusted.pem From yumin.qi at oracle.com Wed Jan 23 16:18:31 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 23 Jan 2013 16:18:31 -0800 Subject: =?GB2312?B?tPC4tDogRXJyb3JzIHdoZW4gdXNlICJ1bml2ZXJzZSIgY29tbQ==?= =?GB2312?B?YW5kIGluIENMSFNEQg==?= In-Reply-To: <50F90C77.5070604@oracle.com> References: <50F8B771.3080505@oracle.com> <50F90C77.5070604@oracle.com> Message-ID: <51007DD7.9090506@oracle.com> Yes, this is the bug. I just looked at the code, Yunda is right. In type library, the name for BinaryTreeDictionary is AFLBinaryTreeDictionary: type AFLBinaryTreeDictionary FreeBlockDictionary false false false 24 _dictionary is not added to vmStructs. /Yumin On 1/18/2013 12:48 AM, Mikael Gerdin wrote: > I saw an existing bug reported for this the other day: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005278 > > I cc:ed Yumin who currently owns the bug. > > /Mikael > > On 2013-01-18 04:54, ???? wrote: >> Thanks Dan! >> >> Regards, >> >> Yunda >> >> *??????:*Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] >> *????????:*2013??1??18??10:46 >> *??????:*????; serviceability-dev at openjdk.java.net >> *????:*Re: Errors when use "universe" command in CLHSDB >> >> Yunda, >> >> The Serviceability Agent is maintained by the Serviceability team. >> I'm adding that alias to this e-mail thread (and Bcc'ing the Runtime >> alias. >> >> Dan >> >> On 1/17/13 7:42 PM, ????wrote: >> >> Hi all, >> >> This is Yunda >> from Alibaba Group(with OCA). >> >> When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar >> sun.jvm.hotspot.CLHSDB) I found two errors below(the second error >> occurred after I made some fix). It seemed that some code about CMS >> in SA didn??t change accordingly. >> >> hsdb> universe >> >> Heap Parameters: >> >> Gen 0: eden >> [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space >> capacity = 140640256, 2.000007736049627 used >> >> from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) >> space capacity = 17563648, 0.0 used >> >> to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) >> space capacity = 17563648, 0.0 usedInvocations: 0 >> >> Gen 1: concurrent mark-sweep generation >> >> Exception in thread "main" java.lang.ExceptionInInitializerError >> >> at >> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> >> at >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >> >> at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> >> at >> java.lang.reflect.Constructor.newInstance(Constructor.java:395) >> >> at >> sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) >> >> at >> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) >> >> at >> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) >> >> at >> sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) >> >> at >> sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) >> >> at >> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) >> >> at >> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) >> >> at >> sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) >> >> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) >> >> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) >> >> Caused by: java.lang.RuntimeException: field "_dictionary" not found >> in type CompactibleFreeListSpace >> >> at >> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) >> >> at >> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) >> >> at >> sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) >> >> at >> sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) >> >> at >> sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) >> >> at >> sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) >> >> at >> sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) >> >> at >> sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) >> >> at >> sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) >> >> ... 14 more >> >> hsdb> universe >> >> Heap Parameters: >> >> Gen 0: eden >> [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space >> capacity = 140640256, 2.000007736049627 used >> >> from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) >> space capacity = 17563648, 0.0 used >> >> to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) >> space capacity = 17563648, 0.0 usedInvocations: 0 >> >> Gen 1: concurrent mark-sweep generation >> >> free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception >> in thread "main" java.lang.ExceptionInInitializerError >> >> at >> sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) >> >> at >> sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) >> >> at >> sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) >> >> at >> sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) >> >> at >> sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) >> >> at >> sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) >> >> at >> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) >> >> at >> sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) >> >> at >> sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) >> >> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) >> >> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) >> >> Caused by: java.lang.RuntimeException: No type named "FreeList" in >> database >> >> at >> sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) >> >> at >> sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) >> >> at >> sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) >> >> at >> sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) >> >> at >> sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) >> >> at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) >> >> at >> sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) >> >> at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) >> >> ... 11 more >> >> So I made a patch to fix them and now ??universe?? command works well. >> Could someone help to review the patch below? >> >> diff -r b14da2e6f2dc -r 8652e04889a4 >> agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java >> >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> >> +++ >> b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java >> Fri Jan 18 09:56:06 2013 +0800 >> >> @@ -0,0 +1,59 @@ >> >> +/* >> >> + * @(#)AFLBinaryTreeDictionary.java >> >> + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All >> rights reserved. >> >> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> >> + * >> >> + * This code is free software; you can redistribute it and/or modify it >> >> + * under the terms of the GNU General Public License version 2 only, as >> >> + * published by the Free Software Foundation. >> >> + * >> >> + * This code is distributed in the hope that it will be useful, but >> WITHOUT >> >> + * ANY WARRANTY; without even the implied warranty of >> MERCHANTABILITY or >> >> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >> License >> >> + * version 2 for more details (a copy is included in the LICENSE >> file that >> >> + * accompanied this code). >> >> + * >> >> + * You should have received a copy of the GNU General Public >> License version >> >> + * 2 along with this work; if not, write to the Free Software >> Foundation, >> >> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> >> + * >> >> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >> 94065 USA >> >> + * or visit www.oracle.com if you need >> additional information or have any >> >> + * questions. >> >> + * >> >> + */ >> >> + >> >> +package sun.jvm.hotspot.memory; >> >> + >> >> +import java.util.*; >> >> +import sun.jvm.hotspot.debugger.*; >> >> +import sun.jvm.hotspot.types.*; >> >> +import sun.jvm.hotspot.runtime.*; >> >> + >> >> +public class AFLBinaryTreeDictionary extends VMObject { >> >> + static { >> >> + VM.registerVMInitializedObserver(new Observer() { >> >> + public void update(Observable o, Object data) { >> >> + initialize(VM.getVM().getTypeDataBase()); >> >> + } >> >> + }); >> >> + } >> >> + >> >> + private static synchronized void initialize(TypeDataBase db) { >> >> + Type type = db.lookupType("AFLBinaryTreeDictionary"); >> >> + totalSizeField = type.getCIntegerField("_total_size"); >> >> + } >> >> + >> >> + // Fields >> >> + private static CIntegerField totalSizeField; >> >> + >> >> + // Accessors >> >> + public long size() { >> >> + return totalSizeField.getValue(addr); >> >> + } >> >> + >> >> + // Constructor >> >> + public AFLBinaryTreeDictionary(Address addr) { >> >> + super(addr); >> >> + } >> >> +} >> >> diff -r b14da2e6f2dc -r 8652e04889a4 >> agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java >> >> --- >> a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java >> Thu Jan 17 13:40:31 2013 -0500 >> >> +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 >> >> @@ -1,59 +0,0 @@ >> >> -/* >> >> - * @(#)BinaryTreeDictionary.java >> >> - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All >> rights reserved. >> >> - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> >> - * >> >> - * This code is free software; you can redistribute it and/or modify it >> >> - * under the terms of the GNU General Public License version 2 only, as >> >> - * published by the Free Software Foundation. >> >> - * >> >> - * This code is distributed in the hope that it will be useful, but >> WITHOUT >> >> - * ANY WARRANTY; without even the implied warranty of >> MERCHANTABILITY or >> >> - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >> License >> >> - * version 2 for more details (a copy is included in the LICENSE >> file that >> >> - * accompanied this code). >> >> - * >> >> - * You should have received a copy of the GNU General Public >> License version >> >> - * 2 along with this work; if not, write to the Free Software >> Foundation, >> >> - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> >> - * >> >> - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >> 94065 USA >> >> - * or visit www.oracle.com if you need >> additional information or have any >> >> - * questions. >> >> - * >> >> - */ >> >> - >> >> -package sun.jvm.hotspot.memory; >> >> - >> >> -import java.util.*; >> >> -import sun.jvm.hotspot.debugger.*; >> >> -import sun.jvm.hotspot.types.*; >> >> -import sun.jvm.hotspot.runtime.*; >> >> - >> >> -public class BinaryTreeDictionary extends VMObject { >> >> - static { >> >> - VM.registerVMInitializedObserver(new Observer() { >> >> - public void update(Observable o, Object data) { >> >> - initialize(VM.getVM().getTypeDataBase()); >> >> - } >> >> - }); >> >> - } >> >> - >> >> - private static synchronized void initialize(TypeDataBase db) { >> >> - Type type = db.lookupType("BinaryTreeDictionary"); >> >> - totalSizeField = type.getCIntegerField("_totalSize"); >> >> - } >> >> - >> >> - // Fields >> >> - private static CIntegerField totalSizeField; >> >> - >> >> - // Accessors >> >> - public long size() { >> >> - return totalSizeField.getValue(addr); >> >> - } >> >> - >> >> - // Constructor >> >> - public BinaryTreeDictionary(Address addr) { >> >> - super(addr); >> >> - } >> >> -} >> >> diff -r b14da2e6f2dc -r 8652e04889a4 >> agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java >> >> --- >> a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java >> Thu Jan 17 13:40:31 2013 -0500 >> >> +++ >> b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java >> Fri Jan 18 09:56:06 2013 +0800 >> >> @@ -117,7 +117,7 @@ >> >> } >> >> // large block >> >> - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) >> VMObjectFactory.newObject(BinaryTreeDictionary.class, >> >> + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) >> VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, >> >> dictionaryField.getValue(addr)); >> >> size += bfbd.size(); >> >> diff -r b14da2e6f2dc -r 8652e04889a4 >> agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >> >> --- >> a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >> Thu Jan 17 13:40:31 2013 -0500 >> >> +++ >> b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java >> Fri Jan 18 09:56:06 2013 +0800 >> >> @@ -41,7 +41,7 @@ >> >> } >> >> private static synchronized void initialize(TypeDataBase db) { >> >> - Type type = db.lookupType("FreeList"); >> >> + Type type = db.lookupType("FreeList"); >> >> sizeField = type.getCIntegerField("_size"); >> >> countField = type.getCIntegerField("_count"); >> >> headerSize = type.getSize(); >> >> diff -r b14da2e6f2dc -r 8652e04889a4 >> src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >> >> --- >> a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >> Thu Jan 17 13:40:31 2013 -0500 >> >> +++ >> b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >> Fri Jan 18 09:56:06 2013 +0800 >> >> @@ -43,7 +43,8 @@ >> >> nonstatic_field(LinearAllocBlock, >> _word_size, >> size_t) \ >> >> nonstatic_field(AFLBinaryTreeDictionary, >> _total_size, >> size_t) \ >> >> nonstatic_field(CompactibleFreeListSpace, >> _indexedFreeList[0], >> FreeList) \ >> >> - nonstatic_field(CompactibleFreeListSpace, >> _smallLinearAllocBlock, LinearAllocBlock) >> >> + nonstatic_field(CompactibleFreeListSpace, >> _smallLinearAllocBlock, >> LinearAllocBlock) \ >> >> + nonstatic_field(CompactibleFreeListSpace, >> _dictionary, >> FreeBlockDictionary*) >> >> #define >> VM_TYPES_CMS(declare_type, \ >> >> Regards, >> >> Yunda >> >> ------------------------------------------------------------------------ >> >> >> This email (including any attachments) is confidential and may be >> legally privileged. If you received this email in error, please >> delete it immediately and do not copy it or use it for any purpose >> or disclose its contents to any other person. Thank you. >> >> ??????(????????????)???????????????????????????????????????????????? >> ???????????????????????????????????????????????????????????????????? >> ???????????????????????? >> >> >> ------------------------------------------------------------------------ >> >> This email (including any attachments) is confidential and may be >> legally privileged. If you received this email in error, please delete >> it immediately and do not copy it or use it for any purpose or disclose >> its contents to any other person. Thank you. >> >> ??????(????????????)???????????????????????????????????????????????????? >> ???????????????????????????????????????????????????????????????????????? >> ???????????????? From sean.mullan at oracle.com Wed Jan 23 17:47:52 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 24 Jan 2013 01:47:52 +0000 Subject: hg: jdk8/tl/jdk: 8006813: Compilation error in PKCS12KeyStore.java Message-ID: <20130124014816.49EFF474FE@hg.openjdk.java.net> Changeset: 89f37f7188df Author: mullan Date: 2013-01-23 20:46 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89f37f7188df 8006813: Compilation error in PKCS12KeyStore.java Reviewed-by: valeriep ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java From joe.darcy at oracle.com Wed Jan 23 20:11:18 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 24 Jan 2013 04:11:18 +0000 Subject: hg: jdk8/tl/langtools: 8006264: Add explanation of why default methods cannot be used in JDK 8 javax.lang.model Message-ID: <20130124041124.3C31447505@hg.openjdk.java.net> Changeset: 09f65aad4759 Author: darcy Date: 2013-01-23 20:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/09f65aad4759 8006264: Add explanation of why default methods cannot be used in JDK 8 javax.lang.model Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/AnnotationValueVisitor.java ! src/share/classes/javax/lang/model/element/ElementVisitor.java ! src/share/classes/javax/lang/model/type/TypeVisitor.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/AbstractAnnotationValueVisitor8.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/AbstractElementVisitor8.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/AbstractTypeVisitor8.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/ElementKindVisitor8.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/SimpleAnnotationValueVisitor8.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/SimpleElementVisitor8.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/SimpleTypeVisitor8.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor8.java From yumin.qi at oracle.com Wed Jan 23 22:14:17 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 23 Jan 2013 22:14:17 -0800 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail Message-ID: <5100D139.3040705@oracle.com> Hi, Can I have your comments on fix for 8005278: Serviceability Agent: jmap -heap and jstack -m fail http://cr.openjdk.java.net/~minqi/8005278/ Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary and this name carried to type library for SA. In SA we still use olde name for that; 2) FreeList now is template based which is not reflected in SA; 3) There is a misuse of FIELFINFO_TAG_MASK(which is not in SA code), in SA code FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to not able to find correct field info. Thanks Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130123/03e377ca/attachment-0001.html From david.holmes at oracle.com Wed Jan 23 22:29:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2013 16:29:04 +1000 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <5100D139.3040705@oracle.com> References: <5100D139.3040705@oracle.com> Message-ID: <5100D4B0.4060105@oracle.com> Thanks Yumin this all looks okay to me. David On 24/01/2013 4:14 PM, Yumin Qi wrote: > Hi, > > Can I have your comments on fix for > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > > http://cr.openjdk.java.net/~minqi/8005278/ > > Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as > AFLBinaryTreeDictionary and this name carried to type library for SA. In > SA we still use olde name for that; 2) FreeList now is template based > which is not reflected in SA; 3) There is a misuse of > FIELFINFO_TAG_MASK(which is not in SA code), in SA code > FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to > not able to find correct field info. > > Thanks > Yumin > > > From krystal.mo at oracle.com Wed Jan 23 22:33:18 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 24 Jan 2013 14:33:18 +0800 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <5100D139.3040705@oracle.com> References: <5100D139.3040705@oracle.com> Message-ID: <5100D5AE.6010105@oracle.com> Yumin, The FIELDINFO_TAG_MASK part in InstanceKlass is already fixed in JDK-8006403. It should be sync'd to the dev repos soon (or has it already?) I fell in that trap of duplicating the fix as JDK-8006641 already... - Kris On 01/24/2013 02:14 PM, Yumin Qi wrote: > Hi, > > Can I have your comments on fix for > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > > http://cr.openjdk.java.net/~minqi/8005278/ > > Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as > AFLBinaryTreeDictionary and this name carried to type library for SA. > In SA we still use olde name for that; 2) FreeList now is template > based which is not reflected in SA; 3) There is a misuse of > FIELFINFO_TAG_MASK(which is not in SA code), in SA code > FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to > not able to find correct field info. > > Thanks > Yumin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130124/5a1a1415/attachment.html From yunda.mly at taobao.com Wed Jan 23 22:54:22 2013 From: yunda.mly at taobao.com (=?utf-8?B?5LqR6L6+?=) Date: Thu, 24 Jan 2013 06:54:22 +0000 Subject: =?utf-8?B?562U5aSNOiBSRlI6IDgwMDUyNzg6IFNlcnZpY2VhYmlsaXR5IEFnZW50OiBq?= =?utf-8?Q?map_-heap_and_jstack_-m_fail?= In-Reply-To: <5100D5AE.6010105@oracle.com> References: <5100D139.3040705@oracle.com> <5100D5AE.6010105@oracle.com> Message-ID: Yes. That?s why my fix before didn?t include the FIELDINFO_TAD_MASK part: http://cr.openjdk.java.net/~sla/8005278/webrev.00/ Regards, Yunda ???: serviceability-dev-bounces at openjdk.java.net [mailto:serviceability-dev-bounces at openjdk.java.net] ?? Krystal Mo ????: 2013?1?24? 14:33 ???: Yumin Qi ??: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-gc-dev openjdk.java.net; hotspot-runtime-dev at openjdk.java.net ??: Re: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail Yumin, The FIELDINFO_TAG_MASK part in InstanceKlass is already fixed in JDK-8006403. It should be sync'd to the dev repos soon (or has it already?) I fell in that trap of duplicating the fix as JDK-8006641 already... - Kris On 01/24/2013 02:14 PM, Yumin Qi wrote: Hi, Can I have your comments on fix for 8005278: Serviceability Agent: jmap -heap and jstack -m fail http://cr.openjdk.java.net/~minqi/8005278/ Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary and this name carried to type library for SA. In SA we still use olde name for that; 2) FreeList now is template based which is not reflected in SA; 3) There is a misuse of FIELFINFO_TAG_MASK(which is not in SA code), in SA code FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to not able to find correct field info. Thanks Yumin ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ???(??????)?????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130124/019540c7/attachment.html From alan.bateman at oracle.com Thu Jan 24 01:49:07 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Jan 2013 09:49:07 +0000 Subject: hg: jdk8/tl/jdk: 8006524: JSR-3: Allows java.beans to be optional Message-ID: <20130124094930.1C5AC4750C@hg.openjdk.java.net> Changeset: b68ac92d0b2a Author: alanb Date: 2013-01-24 09:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b68ac92d0b2a 8006524: JSR-3: Allows java.beans to be optional Reviewed-by: dfuchs, mchung ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/monitor/package.html From erik.helin at oracle.com Thu Jan 24 02:51:18 2013 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 24 Jan 2013 11:51:18 +0100 Subject: RFR (S): 8004172: Update jstat counter names to reflect metaspace changes Message-ID: <51011226.9050509@oracle.com> Hi all, here are the JDK changes for fixing JDK-8004172. This change updates the jstat resource file to use the new metaspace performance counters and also updates the tests. Note that the fixed tests will continue to fail until the HotSpot part of the change finds it way into the tl forest. The HotSpot part of the change is also out for review on hotspot-gc-dev at openjdk.java.net. Webrev: JDK: http://cr.openjdk.java.net/~ehelin/8004172/jdk/webrev.00/ HotSpot: http://cr.openjdk.java.net/~ehelin/8004172/hotspot/webrev.00/ Bug: http://bugs.sun.com/view_bug.do?bug_id=8004172 Testing: Run the jstat jtreg tests locally on my machine on a repository where I've applied both the JDK changes and the HotSpot changes. Thanks, Erik From staffan.larsen at oracle.com Thu Jan 24 04:27:49 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 24 Jan 2013 13:27:49 +0100 Subject: RFR (S): 8004172: Update jstat counter names to reflect metaspace changes In-Reply-To: <51011226.9050509@oracle.com> References: <51011226.9050509@oracle.com> Message-ID: The JDK changes look good, but I think there is change needed in test/sun/tools/jstatd/jstatGcutilOutput1.awk as well. Thanks, /Staffan On 24 jan 2013, at 11:51, Erik Helin wrote: > Hi all, > > here are the JDK changes for fixing JDK-8004172. This change updates the jstat resource file to use the new metaspace performance counters and also updates the tests. > > Note that the fixed tests will continue to fail until the HotSpot part of the change finds it way into the tl forest. > > The HotSpot part of the change is also out for review on hotspot-gc-dev at openjdk.java.net. > > Webrev: > JDK: http://cr.openjdk.java.net/~ehelin/8004172/jdk/webrev.00/ > HotSpot: http://cr.openjdk.java.net/~ehelin/8004172/hotspot/webrev.00/ > > Bug: > http://bugs.sun.com/view_bug.do?bug_id=8004172 > > Testing: > Run the jstat jtreg tests locally on my machine on a repository where I've applied both the JDK changes and the HotSpot changes. > > Thanks, > Erik From yumin.qi at oracle.com Thu Jan 24 08:07:41 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 08:07:41 -0800 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <5100D5AE.6010105@oracle.com> References: <5100D139.3040705@oracle.com> <5100D5AE.6010105@oracle.com> Message-ID: <51015C4D.2030504@oracle.com> I haven't seen this fix so will remove it from my diff. I cloned from hotspot-gc which has not had this fix yet. So I will send out another webrev based on hotspot-rt. Thanks Yumin On 1/23/2013 10:33 PM, Krystal Mo wrote: > Yumin, > > The FIELDINFO_TAG_MASK part in InstanceKlass is already fixed in > JDK-8006403. It should be sync'd to the dev repos soon (or has it > already?) > I fell in that trap of duplicating the fix as JDK-8006641 already... > > - Kris > > On 01/24/2013 02:14 PM, Yumin Qi wrote: >> Hi, >> >> Can I have your comments on fix for >> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >> >> http://cr.openjdk.java.net/~minqi/8005278/ >> >> Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as >> AFLBinaryTreeDictionary and this name carried to type library for SA. >> In SA we still use olde name for that; 2) FreeList now is template >> based which is not reflected in SA; 3) There is a misuse of >> FIELFINFO_TAG_MASK(which is not in SA code), in SA code >> FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to >> not able to find correct field info. >> >> Thanks >> Yumin >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130124/bd46b99a/attachment.html From vincent.x.ryan at oracle.com Thu Jan 24 08:45:00 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 24 Jan 2013 16:45:00 +0000 Subject: hg: jdk8/tl/jdk: 8006855: PKCS12 test failures due to unsupported algorithm Message-ID: <20130124164544.CB4414751C@hg.openjdk.java.net> Changeset: 943af87e0269 Author: vinnie Date: 2013-01-24 16:44 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/943af87e0269 8006855: PKCS12 test failures due to unsupported algorithm Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! test/java/security/KeyStore/PBETest.java ! test/sun/security/pkcs12/StoreSecretKeyTest.java From erik.helin at oracle.com Thu Jan 24 09:36:49 2013 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 24 Jan 2013 18:36:49 +0100 Subject: RFR (S): 8004172: Update jstat counter names to reflect metaspace changes In-Reply-To: References: <51011226.9050509@oracle.com> Message-ID: <51017131.7040603@oracle.com> Hi Staffan, thanks for reviewing this! On 01/24/2013 01:27 PM, Staffan Larsen wrote: > The JDK changes look good, but I think there is change needed in test/sun/tools/jstatd/jstatGcutilOutput1.awk as well. Yes, you are right. Please see an updated webrev at: http://cr.openjdk.java.net/~ehelin/8004172/jdk/webrev.01/ Thanks, Erik > Thanks, > /Staffan > > On 24 jan 2013, at 11:51, Erik Helin wrote: > >> Hi all, >> >> here are the JDK changes for fixing JDK-8004172. This change updates the jstat resource file to use the new metaspace performance counters and also updates the tests. >> >> Note that the fixed tests will continue to fail until the HotSpot part of the change finds it way into the tl forest. >> >> The HotSpot part of the change is also out for review on hotspot-gc-dev at openjdk.java.net. >> >> Webrev: >> JDK: http://cr.openjdk.java.net/~ehelin/8004172/jdk/webrev.00/ >> HotSpot: http://cr.openjdk.java.net/~ehelin/8004172/hotspot/webrev.00/ >> >> Bug: >> http://bugs.sun.com/view_bug.do?bug_id=8004172 >> >> Testing: >> Run the jstat jtreg tests locally on my machine on a repository where I've applied both the JDK changes and the HotSpot changes. >> >> Thanks, >> Erik > From kumar.x.srinivasan at oracle.com Thu Jan 24 09:38:08 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 24 Jan 2013 17:38:08 +0000 Subject: hg: jdk8/tl/jdk: 8006850: [pack200] disable pack200 tests until JSR-308 is implemented Message-ID: <20130124173834.B2D4447525@hg.openjdk.java.net> Changeset: 1fd613016ad9 Author: ksrini Date: 2013-01-24 09:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1fd613016ad9 8006850: [pack200] disable pack200 tests until JSR-308 is implemented Reviewed-by: alanb ! test/ProblemList.txt From vincent.x.ryan at oracle.com Thu Jan 24 10:21:58 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 24 Jan 2013 18:21:58 +0000 Subject: hg: jdk8/tl/jdk: 8006863: javadoc cleanup for 8005408 Message-ID: <20130124182221.A5E4747527@hg.openjdk.java.net> Changeset: b3f0e0c79bcc Author: vinnie Date: 2013-01-24 18:21 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3f0e0c79bcc 8006863: javadoc cleanup for 8005408 Reviewed-by: alanb ! src/share/classes/java/security/PKCS12Attribute.java From serguei.spitsyn at oracle.com Thu Jan 24 10:38:10 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 24 Jan 2013 10:38:10 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <50FF29CA.9000009@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> Message-ID: <51017F92.6020803@oracle.com> I know everyone is overloaded this days, but... May I get a couple of reviews, please? Thanks, Serguei On 1/22/13 4:07 PM, serguei.spitsyn at oracle.com wrote: > > Please, review the fix for: > https://jbs.oracle.com/bugs/browse/JDK-8006542 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ > > Summary: > Need a support for invokedynamic entry kinds when new and old > constant pools are merged. > > Testing: > vm/mlvm/indy/func/jvmti/redefineClassInBootstrap > Asked the VM SQE team to develop new INDY tests for better coverage. > > > Thanks, > Serguei > > > From christian.thalinger at oracle.com Thu Jan 24 14:14:48 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Jan 2013 14:14:48 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <50FF29CA.9000009@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> Message-ID: On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: > > Please, review the fix for: > https://jbs.oracle.com/bugs/browse/JDK-8006542 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ src/share/vm/prims/jvmtiRedefineClasses.hpp: + // Support for constant pool merging (these routines are in alpha order): void append_entry(constantPoolHandle scratch_cp, int scratch_i, constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); + int find_or_append_indirect_entry(constantPoolHandle scratch_cp, int scratch_i, + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); int find_new_index(int old_index); Not really alpha order ;-) Otherwise this looks good (as far as I can tell). -- Chris > > Summary: > Need a support for invokedynamic entry kinds when new and old constant pools are merged. > > Testing: > vm/mlvm/indy/func/jvmti/redefineClassInBootstrap > Asked the VM SQE team to develop new INDY tests for better coverage. > > > Thanks, > Serguei > > > From serguei.spitsyn at oracle.com Thu Jan 24 14:56:36 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 24 Jan 2013 14:56:36 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> Message-ID: <5101BC24.1020905@oracle.com> Christian, Thank you a lot for the review! Nice catch with the ordering. In fact, I tried to follow the order but missed that the find_new_index should go first. :) Thanks, Serguei On 1/24/13 2:14 PM, Christian Thalinger wrote: > On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: > >> Please, review the fix for: >> https://jbs.oracle.com/bugs/browse/JDK-8006542 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ > src/share/vm/prims/jvmtiRedefineClasses.hpp: > > + // Support for constant pool merging (these routines are in alpha order): > void append_entry(constantPoolHandle scratch_cp, int scratch_i, > constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); > + int find_or_append_indirect_entry(constantPoolHandle scratch_cp, int scratch_i, > + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); > int find_new_index(int old_index); > > Not really alpha order ;-) > > Otherwise this looks good (as far as I can tell). > > -- Chris > >> Summary: >> Need a support for invokedynamic entry kinds when new and old constant pools are merged. >> >> Testing: >> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >> Asked the VM SQE team to develop new INDY tests for better coverage. >> >> >> Thanks, >> Serguei >> >> >> From coleen.phillimore at oracle.com Thu Jan 24 15:55:24 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 24 Jan 2013 18:55:24 -0500 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <5101BC24.1020905@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> <5101BC24.1020905@oracle.com> Message-ID: <5101C9EC.6060608@oracle.com> Hi Serguei, Putting functions in alphabetical order seems silly, it's better to have utility functions directly above (or below) the function that calls them. I'd take out the comment. I have started looking at this code a bit. This function find_or_append_indirect_entry() should be used for the other indirect entries also, shouldn't it? The code looks familiar to the inside of the case statement to FieldRef, InterfaceRef and MethodRef. Also is boot_spec an indirect index too that has to be appended? 564 int boot_spec = scratch_cp->invoke_dynamic_bootstrap_method_ref_index_at(scratch_i); Thanks, Coleen On 01/24/2013 05:56 PM, serguei.spitsyn at oracle.com wrote: > Christian, > > > Thank you a lot for the review! > > Nice catch with the ordering. > In fact, I tried to follow the order but missed that the > find_new_index should go first. :) > > > Thanks, > Serguei > > > On 1/24/13 2:14 PM, Christian Thalinger wrote: >> On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: >> >>> Please, review the fix for: >>> https://jbs.oracle.com/bugs/browse/JDK-8006542 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ >> src/share/vm/prims/jvmtiRedefineClasses.hpp: >> >> + // Support for constant pool merging (these routines are in alpha >> order): >> void append_entry(constantPoolHandle scratch_cp, int scratch_i, >> constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >> + int find_or_append_indirect_entry(constantPoolHandle scratch_cp, >> int scratch_i, >> + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >> int find_new_index(int old_index); >> >> Not really alpha order ;-) >> >> Otherwise this looks good (as far as I can tell). >> >> -- Chris >> >>> Summary: >>> Need a support for invokedynamic entry kinds when new and old >>> constant pools are merged. >>> >>> Testing: >>> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >>> Asked the VM SQE team to develop new INDY tests for better coverage. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> > From joe.darcy at oracle.com Thu Jan 24 16:54:27 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 25 Jan 2013 00:54:27 +0000 Subject: hg: jdk8/tl/jdk: 8006895: Clarify that FunctionalInferface is only informative Message-ID: <20130125005448.4AEDD4753C@hg.openjdk.java.net> Changeset: 4d3c05cc21d5 Author: darcy Date: 2013-01-24 16:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d3c05cc21d5 8006895: Clarify that FunctionalInferface is only informative Reviewed-by: briangoetz ! src/share/classes/java/lang/FunctionalInterface.java From serguei.spitsyn at oracle.com Thu Jan 24 17:23:58 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 24 Jan 2013 17:23:58 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <5101C9EC.6060608@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> <5101BC24.1020905@oracle.com> <5101C9EC.6060608@oracle.com> Message-ID: <5101DEAE.9000404@oracle.com> Hi Coleen, Thank you a lot for the review! On 1/24/13 3:55 PM, Coleen Phillimore wrote: > > Hi Serguei, > > Putting functions in alphabetical order seems silly, it's better to > have utility functions directly above (or below) the function that > calls them. I'd take out the comment. > > I have started looking at this code a bit. This function > find_or_append_indirect_entry() should be used for the other indirect > entries also, shouldn't it? The code looks familiar to the inside of > the case statement to FieldRef, InterfaceRef and MethodRef. You've got it right. Yes, I noticed it but did not want to mess with it until it is proven to work well. My plan was to fix it for the FieldRef, InterfaceRef and MethodRef in a next round of fixes. > > Also is boot_spec an indirect index too that has to be appended? > > 564 int boot_spec = > scratch_cp->invoke_dynamic_bootstrap_method_ref_index_at(scratch_i); This is a nice catch, will fix it. I thought, it is an index into the operands array, but it refers to a CONSTANT_MethodHandle element. Thanks, Serguei > > > Thanks, > Coleen > > On 01/24/2013 05:56 PM, serguei.spitsyn at oracle.com wrote: >> Christian, >> >> >> Thank you a lot for the review! >> >> Nice catch with the ordering. >> In fact, I tried to follow the order but missed that the >> find_new_index should go first. :) >> >> >> Thanks, >> Serguei >> >> >> On 1/24/13 2:14 PM, Christian Thalinger wrote: >>> On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: >>> >>>> Please, review the fix for: >>>> https://jbs.oracle.com/bugs/browse/JDK-8006542 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ >>>> >>> src/share/vm/prims/jvmtiRedefineClasses.hpp: >>> >>> + // Support for constant pool merging (these routines are in alpha >>> order): >>> void append_entry(constantPoolHandle scratch_cp, int scratch_i, >>> constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>> + int find_or_append_indirect_entry(constantPoolHandle scratch_cp, >>> int scratch_i, >>> + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>> int find_new_index(int old_index); >>> >>> Not really alpha order ;-) >>> >>> Otherwise this looks good (as far as I can tell). >>> >>> -- Chris >>> >>>> Summary: >>>> Need a support for invokedynamic entry kinds when new and old >>>> constant pools are merged. >>>> >>>> Testing: >>>> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >>>> Asked the VM SQE team to develop new INDY tests for better coverage. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >> > From yumin.qi at oracle.com Thu Jan 24 17:28:11 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 17:28:11 -0800 Subject: Question of 'contributor' at hg commit Message-ID: <5101DFAB.8000302@oracle.com> When I add yunda.mly at taobao.com in following comment: 8005278: Serviceability Agent: jmap -heap and jstack -m fail Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. Reviewed-by: dholmes, sla, coleenp Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com hg commit will give: > Changeset: 4039:59e8c1010cc1 > Author: minqi > Date: 2013-01-24 17:22 > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. > Reviewed-by: dholmes, sla, coleenp > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com Invalid contributor attribution transaction abort! rollback completed note: commit message saved in .hg/last-message.txt abort: pretxncommit hook failed The same problem happened when I integrated 6830717 (C2 Replay by Tom). It complained like this message so I have to remove tom from the commit comment! Does any one know a workaround this? Thanks Yumin From yumin.qi at oracle.com Thu Jan 24 17:44:45 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 17:44:45 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: References: <5101DFAB.8000302@oracle.com> Message-ID: <5101E38D.5000609@oracle.com> removed my email. Still same: [jcheck ce5e03ccbf6b 2013-01-23 16:29:50 -0800] > Changeset: 4039:49f643e94319 > Author: minqi > Date: 2013-01-24 17:43 > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. > Reviewed-by: dholmes, sla, coleenp > Contributed-by: yunda.mly at taobao.com Invalid contributor attribution transaction abort! rollback completed On 1/24/2013 5:31 PM, Srinivas Ramakrishna wrote: > may be it can't parse two email addresses. Probably expecting a single > email address in contributed by line? > > -- ramki > > On Thu, Jan 24, 2013 at 5:28 PM, Yumin Qi > wrote: > > When I add > yunda.mly at taobao.com > in following comment: > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as > AFLBinaryTreeDictionary in vmStructs and in SA we still use old > name for that. FreeList now is a template based class which is not > reflect in SA type library. When SA does calculation of heap for > CMS, the former will cause failure to retrieve > BinaryTreeDictionary sine the rename. The later will fail > wherever it is used in SA. > Reviewed-by: dholmes, sla, coleenp > Contributed-by: yunda.mly at taobao.com > , yumin.qi at oracle.com > > > hg commit will give: > > > > Changeset: 4039:59e8c1010cc1 > > Author: minqi > > Date: 2013-01-24 17:22 > > > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > > Summary: BinaryTreeDictionary is typedef'ed as > AFLBinaryTreeDictionary in vmStructs and in SA we still use old > name for that. FreeList now is a template based class which is not > reflect in SA type library. When SA does calculation of heap for > CMS, the former will cause failure to retrieve > BinaryTreeDictionary sine the rename. The later will fail > wherever it is used in SA. > > Reviewed-by: dholmes, sla, coleenp > > Contributed-by: yunda.mly at taobao.com > , yumin.qi at oracle.com > > > Invalid contributor attribution > > transaction abort! > rollback completed > note: commit message saved in .hg/last-message.txt > abort: pretxncommit hook failed > > The same problem happened when I integrated 6830717 (C2 Replay by > Tom). It complained like this message so I have to remove tom from > the commit comment! Does any one know a workaround this? > > Thanks > Yumin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130124/aa5b6057/attachment-0001.html From mark.reinhold at oracle.com Thu Jan 24 17:44:45 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 24 Jan 2013 17:44:45 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: ysr1729@gmail.com; Thu, 24 Jan 2013 17:31:50 PST; Message-ID: <20130125014445.18D4B938@eggemoggin.niobe.net> 2013/1/24 17:31 -0800, ysr1729 at gmail.com: > may be it can't parse two email addresses. Probably expecting a single email > address in contributed by line? It can handle multiple addresses. Try removing the extra space before the first address, i.e., make it: Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com rather than: Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com - Mark From yumin.qi at oracle.com Thu Jan 24 17:51:37 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 17:51:37 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: <20130125014445.18D4B938@eggemoggin.niobe.net> References: <20130125014445.18D4B938@eggemoggin.niobe.net> Message-ID: <5101E529.4000506@oracle.com> Yes, no more than one leading space needed, also, the space between ',' and following email address is a must too. Very confusing. jcheck should ignore extra spaces. Thanks Yumin On 1/24/2013 5:44 PM, mark.reinhold at oracle.com wrote: > 2013/1/24 17:31 -0800, ysr1729 at gmail.com: >> may be it can't parse two email addresses. Probably expecting a single email >> address in contributed by line? > It can handle multiple addresses. Try removing the extra space before > the first address, i.e., make it: > > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > rather than: > > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > - Mark From ysr1729 at gmail.com Thu Jan 24 17:31:50 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 24 Jan 2013 17:31:50 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: <5101DFAB.8000302@oracle.com> References: <5101DFAB.8000302@oracle.com> Message-ID: may be it can't parse two email addresses. Probably expecting a single email address in contributed by line? -- ramki On Thu, Jan 24, 2013 at 5:28 PM, Yumin Qi wrote: > When I add > yunda.mly at taobao.com > in following comment: > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in > vmStructs and in SA we still use old name for that. FreeList now is a > template based class which is not reflect in SA type library. When SA does > calculation of heap for CMS, the former will cause failure to retrieve > BinaryTreeDictionary sine the rename. The later will fail wherever it is > used in SA. > Reviewed-by: dholmes, sla, coleenp > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > hg commit will give: > > > > Changeset: 4039:59e8c1010cc1 > > Author: minqi > > Date: 2013-01-24 17:22 > > > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > > Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary > in vmStructs and in SA we still use old name for that. FreeList now is a > template based class which is not reflect in SA type library. When SA does > calculation of heap for CMS, the former will cause failure to retrieve > BinaryTreeDictionary sine the rename. The later will fail wherever it is > used in SA. > > Reviewed-by: dholmes, sla, coleenp > > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > Invalid contributor attribution > > transaction abort! > rollback completed > note: commit message saved in .hg/last-message.txt > abort: pretxncommit hook failed > > The same problem happened when I integrated 6830717 (C2 Replay by Tom). It > complained like this message so I have to remove tom from the commit > comment! Does any one know a workaround this? > > Thanks > Yumin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130124/bc23fad9/attachment.html From tao.mao at oracle.com Thu Jan 24 18:26:23 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 24 Jan 2013 18:26:23 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: <5101E529.4000506@oracle.com> References: <20130125014445.18D4B938@eggemoggin.niobe.net> <5101E529.4000506@oracle.com> Message-ID: <5101ED4F.40704@oracle.com> Check out jcheck.py code http://hg.openjdk.java.net/code-tools/jcheck/dist/raw-file/tip/jcheck.py con_check = re.compile("Contributed-by: ((" + addr_pat + ")(, (" + addr_pat + "))*)$") jcheck can take multiple contributors (N >= 1) as long as you comply with the format. It's a good thing to have a format including spacing requirement. But the code probably should provide a more useful error message to correct its users. Tao On 1/24/13 5:51 PM, Yumin Qi wrote: > Yes, no more than one leading space needed, also, the space between > ',' and following email address is a must too. Very confusing. jcheck > should ignore extra spaces. > > Thanks > Yumin > > On 1/24/2013 5:44 PM, mark.reinhold at oracle.com wrote: >> 2013/1/24 17:31 -0800, ysr1729 at gmail.com: >>> may be it can't parse two email addresses. Probably expecting a >>> single email >>> address in contributed by line? >> It can handle multiple addresses. Try removing the extra space before >> the first address, i.e., make it: >> >> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >> >> rather than: >> >> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >> >> - Mark From coleen.phillimore at oracle.com Thu Jan 24 21:24:14 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 25 Jan 2013 05:24:14 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8006040: NPG: on_stack processing wastes space in ConstantPool Message-ID: <20130125052419.1E0F74754E@hg.openjdk.java.net> Changeset: 5daaddd917a1 Author: coleenp Date: 2013-01-23 10:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5daaddd917a1 8006040: NPG: on_stack processing wastes space in ConstantPool Summary: Added on_stack bit to flags. Also MetadataMarkOnStack is used for more than JVMTI so had to be moved. Reviewed-by: dholmes, stefank ! src/share/vm/classfile/classLoaderData.cpp + src/share/vm/classfile/metadataOnStackMark.cpp + src/share/vm/classfile/metadataOnStackMark.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp From david.holmes at oracle.com Thu Jan 24 22:07:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2013 16:07:01 +1000 Subject: Question of 'contributor' at hg commit In-Reply-To: <5101ED4F.40704@oracle.com> References: <20130125014445.18D4B938@eggemoggin.niobe.net> <5101E529.4000506@oracle.com> <5101ED4F.40704@oracle.com> Message-ID: <51022105.1010404@oracle.com> Also check out: http://openjdk.java.net/guide/producingChangeset.html#create I prefer the full form: Contributed-by: Ben Bitdiddle David On 25/01/2013 12:26 PM, Tao Mao wrote: > Check out jcheck.py code > http://hg.openjdk.java.net/code-tools/jcheck/dist/raw-file/tip/jcheck.py > > con_check = re.compile("Contributed-by: ((" + addr_pat + ")(, (" + > addr_pat + "))*)$") > > jcheck can take multiple contributors (N >= 1) as long as you comply > with the format. > > It's a good thing to have a format including spacing requirement. But > the code probably should provide a more useful error message to correct > its users. > > Tao > > On 1/24/13 5:51 PM, Yumin Qi wrote: >> Yes, no more than one leading space needed, also, the space between >> ',' and following email address is a must too. Very confusing. jcheck >> should ignore extra spaces. >> >> Thanks >> Yumin >> >> On 1/24/2013 5:44 PM, mark.reinhold at oracle.com wrote: >>> 2013/1/24 17:31 -0800, ysr1729 at gmail.com: >>>> may be it can't parse two email addresses. Probably expecting a >>>> single email >>>> address in contributed by line? >>> It can handle multiple addresses. Try removing the extra space before >>> the first address, i.e., make it: >>> >>> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >>> >>> rather than: >>> >>> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >>> >>> - Mark > From staffan.larsen at oracle.com Fri Jan 25 00:01:20 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Jan 2013 09:01:20 +0100 Subject: RFR (S): 8004172: Update jstat counter names to reflect metaspace changes In-Reply-To: <51017131.7040603@oracle.com> References: <51011226.9050509@oracle.com> <51017131.7040603@oracle.com> Message-ID: <25C8A64B-FEDF-4736-8CF1-02F1DE7E4FDC@oracle.com> Looks good! /Staffan On 24 jan 2013, at 18:36, Erik Helin wrote: > Hi Staffan, > > thanks for reviewing this! > > On 01/24/2013 01:27 PM, Staffan Larsen wrote: >> The JDK changes look good, but I think there is change needed in test/sun/tools/jstatd/jstatGcutilOutput1.awk as well. > > Yes, you are right. Please see an updated webrev at: > http://cr.openjdk.java.net/~ehelin/8004172/jdk/webrev.01/ > > Thanks, > Erik > >> Thanks, >> /Staffan >> >> On 24 jan 2013, at 11:51, Erik Helin wrote: >> >>> Hi all, >>> >>> here are the JDK changes for fixing JDK-8004172. This change updates the jstat resource file to use the new metaspace performance counters and also updates the tests. >>> >>> Note that the fixed tests will continue to fail until the HotSpot part of the change finds it way into the tl forest. >>> >>> The HotSpot part of the change is also out for review on hotspot-gc-dev at openjdk.java.net. >>> >>> Webrev: >>> JDK: http://cr.openjdk.java.net/~ehelin/8004172/jdk/webrev.00/ >>> HotSpot: http://cr.openjdk.java.net/~ehelin/8004172/hotspot/webrev.00/ >>> >>> Bug: >>> http://bugs.sun.com/view_bug.do?bug_id=8004172 >>> >>> Testing: >>> Run the jstat jtreg tests locally on my machine on a repository where I've applied both the JDK changes and the HotSpot changes. >>> >>> Thanks, >>> Erik >> > From luchsh at linux.vnet.ibm.com Fri Jan 25 01:09:13 2013 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Fri, 25 Jan 2013 09:09:13 +0000 Subject: hg: jdk8/tl/jdk: 7183373: URLClassloader.close() does not close JAR files whose resources have been loaded via getResource() Message-ID: <20130125090934.E627047555@hg.openjdk.java.net> Changeset: 4c9fcb5cbc07 Author: dingxmin Date: 2013-01-25 17:00 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c9fcb5cbc07 7183373: URLClassloader.close() does not close JAR files whose resources have been loaded via getResource() Reviewed-by: chegar ! src/share/classes/sun/misc/URLClassPath.java + test/sun/misc/URLClassPath/JarLoaderTest.java From yumin.qi at oracle.com Fri Jan 25 03:20:28 2013 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Fri, 25 Jan 2013 11:20:28 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8005278: Serviceability Agent: jmap -heap and jstack -m fail Message-ID: <20130125112032.D4D7C4755A@hg.openjdk.java.net> Changeset: 6cf2530f7fd3 Author: minqi Date: 2013-01-24 23:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6cf2530f7fd3 8005278: Serviceability Agent: jmap -heap and jstack -m fail Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. Reviewed-by: dholmes, sla, coleenp Contributed-by: yunda.mly at taobao.com + agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp From Alan.Bateman at oracle.com Fri Jan 25 05:09:29 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Jan 2013 13:09:29 +0000 Subject: 8006565: java.lang.instrument specification should make it clear that -javaagent is optional In-Reply-To: <50FD40CB.9000709@oracle.com> References: <50FD40CB.9000709@oracle.com> Message-ID: <51028409.3070706@oracle.com> On 21/01/2013 13:21, Alan Bateman wrote: > > The optionally of JVM TI is clear in its specification, the status of > java.lang.management, or more specifically the -javaagent option is > less clear. The change proposed here is to make it very clear that > -javaagent is not required to be supported. The motive is small > environments where it should not be necessary to have a way to start > tool agents even though there may be command-line support. > > Thanks, > > -Alan Just to say that there was additional feedback on the proposed wording. Attached is what I propose to push now. I don't think this requires any further reviews. -Alan diff --git a/src/share/classes/java/lang/instrument/package.html b/src/share/classes/java/lang/instrument/package.html --- a/src/share/classes/java/lang/instrument/package.html +++ b/src/share/classes/java/lang/instrument/package.html @@ -53,8 +53,10 @@

Command-Line Interface

-On implementations with a command-line interface, an agent is started by -adding this option to the command-line: +An implementation is not required to provide a way to start agents from the +command-line interface. On implementations that do provide a way to start agents +from the command-line interface, an agent is started by adding this option to +the command-line:

-javaagent:jarpath[=options]
From alan.bateman at oracle.com Fri Jan 25 05:11:51 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 25 Jan 2013 13:11:51 +0000 Subject: hg: jdk8/tl/jdk: 8006565: java.lang.instrument specification should make it clear that -javaagent is optional Message-ID: <20130125131214.C95A14755B@hg.openjdk.java.net> Changeset: 4a4b97f7f83b Author: alanb Date: 2013-01-25 13:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a4b97f7f83b 8006565: java.lang.instrument specification should make it clear that -javaagent is optional Reviewed-by: sla, dcubed, mchung ! src/share/classes/java/lang/instrument/package.html From coleen.phillimore at oracle.com Fri Jan 25 07:40:08 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 25 Jan 2013 10:40:08 -0500 Subject: Review Request: 8006506: Add test for redefining methods in backtraces to java/lang/instrument tests In-Reply-To: <50FE901F.4050806@oracle.com> References: <50FE901F.4050806@oracle.com> Message-ID: <5102A758.1000200@oracle.com> I think if you wait a week, you won't need to have it in the problem list. This test passes with my backtrace changes which were pushed to hotspot-main this week. The test looks great and was really helpful! Thanks!! Coleen On 1/22/2013 8:11 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8006506/webrev.00/ > > This test provokes the JVM crash described in bug: JDK-7174978. > > I intend to push this to: > http://hg.openjdk.java.net/jdk8/tl/jdk > > thanks, > StefanK > > From vincent.x.ryan at oracle.com Fri Jan 25 08:20:56 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 25 Jan 2013 16:20:56 +0000 Subject: hg: jdk8/tl/jdk: 8006946: PKCS12 test failure due to incorrect alias name Message-ID: <20130125162133.27CF94755F@hg.openjdk.java.net> Changeset: c6ea84a629db Author: vinnie Date: 2013-01-25 16:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6ea84a629db 8006946: PKCS12 test failure due to incorrect alias name Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java From vincent.x.ryan at oracle.com Fri Jan 25 09:51:33 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 25 Jan 2013 17:51:33 +0000 Subject: hg: jdk8/tl/jdk: 8006951: Avoid storing duplicate PKCS12 attributes Message-ID: <20130125175154.6083347570@hg.openjdk.java.net> Changeset: 117491dd58c2 Author: vinnie Date: 2013-01-25 17:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/117491dd58c2 8006951: Avoid storing duplicate PKCS12 attributes Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java From kurchi.subhra.hazra at oracle.com Fri Jan 25 11:44:38 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Fri, 25 Jan 2013 19:44:38 +0000 Subject: hg: jdk8/tl/jdk: 7017962: Obsolete link is used in URL class level spec Message-ID: <20130125194502.E68CD47578@hg.openjdk.java.net> Changeset: 77bde15bc6a9 Author: khazra Date: 2013-01-25 11:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77bde15bc6a9 7017962: Obsolete link is used in URL class level spec Summary: Change the link to an archived document Reviewed-by: chegar, mduigou ! src/share/classes/java/net/URL.java From zhengyu.gu at oracle.com Fri Jan 25 13:40:55 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Fri, 25 Jan 2013 21:40:55 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8000692: Remove old KERNEL code Message-ID: <20130125214059.13DBC4757F@hg.openjdk.java.net> Changeset: 8b46b0196eb0 Author: zgu Date: 2013-01-25 10:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8b46b0196eb0 8000692: Remove old KERNEL code Summary: Removed depreciated kernel VM source code from hotspot VM Reviewed-by: dholmes, acorn ! make/Makefile ! make/bsd/makefiles/dtrace.make ! make/solaris/Makefile ! make/solaris/makefiles/dtrace.make - make/solaris/makefiles/kernel.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/defs.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.hpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExtensions.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRawMonitor.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp From yumin.qi at oracle.com Fri Jan 25 17:20:25 2013 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Sat, 26 Jan 2013 01:20:25 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20130126012032.C2F3C47589@hg.openjdk.java.net> Changeset: edd76a5856f7 Author: sspitsyn Date: 2013-01-24 22:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/edd76a5856f7 8005128: JSR 292: the mlvm redefineClassInBootstrap test crashes in ConstantPool::compare_entry_to Summary: When constant pool is copied in merge_constant_pools the invokedynamic operands must be copied before. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4a0dd3799a44 Author: minqi Date: 2013-01-25 04:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4a0dd3799a44 Merge Changeset: 8d1fb417a42d Author: minqi Date: 2013-01-25 13:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8d1fb417a42d Merge ! src/share/vm/prims/jvmtiRedefineClasses.cpp From mike.duigou at oracle.com Fri Jan 25 20:33:53 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 26 Jan 2013 04:33:53 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130126043437.BAFC04758E@hg.openjdk.java.net> Changeset: 4209b3936a7f Author: mduigou Date: 2013-01-25 16:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4209b3936a7f 8005632: Extend java.util.Logger to use Supplier for messages Reviewed-by: briangoetz, mduigou Contributed-by: henry.jen at oracle.com ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/LoggerSupplierAPIsTest.java Changeset: 1d918647332e Author: mduigou Date: 2013-01-25 16:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d918647332e 8004201: Add static utility methods to primitives to be used for redution operations. Reviewed-by: darcy, mduigou, briangoetz, dholmes Contributed-by: akhil.arora at oracle.com ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java + test/java/lang/PrimitiveSumMinMaxTest.java Changeset: 86a5b435c928 Author: jgish Date: 2013-01-22 11:14 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86a5b435c928 4247235: (spec str) StringBuffer.insert(int, char[]) specification is inconsistent Summary: Add blanket null-handling statement to StringBuilder and StringBuffer Reviewed-by: mduigou ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java From alan.bateman at oracle.com Sat Jan 26 09:00:28 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 26 Jan 2013 17:00:28 +0000 Subject: hg: jdk8/tl/jdk: 8006503: JVM_PrintStackTrace is not used in JDK Message-ID: <20130126170117.3D2F647594@hg.openjdk.java.net> Changeset: e96577d82cbb Author: alanb Date: 2013-01-26 16:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e96577d82cbb 8006503: JVM_PrintStackTrace is not used in JDK Reviewed-by: alanb, darcy Contributed-by: eric.mccorkle at oracle.com ! src/share/javavm/export/jvm.h From karen.kinnear at oracle.com Sun Jan 27 21:16:57 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Mon, 28 Jan 2013 05:16:57 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 13 new changesets Message-ID: <20130128051723.54DDF475AE@hg.openjdk.java.net> Changeset: 7df93f7c14a5 Author: brutisso Date: 2013-01-16 12:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7df93f7c14a5 8006242: G1: WorkerDataArray::verify() too strict for double calculations Summary: Also reviewed by vitalyd at gmail.com. Reviewed-by: johnc, mgerdin ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp Changeset: bf8c2b2c8cfa Author: mgerdin Date: 2013-01-22 13:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bf8c2b2c8cfa 8004147: test/Makefile jtreg_tests target does not work with cygwin Reviewed-by: ctornqvi, brutisso ! test/Makefile Changeset: d754ef7b9352 Author: jmasa Date: 2013-01-24 06:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d754ef7b9352 Merge Changeset: a7114d3d712e Author: kvn Date: 2013-01-22 11:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a7114d3d712e 8005055: pass outputStream to more opto debug routines Summary: pass the output stream to node->dump() and everything reachable from there Reviewed-by: kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp Changeset: b30b3c2a0cf2 Author: kvn Date: 2013-01-22 15:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b30b3c2a0cf2 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 Summary: Use SSE4.2 and AVX2 instructions for encodeArray intrinsic. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/6896617/Test6896617.java Changeset: 522c328b8b77 Author: kvn Date: 2013-01-23 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/522c328b8b77 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 Summary: Limit vectors size to 16 bytes on BSD until the problem is fixed Reviewed-by: twisti ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: 22ead76da3f4 Author: kmo Date: 2013-01-24 02:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/22ead76da3f4 8006758: LinkResolver assertion (caused by @Contended changes) Summary: treat anonymous classes as privileged code to restore the special handling for @Compiled during class file parsing Reviewed-by: jrose, coleenp, kvn, dholmes ! src/share/vm/classfile/classFileParser.cpp Changeset: 274a29bf5682 Author: kmo Date: 2013-01-24 09:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/274a29bf5682 Merge Changeset: 89fc17e8d808 Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/89fc17e8d808 Added tag jdk8-b74 for changeset 1a3e54283c54 ! .hgtags Changeset: b4391649e91e Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b4391649e91e Merge ! .hgtags Changeset: 6778d0b16593 Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6778d0b16593 Added tag hs25-b17 for changeset b4391649e91e ! .hgtags Changeset: 6fbe8a57549d Author: amurillo Date: 2013-01-25 03:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6fbe8a57549d 8006827: new hotspot build - hs25-b18 Reviewed-by: jcoomes ! make/hotspot_version Changeset: cf8470eaf7e5 Author: acorn Date: 2013-01-27 21:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cf8470eaf7e5 Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp From vicente.romero at oracle.com Mon Jan 28 00:55:35 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 28 Jan 2013 08:55:35 +0000 Subject: hg: jdk8/tl/langtools: 8006944: javac, combo tests should print out the number of threads used Message-ID: <20130128085542.628DD475B4@hg.openjdk.java.net> Changeset: cbcd9b484759 Author: vromero Date: 2013-01-27 19:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cbcd9b484759 8006944: javac, combo tests should print out the number of threads used Reviewed-by: mcimadamore ! test/tools/javac/lib/JavacTestingAbstractThreadedTest.java From stefan.karlsson at oracle.com Mon Jan 28 01:32:19 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 28 Jan 2013 10:32:19 +0100 Subject: Review Request: 8006506: Add test for redefining methods in backtraces to java/lang/instrument tests In-Reply-To: <5102A758.1000200@oracle.com> References: <50FE901F.4050806@oracle.com> <5102A758.1000200@oracle.com> Message-ID: <510645A3.3000104@oracle.com> On 01/25/2013 04:40 PM, Coleen Phillimore wrote: > > I think if you wait a week, you won't need to have it in the problem > list. > This test passes with my backtrace changes which were pushed to > hotspot-main this week. > The test looks great and was really helpful! OK. I'll wait for your fix to propagate up to jdk8/tl. thanks, StefanK > > Thanks!! > Coleen > > On 1/22/2013 8:11 AM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8006506/webrev.00/ >> >> This test provokes the JVM crash described in bug: JDK-7174978. >> >> I intend to push this to: >> http://hg.openjdk.java.net/jdk8/tl/jdk >> >> thanks, >> StefanK >> >> From markus.gronlund at oracle.com Mon Jan 28 07:13:34 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Mon, 28 Jan 2013 07:13:34 -0800 (PST) Subject: RFR:(S) JEP 167 tracing gives negative time stamps for certain event fields Message-ID: Hi, ? Kindly asking for reviews and putback sponsorship for the following change: ? Bugid: https://jbs.oracle.com/bugs/browse/JDK-8007005 ? Webrev: http://cr.openjdk.java.net/~mgronlun/8007005/webrev01/ ? Thank you Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130128/d11999b9/attachment.html From erik.helin at oracle.com Mon Jan 28 07:23:29 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 28 Jan 2013 16:23:29 +0100 Subject: RFR (S): 8004172: Update jstat counter names to reflect metaspace changes In-Reply-To: <25C8A64B-FEDF-4736-8CF1-02F1DE7E4FDC@oracle.com> References: <51011226.9050509@oracle.com> <51017131.7040603@oracle.com> <25C8A64B-FEDF-4736-8CF1-02F1DE7E4FDC@oracle.com> Message-ID: <510697F1.8040808@oracle.com> Jon Masamitsu suggested that the "sun.rt" namespace should be used instead of the "sun.gc" namespace. I've updated both the jdk and the hotspot code based on this suggestion. New webrevs: - hotspot: http://cr.openjdk.java.net/~ehelin/8004172/hotspot/webrev.01/ - jdk: http://cr.openjdk.java.net/~ehelin/8004172/jdk/webrev.02/ Thanks, Erik On 01/25/2013 09:01 AM, Staffan Larsen wrote: > Looks good! > > /Staffan > > On 24 jan 2013, at 18:36, Erik Helin wrote: > >> Hi Staffan, >> >> thanks for reviewing this! >> >> On 01/24/2013 01:27 PM, Staffan Larsen wrote: >>> The JDK changes look good, but I think there is change needed in test/sun/tools/jstatd/jstatGcutilOutput1.awk as well. >> >> Yes, you are right. Please see an updated webrev at: >> http://cr.openjdk.java.net/~ehelin/8004172/jdk/webrev.01/ >> >> Thanks, >> Erik >> >>> Thanks, >>> /Staffan >>> >>> On 24 jan 2013, at 11:51, Erik Helin wrote: >>> >>>> Hi all, >>>> >>>> here are the JDK changes for fixing JDK-8004172. This change updates the jstat resource file to use the new metaspace performance counters and also updates the tests. >>>> >>>> Note that the fixed tests will continue to fail until the HotSpot part of the change finds it way into the tl forest. >>>> >>>> The HotSpot part of the change is also out for review on hotspot-gc-dev at openjdk.java.net. >>>> >>>> Webrev: >>>> JDK: http://cr.openjdk.java.net/~ehelin/8004172/jdk/webrev.00/ >>>> HotSpot: http://cr.openjdk.java.net/~ehelin/8004172/hotspot/webrev.00/ >>>> >>>> Bug: >>>> http://bugs.sun.com/view_bug.do?bug_id=8004172 >>>> >>>> Testing: >>>> Run the jstat jtreg tests locally on my machine on a repository where I've applied both the JDK changes and the HotSpot changes. >>>> >>>> Thanks, >>>> Erik >>> >> > From karen.kinnear at oracle.com Mon Jan 28 09:16:28 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Mon, 28 Jan 2013 17:16:28 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130128171635.89489475BC@hg.openjdk.java.net> Changeset: 16fb9f942703 Author: acorn Date: 2013-01-25 15:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16fb9f942703 6479360: PrintClassHistogram improvements Summary: jcmd GC.class_stats (UnlockDiagnosticVMOptions) Reviewed-by: coleenp, hseigel, sla, acorn Contributed-by: ioi.lam at oracle.com ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: 0d26ce8e9251 Author: acorn Date: 2013-01-28 10:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0d26ce8e9251 Merge - make/solaris/makefiles/kernel.make ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp From karen.kinnear at oracle.com Mon Jan 28 10:42:44 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Mon, 28 Jan 2013 18:42:44 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130128184249.06C9C475C2@hg.openjdk.java.net> Changeset: 815957d0203e Author: acorn Date: 2013-01-28 10:55 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/815957d0203e 8004967: Default method cause VerifyError: Illegal use of nonvirtual Summary: Recognize VM generated method in old verifier Reviewed-by: acorn, coleenp Contributed-by: bharadwaj.yadavelli at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 7885e162c30f Author: acorn Date: 2013-01-28 09:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7885e162c30f Merge From serguei.spitsyn at oracle.com Mon Jan 28 14:18:03 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Jan 2013 14:18:03 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <5101DEAE.9000404@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> <5101BC24.1020905@oracle.com> <5101C9EC.6060608@oracle.com> <5101DEAE.9000404@oracle.com> Message-ID: <5106F91B.4040900@oracle.com> Hi Coleen, This is a new webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.2/ As you pointed out, the InvokeDynamic entry support should also do cross-checks with the bootstrap method operands (arguments) and recursive extra appends if necessary. I've filed a separate bug to track this issue: https://jbs.oracle.com/bugs/browse/JDK-8007037 I want to separate this issue to be able to integrate what I have now and concentrate on the rest later. The VM SQE team developed new INDY tests that cover the RedefineClasses issues. I hope to adopt and use new tests soon to make sure most of the issues are actually resolved. Thanks, Serguei On 1/24/13 5:23 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > > Thank you a lot for the review! > > On 1/24/13 3:55 PM, Coleen Phillimore wrote: >> >> Hi Serguei, >> >> Putting functions in alphabetical order seems silly, it's better to >> have utility functions directly above (or below) the function that >> calls them. I'd take out the comment. >> >> I have started looking at this code a bit. This function >> find_or_append_indirect_entry() should be used for the other indirect >> entries also, shouldn't it? The code looks familiar to the inside of >> the case statement to FieldRef, InterfaceRef and MethodRef. > > You've got it right. > Yes, I noticed it but did not want to mess with it until it is proven > to work well. > My plan was to fix it for the FieldRef, InterfaceRef and MethodRef in > a next round of fixes. > >> >> Also is boot_spec an indirect index too that has to be appended? >> >> 564 int boot_spec = >> scratch_cp->invoke_dynamic_bootstrap_method_ref_index_at(scratch_i); > > This is a nice catch, will fix it. > I thought, it is an index into the operands array, but it refers to a > CONSTANT_MethodHandle element. > > > Thanks, > Serguei > > >> >> >> Thanks, >> Coleen >> >> On 01/24/2013 05:56 PM, serguei.spitsyn at oracle.com wrote: >>> Christian, >>> >>> >>> Thank you a lot for the review! >>> >>> Nice catch with the ordering. >>> In fact, I tried to follow the order but missed that the >>> find_new_index should go first. :) >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 1/24/13 2:14 PM, Christian Thalinger wrote: >>>> On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>>> Please, review the fix for: >>>>> https://jbs.oracle.com/bugs/browse/JDK-8006542 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ >>>>> >>>> src/share/vm/prims/jvmtiRedefineClasses.hpp: >>>> >>>> + // Support for constant pool merging (these routines are in >>>> alpha order): >>>> void append_entry(constantPoolHandle scratch_cp, int scratch_i, >>>> constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>>> + int find_or_append_indirect_entry(constantPoolHandle scratch_cp, >>>> int scratch_i, >>>> + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>>> int find_new_index(int old_index); >>>> >>>> Not really alpha order ;-) >>>> >>>> Otherwise this looks good (as far as I can tell). >>>> >>>> -- Chris >>>> >>>>> Summary: >>>>> Need a support for invokedynamic entry kinds when new and old >>>>> constant pools are merged. >>>>> >>>>> Testing: >>>>> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >>>>> Asked the VM SQE team to develop new INDY tests for better >>>>> coverage. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>> >> > From serguei.spitsyn at oracle.com Mon Jan 28 14:33:43 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Jan 2013 14:33:43 -0800 Subject: Review Request (XS) 8006546: JSR 292: typos in the ConstantPool::copy_cp_impl() In-Reply-To: <50F71FB2.4020702@oracle.com> References: <50F71FB2.4020702@oracle.com> Message-ID: <5106FCC7.4050201@oracle.com> Please, review the fix for (it was already reviewed by Christian): https://jbs.oracle.com/bugs/browse/JDK-8006546 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006546-JVMTI-JSR292.0 Summary: The copy_operands() does the same copy frrom dest cpool twice in two places. Instead, it must copy once from dest and once from source cpool. It would make it consistent with the comments. Testing: nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist, vm/mlvm/indy/func/jvmti/redefineClassInBootstrap Thanks, Serguei From serguei.spitsyn at oracle.com Mon Jan 28 14:33:57 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Jan 2013 14:33:57 -0800 Subject: Review Request (XS) 8006731: JSR 292: the VM_RedefineClasses::rewrite_cp_refs_in_method() must support invokedynamic In-Reply-To: <50F71FB2.4020702@oracle.com> References: <50F71FB2.4020702@oracle.com> Message-ID: <5106FCD5.804@oracle.com> Please, review the fix for (it was already reviewed by Christian): https://jbs.oracle.com/bugs/browse/JDK-8006731 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006731-JVMTI-JSR292.0 Summary: The invokedynamic bytecode ref to a CP entry needs to be checked and fixed as well. Take the interpreter/rewrite.cpp::Rewriter::rewrite_invokedynamic() as an example. Testing: nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist, vm/mlvm/indy/func/jvmti/redefineClassInBootstrap Thanks, Serguei From coleen.phillimore at oracle.com Mon Jan 28 15:55:14 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 28 Jan 2013 18:55:14 -0500 Subject: Review Request (XS) 8006546: JSR 292: typos in the ConstantPool::copy_cp_impl() In-Reply-To: <5106FCC7.4050201@oracle.com> References: <50F71FB2.4020702@oracle.com> <5106FCC7.4050201@oracle.com> Message-ID: <51070FE2.1020804@oracle.com> This looks good. I assume that this is tested with the mlvm nsk tests? Thanks, Coleen On 1/28/2013 5:33 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for (it was already reviewed by Christian): > https://jbs.oracle.com/bugs/browse/JDK-8006546 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006546-JVMTI-JSR292.0 > > > > Summary: > The copy_operands() does the same copy frrom dest cpool twice in two > places. > Instead, it must copy once from dest and once from source cpool. > It would make it consistent with the comments. > > > Testing: nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist, > vm/mlvm/indy/func/jvmti/redefineClassInBootstrap > > > Thanks, > Serguei > > From serguei.spitsyn at oracle.com Mon Jan 28 16:24:04 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Jan 2013 16:24:04 -0800 Subject: Review Request (XS) 8006546: JSR 292: typos in the ConstantPool::copy_cp_impl() In-Reply-To: <51070FE2.1020804@oracle.com> References: <50F71FB2.4020702@oracle.com> <5106FCC7.4050201@oracle.com> <51070FE2.1020804@oracle.com> Message-ID: <510716A4.4090107@oracle.com> Thanks! In fact, I did not test it with all the mlvm nsk tests, but agreed it is worth to do. I'll run the mlvm tests before the integration. Thanks, Serguei On 1/28/13 3:55 PM, Coleen Phillimore wrote: > > This looks good. I assume that this is tested with the mlvm nsk tests? > Thanks, > Coleen > > On 1/28/2013 5:33 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for (it was already reviewed by Christian): >> https://jbs.oracle.com/bugs/browse/JDK-8006546 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006546-JVMTI-JSR292.0 >> >> >> >> Summary: >> The copy_operands() does the same copy frrom dest cpool twice in >> two places. >> Instead, it must copy once from dest and once from source cpool. >> It would make it consistent with the comments. >> >> >> Testing: nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist, >> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >> >> >> Thanks, >> Serguei >> >> From serguei.spitsyn at oracle.com Mon Jan 28 20:28:51 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Jan 2013 20:28:51 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <5106F91B.4040900@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> <5101BC24.1020905@oracle.com> <5101C9EC.6060608@oracle.com> <5101DEAE.9000404@oracle.com> <5106F91B.4040900@oracle.com> Message-ID: <51075003.9000307@oracle.com> Coleen, This is a version with a refactoring you requested: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.3/ Now, the NameAndType, FieldRef, InterfaceMethodRef and MethodRef use the find_or_append_indirect_entry(). Thanks, Serguei On 1/28/13 2:18 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > > This is a new webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.2/ > > > As you pointed out, the InvokeDynamic entry support should also do > cross-checks with > the bootstrap method operands (arguments) and recursive extra appends > if necessary. > > I've filed a separate bug to track this issue: > https://jbs.oracle.com/bugs/browse/JDK-8007037 > > I want to separate this issue to be able to integrate what I have now > and concentrate on the rest later. > The VM SQE team developed new INDY tests that cover the > RedefineClasses issues. > I hope to adopt and use new tests soon to make sure most of the issues > are actually resolved. > > > Thanks, > Serguei > > > On 1/24/13 5:23 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> >> Thank you a lot for the review! >> >> On 1/24/13 3:55 PM, Coleen Phillimore wrote: >>> >>> Hi Serguei, >>> >>> Putting functions in alphabetical order seems silly, it's better to >>> have utility functions directly above (or below) the function that >>> calls them. I'd take out the comment. >>> >>> I have started looking at this code a bit. This function >>> find_or_append_indirect_entry() should be used for the other >>> indirect entries also, shouldn't it? The code looks familiar to the >>> inside of the case statement to FieldRef, InterfaceRef and MethodRef. >> >> You've got it right. >> Yes, I noticed it but did not want to mess with it until it is proven >> to work well. >> My plan was to fix it for the FieldRef, InterfaceRef and MethodRef in >> a next round of fixes. >> >>> >>> Also is boot_spec an indirect index too that has to be appended? >>> >>> 564 int boot_spec = >>> scratch_cp->invoke_dynamic_bootstrap_method_ref_index_at(scratch_i); >> >> This is a nice catch, will fix it. >> I thought, it is an index into the operands array, but it refers to a >> CONSTANT_MethodHandle element. >> >> >> Thanks, >> Serguei >> >> >>> >>> >>> Thanks, >>> Coleen >>> >>> On 01/24/2013 05:56 PM, serguei.spitsyn at oracle.com wrote: >>>> Christian, >>>> >>>> >>>> Thank you a lot for the review! >>>> >>>> Nice catch with the ordering. >>>> In fact, I tried to follow the order but missed that the >>>> find_new_index should go first. :) >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 1/24/13 2:14 PM, Christian Thalinger wrote: >>>>> On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>>> Please, review the fix for: >>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006542 >>>>>> >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ >>>>>> >>>>> src/share/vm/prims/jvmtiRedefineClasses.hpp: >>>>> >>>>> + // Support for constant pool merging (these routines are in >>>>> alpha order): >>>>> void append_entry(constantPoolHandle scratch_cp, int scratch_i, >>>>> constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>>>> + int find_or_append_indirect_entry(constantPoolHandle >>>>> scratch_cp, int scratch_i, >>>>> + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>>>> int find_new_index(int old_index); >>>>> >>>>> Not really alpha order ;-) >>>>> >>>>> Otherwise this looks good (as far as I can tell). >>>>> >>>>> -- Chris >>>>> >>>>>> Summary: >>>>>> Need a support for invokedynamic entry kinds when new and old >>>>>> constant pools are merged. >>>>>> >>>>>> Testing: >>>>>> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >>>>>> Asked the VM SQE team to develop new INDY tests for better >>>>>> coverage. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>> >>> >> > From joel.franck at oracle.com Tue Jan 29 01:38:02 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 29 Jan 2013 09:38:02 +0000 Subject: hg: jdk8/tl/jdk: 8004698: Implement Core Reflection for Type Annotations Message-ID: <20130129093814.3EF4A4763E@hg.openjdk.java.net> Changeset: a343d280bd8c Author: jfranck Date: 2013-01-29 10:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a343d280bd8c 8004698: Implement Core Reflection for Type Annotations Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java + src/share/classes/java/lang/reflect/AnnotatedArrayType.java + src/share/classes/java/lang/reflect/AnnotatedParameterizedType.java + src/share/classes/java/lang/reflect/AnnotatedType.java + src/share/classes/java/lang/reflect/AnnotatedTypeVariable.java + src/share/classes/java/lang/reflect/AnnotatedWildcardType.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/java/lang/reflect/TypeVariable.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/LangReflectAccess.java ! src/share/classes/sun/reflect/ReflectionFactory.java + src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java + src/share/classes/sun/reflect/annotation/TypeAnnotation.java + src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/Class.c + test/java/lang/annotation/TypeAnnotationReflection.java + test/java/lang/annotation/TypeParamAnnotation.java From markus.gronlund at oracle.com Tue Jan 29 04:09:36 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Tue, 29 Jan 2013 04:09:36 -0800 (PST) Subject: FW: RFR:(S) JEP 167 tracing gives negative time stamps for certain event fields Message-ID: <315e65bc-85f4-4f08-831e-e7efcdaeb5b8@default> Hi again, ? Kindly asking for reviews and putback sponsorship for the following change: ? Bugid: https://jbs.oracle.com/bugs/browse/JDK-8007005 ? (updated webrev) Webrev: http://cr.openjdk.java.net/~mgronlun/8007005/webrev02/ ? Thank you Markus ? ? ? From: Markus Gr?nlund Sent: den 28 januari 2013 16:14 To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RFR:(S) JEP 167 tracing gives negative time stamps for certain event fields -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130129/d28c5be4/attachment.html From rickard.backman at oracle.com Tue Jan 29 04:23:44 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Tue, 29 Jan 2013 13:23:44 +0100 Subject: RFR:(S) JEP 167 tracing gives negative time stamps for certain event fields In-Reply-To: <315e65bc-85f4-4f08-831e-e7efcdaeb5b8@default> References: <315e65bc-85f4-4f08-831e-e7efcdaeb5b8@default> Message-ID: <433B38B3-8C04-489C-89F7-021563895F14@oracle.com> Markus, the change looks good! /R On Jan 29, 2013, at 1:09 PM, Markus Gr?nlund wrote: > Hi again, > > Kindly asking for reviews and putback sponsorship for the following change: > > Bugid: https://jbs.oracle.com/bugs/browse/JDK-8007005 > > (updated webrev) > Webrev: http://cr.openjdk.java.net/~mgronlun/8007005/webrev02/ > > Thank you > Markus > > > > From: Markus Gr?nlund > Sent: den 28 januari 2013 16:14 > To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: RFR:(S) JEP 167 tracing gives negative time stamps for certain event fields From bengt.rutisson at oracle.com Tue Jan 29 05:05:07 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 29 Jan 2013 14:05:07 +0100 Subject: FW: RFR:(S) JEP 167 tracing gives negative time stamps for certain event fields In-Reply-To: <315e65bc-85f4-4f08-831e-e7efcdaeb5b8@default> References: <315e65bc-85f4-4f08-831e-e7efcdaeb5b8@default> Message-ID: <5107C903.7060408@oracle.com> Hi Markus, Looks good to me. Thanks, Bengt On 1/29/13 1:09 PM, Markus Gr?nlund wrote: > > Hi again, > > Kindly asking for reviews and putback sponsorship for the following > change: > > Bugid: https://jbs.oracle.com/bugs/browse/JDK-8007005 > > (updated webrev) > > Webrev: http://cr.openjdk.java.net/~mgronlun/8007005/webrev02/ > > > Thank you > > Markus > > *From:*Markus Gr?nlund > *Sent:* den 28 januari 2013 16:14 > *To:* serviceability-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net > *Subject:* RFR:(S) JEP 167 tracing gives negative time stamps for > certain event fields > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130129/2e6d80e1/attachment.html From markus.gronlund at oracle.com Wed Jan 30 04:16:15 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 30 Jan 2013 04:16:15 -0800 (PST) Subject: RFR(XXS): 8007134: Enable tracing asserts on missing ResourceMark Message-ID: Greetings, ? Asking for review and sponsoring of this very simple change: ? Bugid: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007134 ? Webrev: http://cr.openjdk.java.net/~mgronlun/8007134/webrev01/ ? Cheers Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130130/c2d72aa1/attachment.html From rickard.backman at oracle.com Wed Jan 30 06:40:39 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 30 Jan 2013 15:40:39 +0100 Subject: 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: <51092A24.6050009@oracle.com> References: <5107D8F7.4040308@oracle.com> <51092A24.6050009@oracle.com> Message-ID: Katja, I think the change looks good. However we need to find an official reviewer before we can push this. Can we get an official reviewer to look on this change please? Thanks /R On Jan 30, 2013, at 3:11 PM, Yekaterina Kantserova wrote: > Hi everyone, > > In the previous mail I've referred to already existing BUG number, which was wrong. Here comes the webrev referred to the new BUG > > http://cr.openjdk.java.net/~ykantser/8007142/webrev.00/ > > Thanks, > Katja > > -------- Original Message -------- > Subject: 8006413: Add utility classes for writing better multiprocess tests in jtreg > Date: Tue, 29 Jan 2013 15:13:11 +0100 > From: Yekaterina Kantserova > To: core-libs-dev at openjdk.java.net > CC: jfr_dev_ww_grp > > Hi everyone, > > Christian T?rnqvist has done a great job to make it easier to run > multi-process tests in jtreg. His webrev > ( > http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.03/ > ) is > already approved and on the way into the hotspot repo. > > This webrev > http://cr.openjdk.java.net/~ykantser/8006413/webrev.00/ > is > for putting these utility classes into the jdk repo. I'm going to use > them for the JFR testing in the first hand. > > The webrev is almost a copy of Christian's except JcmdBase.java, utility > class for starting jcmd, and some extra methods in OutputAnalyzer.java. > > Thanks, > Katja > > From markus.gronlund at oracle.com Wed Jan 30 07:08:22 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 30 Jan 2013 07:08:22 -0800 (PST) Subject: RFR(XXS): 8007084: EnableTracing asserts in non-product builds Message-ID: <44e72377-2fba-45d1-a4f1-07aa4d274475@default> Greetings, ? Asking for review and putback sponsorship for the following very simple fix: ? Bugid: ?http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007084 Webrev: http://cr.openjdk.java.net/~mgronlun/8007084/webrev01/ ? Comment: The effect of this fix is that stringStream will now always assign a valid timestamp upon constructing its outputStream. The impact of this is considered to be minimal. I elaborated with adding additional constructors to stringStream with options for enabling timestamping, but this proved cumbersome, there is already a default constructor taking a size_t for initial size. In addition, adding new constructors would mean chasing down the oop::print_string, oop::print_on, oop::print_value_on chains and updating all stringStream alloc sites. Since the timestamp field is already in outputStream, I made this tradeoff for this bugfix instead - which I believe will have little impact in practice. ? Cheers Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130130/aeb74de8/attachment.html From jonathan.gibbons at oracle.com Wed Jan 30 09:41:27 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 30 Jan 2013 17:41:27 +0000 Subject: hg: jdk8/tl/langtools: 8007096: DocLint parsing problems with some comments Message-ID: <20130130174132.C765D476AD@hg.openjdk.java.net> Changeset: 950d8195a5a4 Author: jjg Date: 2013-01-30 09:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/950d8195a5a4 8007096: DocLint parsing problems with some comments Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java + test/tools/doclint/EndWithIdentifierTest.java + test/tools/doclint/EndWithIdentifierTest.out + test/tools/doclint/UnfinishedInlineTagTest.java + test/tools/doclint/UnfinishedInlineTagTest.out From jonathan.gibbons at oracle.com Wed Jan 30 09:47:45 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 30 Jan 2013 17:47:45 +0000 Subject: hg: jdk8/tl/langtools: 8007034: debug printer for javac internals Message-ID: <20130130174748.46FE4476AE@hg.openjdk.java.net> Changeset: c924291865e5 Author: jjg Date: 2013-01-30 09:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c924291865e5 8007034: debug printer for javac internals Reviewed-by: mcimadamore + test/tools/javac/lib/DPrinter.java From martinrb at google.com Wed Jan 30 12:36:20 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 30 Jan 2013 12:36:20 -0800 Subject: 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <5107D8F7.4040308@oracle.com> <51092A24.6050009@oracle.com> Message-ID: I don't have time for a detailed review, but I have some high-level comments. A lot of this is good functionality that should be provided in the jdk proper, notably getting process ids and manipulating process output (a higher level interface to ProcessBuilder). See the test ProcessBuilder/Basic for previous work by myself. Source files need to be newline-terminated. is so 1990s. Use {@code instead. Do you really need test.jdk to find yourself? Why not use java.home, which is always present? On Wed, Jan 30, 2013 at 6:40 AM, Rickard B?ckman wrote: > Katja, > > I think the change looks good. > However we need to find an official reviewer before we can push this. > > Can we get an official reviewer to look on this change please? > > Thanks > /R > > On Jan 30, 2013, at 3:11 PM, Yekaterina Kantserova wrote: > > > Hi everyone, > > > > In the previous mail I've referred to already existing BUG number, which > was wrong. Here comes the webrev referred to the new BUG > > > > http://cr.openjdk.java.net/~ykantser/8007142/webrev.00/ > > > > Thanks, > > Katja > > > > -------- Original Message -------- > > Subject: 8006413: Add utility classes for writing better > multiprocess tests in jtreg > > Date: Tue, 29 Jan 2013 15:13:11 +0100 > > From: Yekaterina Kantserova > > To: core-libs-dev at openjdk.java.net > > CC: jfr_dev_ww_grp > > > > Hi everyone, > > > > Christian T?rnqvist has done a great job to make it easier to run > > multi-process tests in jtreg. His webrev > > ( > > http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.03/ > > ) is > > already approved and on the way into the hotspot repo. > > > > This webrev > > http://cr.openjdk.java.net/~ykantser/8006413/webrev.00/ > > is > > for putting these utility classes into the jdk repo. I'm going to use > > them for the JFR testing in the first hand. > > > > The webrev is almost a copy of Christian's except JcmdBase.java, utility > > class for starting jcmd, and some extra methods in OutputAnalyzer.java. > > > > Thanks, > > Katja > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130130/f7e89b15/attachment.html From martinrb at google.com Wed Jan 30 12:37:45 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 30 Jan 2013 12:37:45 -0800 Subject: 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <5107D8F7.4040308@oracle.com> <51092A24.6050009@oracle.com> Message-ID: [ email address fail: JDK-CORE-LIBS-DEV_WW_GRP at oracle.com] On Wed, Jan 30, 2013 at 12:36 PM, Martin Buchholz wrote: > I don't have time for a detailed review, but I have some high-level > comments. > > A lot of this is good functionality that should be provided in the jdk > proper, > notably getting process ids and manipulating process output (a higher > level interface to ProcessBuilder). See the test ProcessBuilder/Basic for > previous work by myself. > > Source files need to be newline-terminated. > > is so 1990s. Use {@code instead. > > Do you really need test.jdk to find yourself? Why not use java.home, > which is always present? > > > On Wed, Jan 30, 2013 at 6:40 AM, Rickard B?ckman < > rickard.backman at oracle.com> wrote: > >> Katja, >> >> I think the change looks good. >> However we need to find an official reviewer before we can push this. >> >> Can we get an official reviewer to look on this change please? >> >> Thanks >> /R >> >> On Jan 30, 2013, at 3:11 PM, Yekaterina Kantserova wrote: >> >> > Hi everyone, >> > >> > In the previous mail I've referred to already existing BUG number, >> which was wrong. Here comes the webrev referred to the new BUG >> > >> > http://cr.openjdk.java.net/~ykantser/8007142/webrev.00/ >> > >> > Thanks, >> > Katja >> > >> > -------- Original Message -------- >> > Subject: 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> > Date: Tue, 29 Jan 2013 15:13:11 +0100 >> > From: Yekaterina Kantserova >> > To: core-libs-dev at openjdk.java.net >> > CC: jfr_dev_ww_grp >> > >> > Hi everyone, >> > >> > Christian T?rnqvist has done a great job to make it easier to run >> > multi-process tests in jtreg. His webrev >> > ( >> > http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.03/ >> > ) is >> > already approved and on the way into the hotspot repo. >> > >> > This webrev >> > http://cr.openjdk.java.net/~ykantser/8006413/webrev.00/ >> > is >> > for putting these utility classes into the jdk repo. I'm going to use >> > them for the JFR testing in the first hand. >> > >> > The webrev is almost a copy of Christian's except JcmdBase.java, utility >> > class for starting jcmd, and some extra methods in OutputAnalyzer.java. >> > >> > Thanks, >> > Katja >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130130/6a2d4bb3/attachment.html From coleen.phillimore at oracle.com Wed Jan 30 15:04:43 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 30 Jan 2013 18:04:43 -0500 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <51075003.9000307@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> <5101BC24.1020905@oracle.com> <5101C9EC.6060608@oracle.com> <5101DEAE.9000404@oracle.com> <5106F91B.4040900@oracle.com> <51075003.9000307@oracle.com> Message-ID: <5109A70B.2060109@oracle.com> This looks really good! Thanks for doing the refactoring! Coleen On 1/28/2013 11:28 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > This is a version with a refactoring you requested: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.3/ > > > Now, the NameAndType, FieldRef, InterfaceMethodRef and MethodRef use > the find_or_append_indirect_entry(). > > > Thanks, > Serguei > > > On 1/28/13 2:18 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> >> This is a new webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.2/ >> >> >> As you pointed out, the InvokeDynamic entry support should also do >> cross-checks with >> the bootstrap method operands (arguments) and recursive extra appends >> if necessary. >> >> I've filed a separate bug to track this issue: >> https://jbs.oracle.com/bugs/browse/JDK-8007037 >> >> I want to separate this issue to be able to integrate what I have now >> and concentrate on the rest later. >> The VM SQE team developed new INDY tests that cover the >> RedefineClasses issues. >> I hope to adopt and use new tests soon to make sure most of the >> issues are actually resolved. >> >> >> Thanks, >> Serguei >> >> >> On 1/24/13 5:23 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> >>> Thank you a lot for the review! >>> >>> On 1/24/13 3:55 PM, Coleen Phillimore wrote: >>>> >>>> Hi Serguei, >>>> >>>> Putting functions in alphabetical order seems silly, it's better to >>>> have utility functions directly above (or below) the function that >>>> calls them. I'd take out the comment. >>>> >>>> I have started looking at this code a bit. This function >>>> find_or_append_indirect_entry() should be used for the other >>>> indirect entries also, shouldn't it? The code looks familiar to >>>> the inside of the case statement to FieldRef, InterfaceRef and >>>> MethodRef. >>> >>> You've got it right. >>> Yes, I noticed it but did not want to mess with it until it is >>> proven to work well. >>> My plan was to fix it for the FieldRef, InterfaceRef and MethodRef >>> in a next round of fixes. >>> >>>> >>>> Also is boot_spec an indirect index too that has to be appended? >>>> >>>> 564 int boot_spec = >>>> scratch_cp->invoke_dynamic_bootstrap_method_ref_index_at(scratch_i); >>> >>> This is a nice catch, will fix it. >>> I thought, it is an index into the operands array, but it refers to >>> a CONSTANT_MethodHandle element. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 01/24/2013 05:56 PM, serguei.spitsyn at oracle.com wrote: >>>>> Christian, >>>>> >>>>> >>>>> Thank you a lot for the review! >>>>> >>>>> Nice catch with the ordering. >>>>> In fact, I tried to follow the order but missed that the >>>>> find_new_index should go first. :) >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 1/24/13 2:14 PM, Christian Thalinger wrote: >>>>>> On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: >>>>>> >>>>>>> Please, review the fix for: >>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006542 >>>>>>> >>>>>>> >>>>>>> Open webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ >>>>>>> >>>>>> src/share/vm/prims/jvmtiRedefineClasses.hpp: >>>>>> >>>>>> + // Support for constant pool merging (these routines are in >>>>>> alpha order): >>>>>> void append_entry(constantPoolHandle scratch_cp, int scratch_i, >>>>>> constantPoolHandle *merge_cp_p, int *merge_cp_length_p, >>>>>> TRAPS); >>>>>> + int find_or_append_indirect_entry(constantPoolHandle >>>>>> scratch_cp, int scratch_i, >>>>>> + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); >>>>>> int find_new_index(int old_index); >>>>>> >>>>>> Not really alpha order ;-) >>>>>> >>>>>> Otherwise this looks good (as far as I can tell). >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> Summary: >>>>>>> Need a support for invokedynamic entry kinds when new and old >>>>>>> constant pools are merged. >>>>>>> >>>>>>> Testing: >>>>>>> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >>>>>>> Asked the VM SQE team to develop new INDY tests for better >>>>>>> coverage. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Wed Jan 30 15:15:57 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 Jan 2013 15:15:57 -0800 Subject: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds In-Reply-To: <5109A70B.2060109@oracle.com> References: <50F71FB2.4020702@oracle.com> <50FF29CA.9000009@oracle.com> <5101BC24.1020905@oracle.com> <5101C9EC.6060608@oracle.com> <5101DEAE.9000404@oracle.com> <5106F91B.4040900@oracle.com> <51075003.9000307@oracle.com> <5109A70B.2060109@oracle.com> Message-ID: <5109A9AD.2080203@oracle.com> Thanks, Coleen! Serguei On 1/30/13 3:04 PM, Coleen Phillimore wrote: > > This looks really good! Thanks for doing the refactoring! > Coleen > > On 1/28/2013 11:28 PM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> This is a version with a refactoring you requested: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.3/ >> >> >> Now, the NameAndType, FieldRef, InterfaceMethodRef and MethodRef use >> the find_or_append_indirect_entry(). >> >> >> Thanks, >> Serguei >> >> >> On 1/28/13 2:18 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> >>> This is a new webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.2/ >>> >>> >>> As you pointed out, the InvokeDynamic entry support should also do >>> cross-checks with >>> the bootstrap method operands (arguments) and recursive extra >>> appends if necessary. >>> >>> I've filed a separate bug to track this issue: >>> https://jbs.oracle.com/bugs/browse/JDK-8007037 >>> >>> I want to separate this issue to be able to integrate what I have >>> now and concentrate on the rest later. >>> The VM SQE team developed new INDY tests that cover the >>> RedefineClasses issues. >>> I hope to adopt and use new tests soon to make sure most of the >>> issues are actually resolved. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 1/24/13 5:23 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Coleen, >>>> >>>> >>>> Thank you a lot for the review! >>>> >>>> On 1/24/13 3:55 PM, Coleen Phillimore wrote: >>>>> >>>>> Hi Serguei, >>>>> >>>>> Putting functions in alphabetical order seems silly, it's better >>>>> to have utility functions directly above (or below) the function >>>>> that calls them. I'd take out the comment. >>>>> >>>>> I have started looking at this code a bit. This function >>>>> find_or_append_indirect_entry() should be used for the other >>>>> indirect entries also, shouldn't it? The code looks familiar to >>>>> the inside of the case statement to FieldRef, InterfaceRef and >>>>> MethodRef. >>>> >>>> You've got it right. >>>> Yes, I noticed it but did not want to mess with it until it is >>>> proven to work well. >>>> My plan was to fix it for the FieldRef, InterfaceRef and MethodRef >>>> in a next round of fixes. >>>> >>>>> >>>>> Also is boot_spec an indirect index too that has to be appended? >>>>> >>>>> 564 int boot_spec = >>>>> scratch_cp->invoke_dynamic_bootstrap_method_ref_index_at(scratch_i); >>>> >>>> This is a nice catch, will fix it. >>>> I thought, it is an index into the operands array, but it refers to >>>> a CONSTANT_MethodHandle element. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 01/24/2013 05:56 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Christian, >>>>>> >>>>>> >>>>>> Thank you a lot for the review! >>>>>> >>>>>> Nice catch with the ordering. >>>>>> In fact, I tried to follow the order but missed that the >>>>>> find_new_index should go first. :) >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 1/24/13 2:14 PM, Christian Thalinger wrote: >>>>>>> On Jan 22, 2013, at 4:07 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> >>>>>>>> Please, review the fix for: >>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006542 >>>>>>>> >>>>>>>> >>>>>>>> Open webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ >>>>>>>> >>>>>>> src/share/vm/prims/jvmtiRedefineClasses.hpp: >>>>>>> >>>>>>> + // Support for constant pool merging (these routines are in >>>>>>> alpha order): >>>>>>> void append_entry(constantPoolHandle scratch_cp, int scratch_i, >>>>>>> constantPoolHandle *merge_cp_p, int *merge_cp_length_p, >>>>>>> TRAPS); >>>>>>> + int find_or_append_indirect_entry(constantPoolHandle >>>>>>> scratch_cp, int scratch_i, >>>>>>> + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, >>>>>>> TRAPS); >>>>>>> int find_new_index(int old_index); >>>>>>> >>>>>>> Not really alpha order ;-) >>>>>>> >>>>>>> Otherwise this looks good (as far as I can tell). >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> Summary: >>>>>>>> Need a support for invokedynamic entry kinds when new and old >>>>>>>> constant pools are merged. >>>>>>>> >>>>>>>> Testing: >>>>>>>> vm/mlvm/indy/func/jvmti/redefineClassInBootstrap >>>>>>>> Asked the VM SQE team to develop new INDY tests for better >>>>>>>> coverage. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> From weijun.wang at oracle.com Wed Jan 30 16:54:37 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 31 Jan 2013 08:54:37 +0800 Subject: 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <5107D8F7.4040308@oracle.com> <51092A24.6050009@oracle.com> Message-ID: <5109C0CD.4080107@oracle.com> Just take a brief look at the codes. It seems the library can launch a Java process, wait for it to finish, and collect all the output (stdout and stderr). Is that all? I would be glad if it supports manipulating the stdin, i.e. simulating input to a process. For example, I sometimes need to start two processes, one is a client, and one is a server, and they need to talk to each other. I could create sockets inside but it will be much simpler (and more stable) if they can just communicate through stdin/stdout. This also means you cannot drain the stdout in a single method, but read it after each input, you might need to prepare for blocking. Also, It will be nice if there is an example on how to use it. In fact, I'm working on something similar right now: http://cr.openjdk.java.net/~weijun/9999999/webrev.13/ Thanks Max On 01/30/2013 10:40 PM, Rickard B?ckman wrote: > Katja, > > I think the change looks good. > However we need to find an official reviewer before we can push this. > > Can we get an official reviewer to look on this change please? > > Thanks > /R > > On Jan 30, 2013, at 3:11 PM, Yekaterina Kantserova wrote: > >> Hi everyone, >> >> In the previous mail I've referred to already existing BUG number, which was wrong. Here comes the webrev referred to the new BUG >> >> http://cr.openjdk.java.net/~ykantser/8007142/webrev.00/ >> >> Thanks, >> Katja >> >> -------- Original Message -------- >> Subject: 8006413: Add utility classes for writing better multiprocess tests in jtreg >> Date: Tue, 29 Jan 2013 15:13:11 +0100 >> From: Yekaterina Kantserova >> To: core-libs-dev at openjdk.java.net >> CC: jfr_dev_ww_grp >> >> Hi everyone, >> >> Christian T?rnqvist has done a great job to make it easier to run >> multi-process tests in jtreg. His webrev >> ( >> http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.03/ >> ) is >> already approved and on the way into the hotspot repo. >> >> This webrev >> http://cr.openjdk.java.net/~ykantser/8006413/webrev.00/ >> is >> for putting these utility classes into the jdk repo. I'm going to use >> them for the JFR testing in the first hand. >> >> The webrev is almost a copy of Christian's except JcmdBase.java, utility >> class for starting jcmd, and some extra methods in OutputAnalyzer.java. >> >> Thanks, >> Katja >> >> > From yumin.qi at oracle.com Wed Jan 30 23:16:06 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 30 Jan 2013 23:16:06 -0800 Subject: RFR: 8000973: SA on windows thread inspection is broken Message-ID: <510A1A36.5010608@oracle.com> Please have your comments on: http://cr.openjdk.java.net/~minqi/8000973/ This only affected Windows platform. Summary: After bug 7161732, On Windows SA could not find correct address of thread_id of OSThread since _thread_id moved to end of the class . The presupposition of the address is following thread handle no longer stands. Fix by adding thread_id field to OSThread and getting the address directly from OSThread. Reviewed-by: Contributed-by: yumin.qi at oracle.com Thanks Yumin From nils.loodin at oracle.com Thu Jan 31 00:12:49 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Thu, 31 Jan 2013 09:12:49 +0100 Subject: RFR: 8000973: SA on windows thread inspection is broken In-Reply-To: <510A1A36.5010608@oracle.com> References: <510A1A36.5010608@oracle.com> Message-ID: <0D498837-8558-4EB1-A603-D986A851D4B4@oracle.com> Ah, was just about to take a look a this too! Looks good and equal to what I had in my workspace :) /Nisse On Jan 31, 2013, at 8:16 , Yumin Qi wrote: > Please have your comments on: > > http://cr.openjdk.java.net/~minqi/8000973/ > > This only affected Windows platform. > > Summary: After bug 7161732, On Windows SA could not find correct address of thread_id of OSThread since _thread_id moved to end of the class . The presupposition of the address is following thread handle no longer stands. Fix by adding thread_id field to OSThread and getting the address directly from OSThread. > Reviewed-by: > Contributed-by: yumin.qi at oracle.com > > Thanks > Yumin From joel.franck at oracle.com Thu Jan 31 01:12:40 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 31 Jan 2013 09:12:40 +0000 Subject: hg: jdk8/tl/jdk: 8005712: Simplify support for repeating annotations in j.l.r.AnnotatedElement; ... Message-ID: <20130131091301.331DF476D9@hg.openjdk.java.net> Changeset: 5097fe015763 Author: jfranck Date: 2013-01-31 10:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5097fe015763 8005712: Simplify support for repeating annotations in j.l.r.AnnotatedElement 8004919: AnnotationSupport uses possibly half-constructed AnnotationType instances Summary: Implements the simplified semantics for repeating annotations and removes the incorrect obtaining of an AnnotationType Reviewed-by: darcy, abuckley ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java ! test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/Container.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainer.java From yumin.qi at oracle.com Thu Jan 31 07:48:47 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 31 Jan 2013 07:48:47 -0800 Subject: RFR: 8000973: SA on windows thread inspection is broken In-Reply-To: <0D498837-8558-4EB1-A603-D986A851D4B4@oracle.com> References: <510A1A36.5010608@oracle.com> <0D498837-8558-4EB1-A603-D986A851D4B4@oracle.com> Message-ID: <510A925F.6020709@oracle.com> Thanks, Nils Yumin On 1/31/2013 12:12 AM, Nils Loodin wrote: > Ah, was just about to take a look a this too! > Looks good and equal to what I had in my workspace :) > > /Nisse > > On Jan 31, 2013, at 8:16 , Yumin Qi wrote: > >> Please have your comments on: >> >> http://cr.openjdk.java.net/~minqi/8000973/ >> >> This only affected Windows platform. >> >> Summary: After bug 7161732, On Windows SA could not find correct address of thread_id of OSThread since _thread_id moved to end of the class . The presupposition of the address is following thread handle no longer stands. Fix by adding thread_id field to OSThread and getting the address directly from OSThread. >> Reviewed-by: >> Contributed-by: yumin.qi at oracle.com >> >> Thanks >> Yumin From david.buck at oracle.com Thu Jan 31 10:56:21 2013 From: david.buck at oracle.com (david.buck at oracle.com) Date: Thu, 31 Jan 2013 18:56:21 +0000 Subject: hg: jdk8/tl/jdk: 7042126: (alt-rt) HashMap.clone implementation should be re-examined Message-ID: <20130131185643.CC531476F4@hg.openjdk.java.net> Changeset: 3f766f58c48a Author: dbuck Date: 2013-01-31 10:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f766f58c48a 7042126: (alt-rt) HashMap.clone implementation should be re-examined Summary: Test case for cr7042126. Issue only found in OracleJDK, but test case is valid for OpenJDK as well Reviewed-by: mduigou + test/java/util/HashMap/HashMapCloneLeak.java From serguei.spitsyn at oracle.com Thu Jan 31 11:10:17 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Jan 2013 11:10:17 -0800 Subject: RFR: 8000973: SA on windows thread inspection is broken In-Reply-To: <510A1A36.5010608@oracle.com> References: <510A1A36.5010608@oracle.com> Message-ID: <510AC199.8020307@oracle.com> Hi Yumin, Looks good. A couple of minor comments. 1. All the copyright comments are outdated. 2. *agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/amd64/WindbgAMD64Thread.java ***agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/x86/WindbgX86Thread.java ** 37 //The address argument must be the address of the OSThread::_thread_id Space is missed at the beginning of comment. 39 this.debugger = debugger; * 40 this.sysId = (long)addr.getCIntegerAt(0, 4, true);* The '=' is not aligned properly and extra space after '='. Thanks, Serguei On 1/30/13 11:16 PM, Yumin Qi wrote: > Please have your comments on: > > http://cr.openjdk.java.net/~minqi/8000973/ > > This only affected Windows platform. > > Summary: After bug 7161732, On Windows SA could not find correct > address of thread_id of OSThread since _thread_id moved to end of the > class . The presupposition of the address is following thread handle > no longer stands. Fix by adding thread_id field to OSThread and > getting the address directly from OSThread. > Reviewed-by: > Contributed-by: yumin.qi at oracle.com > > Thanks > Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130131/abe743b6/attachment.html From xueming.shen at oracle.com Thu Jan 31 11:10:30 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 31 Jan 2013 19:10:30 +0000 Subject: hg: jdk8/tl/jdk: 8005394: Base64.Decoder/Encoder.wrap(XStream) don't throw NPE for null args passed Message-ID: <20130131191041.A2BBB476F5@hg.openjdk.java.net> Changeset: 857d99bef21d Author: sherman Date: 2013-01-31 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/857d99bef21d 8005394: Base64.Decoder/Encoder.wrap(XStream) don't throw NPE for null args passed Summary: to check null for dec/enc.wrap methods Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java From yumin.qi at oracle.com Thu Jan 31 11:12:33 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 31 Jan 2013 11:12:33 -0800 Subject: RFR: 8000973: SA on windows thread inspection is broken In-Reply-To: <510AC199.8020307@oracle.com> References: <510A1A36.5010608@oracle.com> <510AC199.8020307@oracle.com> Message-ID: <510AC221.6040904@oracle.com> Serguei, Thanks Yumin On 1/31/2013 11:10 AM, serguei.spitsyn at oracle.com wrote: > Hi Yumin, > > Looks good. > > A couple of minor comments. > > 1. All the copyright comments are outdated. > > 2. > * > agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/amd64/WindbgAMD64Thread.java > *** > agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/x86/WindbgX86Thread.java > ** > 37 //The address argument must be the address of the OSThread::_thread_id > Space is missed at the beginning of comment. > > 39 this.debugger = debugger; > * 40 this.sysId = (long)addr.getCIntegerAt(0, 4, true);* > The '=' is not aligned properly and extra space after '='. > > > Thanks, > Serguei > > > On 1/30/13 11:16 PM, Yumin Qi wrote: >> Please have your comments on: >> >> http://cr.openjdk.java.net/~minqi/8000973/ >> >> This only affected Windows platform. >> >> Summary: After bug 7161732, On Windows SA could not find correct >> address of thread_id of OSThread since _thread_id moved to end of the >> class . The presupposition of the address is following thread handle >> no longer stands. Fix by adding thread_id field to OSThread and >> getting the address directly from OSThread. >> Reviewed-by: >> Contributed-by: yumin.qi at oracle.com >> >> Thanks >> Yumin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130131/09f0426a/attachment-0001.html From joe.darcy at oracle.com Thu Jan 31 12:13:45 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 31 Jan 2013 20:13:45 +0000 Subject: hg: jdk8/tl/jdk: 8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} annotation types Message-ID: <20130131201358.B16CD476F8@hg.openjdk.java.net> Changeset: 278397f752da Author: darcy Date: 2013-01-31 12:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/278397f752da 8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} annotation types Reviewed-by: mduigou - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java ! src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java From joe.darcy at oracle.com Thu Jan 31 12:16:13 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 31 Jan 2013 20:16:13 +0000 Subject: hg: jdk8/tl/langtools: 8007313: Remove use of {ContainerFor/ContainedBy} from langtools Message-ID: <20130131201615.A7A28476F9@hg.openjdk.java.net> Changeset: 8e4c22acebeb Author: darcy Date: 2013-01-31 12:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8e4c22acebeb 8007313: Remove use of {ContainerFor/ContainedBy} from langtools Reviewed-by: jjg ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java From joe.darcy at oracle.com Thu Jan 31 12:23:22 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 31 Jan 2013 20:23:22 +0000 Subject: hg: jdk8/tl/jdk: 8007115: Refactor regression tests for java.lang.reflect.Parameter Message-ID: <20130131202335.7F191476FA@hg.openjdk.java.net> Changeset: a5f38e811ab0 Author: darcy Date: 2013-01-31 12:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5f38e811ab0 8007115: Refactor regression tests for java.lang.reflect.Parameter Reviewed-by: emc ! test/java/lang/reflect/Parameter/WithoutParameters.java From xueming.shen at oracle.com Thu Jan 31 13:13:37 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 31 Jan 2013 21:13:37 +0000 Subject: hg: jdk8/tl/jdk: 8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character; ... Message-ID: <20130131211351.72285476FF@hg.openjdk.java.net> Changeset: e5ce312a5b10 Author: sherman Date: 2013-01-31 13:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e5ce312a5b10 8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character 8006526: Base64.Decoder.decode(String) spec contains a copy-paste mistake Summary: to ignore single non-base64 char in mime decoding Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java From mike.duigou at oracle.com Thu Jan 31 13:27:56 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 31 Jan 2013 21:27:56 +0000 Subject: hg: jdk8/tl/jdk: 8006709: Add minimal support of MacOSX platform for NetBeans Projects Message-ID: <20130131212807.8091B47701@hg.openjdk.java.net> Changeset: cff8d7768d72 Author: mduigou Date: 2013-01-31 13:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cff8d7768d72 8006709: Add minimal support of MacOSX platform for NetBeans Projects Summary: Adds support for MacOSX platform and architecture detection. Other minor updates (-source/target 1.8) Reviewed-by: ohair + make/netbeans/common/architectures/arch-x86_64.properties + make/netbeans/common/architectures/name-Macosx.properties ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent ! make/netbeans/common/make.xml ! make/netbeans/common/shared.xml From lana.steuck at oracle.com Thu Jan 31 14:19:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:19:01 +0000 Subject: hg: jdk8/tl: 19 new changesets Message-ID: <20130131221903.1B5C147703@hg.openjdk.java.net> Changeset: 50307da0149e Author: jqzuo Date: 2012-12-31 14:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/50307da0149e 8005583: Install build(gnumake all) failed preventing RE from doing JDK8 combo builds Reviewed-by: paulk, billyh ! make/install-rules.gmk Changeset: e5664599a127 Author: cgruszka Date: 2013-01-02 14:54 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e5664599a127 Merge Changeset: 75634cbeab47 Author: cgruszka Date: 2013-01-04 13:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/75634cbeab47 Merge Changeset: 61d7e2971723 Author: cgruszka Date: 2013-01-14 14:40 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/61d7e2971723 Merge Changeset: f9163f9cb1da Author: cgruszka Date: 2013-01-23 08:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f9163f9cb1da Merge Changeset: 5a5e97f9ac0a Author: erikj Date: 2013-01-18 09:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5a5e97f9ac0a 8006520: build-infra: Fix sparkle-framework configure parameter Reviewed-by: tbell, ohair ! common/autoconf/generated-configure.sh ! common/makefiles/Jprt.gmk Changeset: edad83acbd46 Author: erikj Date: 2013-01-18 16:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/edad83acbd46 8003693: build-infra: bridgeBuild should allow for partial build (no hotspot) Reviewed-by: tbell ! common/makefiles/Jprt.gmk Changeset: c3bf62746a80 Author: tbell Date: 2013-01-23 13:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c3bf62746a80 8006797: build-infra JPRT builds need JPRT_ARCHIVE_INSTALL_BUNDLE in common/makefiles/Jprt.gmk Reviewed-by: ohair ! common/makefiles/Jprt.gmk Changeset: b43aa5bd8ca5 Author: katleman Date: 2013-01-23 15:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b43aa5bd8ca5 Merge Changeset: cd2fa0d0ed3d Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cd2fa0d0ed3d Added tag jdk8-b74 for changeset b43aa5bd8ca5 ! .hgtags Changeset: 039783b67959 Author: lana Date: 2013-01-26 18:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/039783b67959 Merge Changeset: e28985c549aa Author: raginip Date: 2013-01-18 11:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e28985c549aa 8000839: Integrate the Java Access Bridge with Java Runtime Reviewed-by: ptbrunet, erikj ! common/bin/compare_exceptions.sh.incl Changeset: db46b1c27a93 Author: erikj Date: 2013-01-28 14:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/db46b1c27a93 Merge - common/autoconf/closed.version.numbers ! common/autoconf/generated-configure.sh - common/autoconf/version.numbers ! common/bin/compare_exceptions.sh.incl Changeset: 8baaaba2ee6b Author: lana Date: 2013-01-29 20:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8baaaba2ee6b Merge Changeset: 0d4b0a13adb2 Author: erikj Date: