From daniel.fuchs at oracle.com Mon Jul 1 02:27:19 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Mon, 01 Jul 2013 09:27:19 +0000 Subject: hg: jdk8/tl/jdk: 8014045: test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently Message-ID: <20130701092807.71C8C486BA@hg.openjdk.java.net> Changeset: 3aa541b50a64 Author: dfuchs Date: 2013-07-01 11:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3aa541b50a64 8014045: test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently Summary: this test was failing because it didn't take into account the fact that Loggers could be garbage collected. Reviewed-by: mchung ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java From frederic.parain at oracle.com Mon Jul 1 04:06:47 2013 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Mon, 01 Jul 2013 11:06:47 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7060111: race condition in VMError::report_and_die() Message-ID: <20130701110653.8A1DB486C0@hg.openjdk.java.net> Changeset: 068b406e307f Author: fparain Date: 2013-07-01 09:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/068b406e307f 7060111: race condition in VMError::report_and_die() Reviewed-by: zgu, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp From vincent.x.ryan at oracle.com Mon Jul 1 06:41:46 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 01 Jul 2013 13:41:46 +0000 Subject: hg: jdk8/tl/jdk: 8019259: Failover to CRL checking does not happen if wrong OCSP responder URL is set Message-ID: <20130701134210.1FE1F486C5@hg.openjdk.java.net> Changeset: dfb37cc30a67 Author: vinnie Date: 2013-07-01 14:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfb37cc30a67 8019259: Failover to CRL checking does not happen if wrong OCSP responder URL is set Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java From maurizio.cimadamore at oracle.com Mon Jul 1 06:57:26 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 01 Jul 2013 13:57:26 +0000 Subject: hg: jdk8/tl/langtools: 7034798: Ambiguity error for abstract method call is too eager Message-ID: <20130701135732.8E158486C6@hg.openjdk.java.net> Changeset: f559ef7568ce Author: mcimadamore Date: 2013-07-01 14:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f559ef7568ce 7034798: Ambiguity error for abstract method call is too eager Summary: Javac should wait and see if ambiguous methods can be reconciled at the end of an overload resolution round Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/tests/AbstractMerge.java ! test/tools/javac/resolve/tests/InnerOverOuter.java From rickard.backman at oracle.com Mon Jul 1 07:00:02 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Mon, 01 Jul 2013 14:00:02 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8016444: Duplicate zombie check in safe_for_sender Message-ID: <20130701140007.DCC15486C7@hg.openjdk.java.net> Changeset: acfa2cc19146 Author: rbackman Date: 2013-06-12 09:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/acfa2cc19146 8016444: Duplicate zombie check in safe_for_sender Reviewed-by: dholmes, sla ! src/cpu/sparc/vm/frame_sparc.cpp ! src/share/vm/memory/referenceProcessorStats.hpp From erik.helin at oracle.com Mon Jul 1 08:32:02 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 1 Jul 2013 17:32:02 +0200 Subject: RFR: 8019500: Exclude MemoryTest.java and MemoryTestAllGC.sh to enable integration Message-ID: <20130701153202.GE2213@ehelin-thinkpad> Hi all, this change excludes the following two MemoryMXBean tests: - java/lang/management/MemoryMXBean/MemoryTestAllGC.sh - java/lang/management/MemoryMXBean/MemoryTest.java This is needed since a change in hotspot added a new memory pool for metaspace: > hg log hotspot-main/hotspot: > changeset: 4861:71963b3f802a > user: ehelin > date: Wed Jun 26 16:58:37 2013 > summary: 8013590: NPG: Add a memory pool MXBean for Metaspace These tests need to be excluded for a (very short) time to be able to integrate hotspot-main into jdk8/jdk8. Webrev: http://cr.openjdk.java.net/~ehelin/8019500/webrev.00/ Please note that the change is for jdk8/jdk8 (not jdk8/tl) since hotspot needs to be integrated into jdk8/jdk8. I have also sent out a review request for a change that fixes the test and removes the tests from ProblemList.txt. This change can be applied to jdk8/tl as soon as hotspot has been integrated and pulled down to jdk8/tl. Thanks, Erik From erik.helin at oracle.com Mon Jul 1 08:35:20 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 1 Jul 2013 17:35:20 +0200 Subject: RFR: 8010734: NPG: The test MemoryTest.java needs to be updated to support metaspace Message-ID: <20130701153520.GF2213@ehelin-thinkpad> Hi all, this change updates MemoryTest.java to take the newly added Metaspace and Compressed Class Space MemoryMXBeans into account, as well as the new Metaspace Memory Manager. This change also removes the following two tests from ProblemList.txt since they are now passing again: -java/lang/management/MemoryMXBean/MemoryTestAllGC.sh generic-all -java/lang/management/MemoryMXBean/MemoryTest.java generic-all Webrev: http://cr.openjdk.java.net/~ehelin/8010734/webrev.00/ Thanks, Erik From erik.helin at oracle.com Mon Jul 1 08:43:45 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 1 Jul 2013 17:43:45 +0200 Subject: RFR (XXS): 8017159: Unexclude sun/tools/JMAP/Basic.sh test In-Reply-To: <51C9A472.8030209@oracle.com> References: <20130625135757.GB2007@ehelin-thinkpad> <51C9A472.8030209@oracle.com> Message-ID: <20130701154345.GG2213@ehelin-thinkpad> On 2013-06-25, Alan Bateman wrote: > On 25/06/2013 14:57, Erik Helin wrote: > >Hi all, > > > >this minimal change removes the test sun/tools/JMAP/Basic.sh from > >ProblemList.txt since the bug that caused the test to fail has been > >fixed. > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8017159/webrev.00/ > > > Looks fine, probably the bug summary should say "jmap" rather than "JMAP". Thanks! I've updated the bug to use jmap instead of JMAP. Erik > -Alan From markus.gronlund at oracle.com Mon Jul 1 11:13:39 2013 From: markus.gronlund at oracle.com (markus.gronlund at oracle.com) Date: Mon, 01 Jul 2013 18:13:39 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8016331: Minor issues in event tracing metadata Message-ID: <20130701181344.3E1FE486D2@hg.openjdk.java.net> Changeset: 993dfb57c575 Author: egahlin Date: 2013-06-26 17:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/993dfb57c575 8016331: Minor issues in event tracing metadata Reviewed-by: stefank, brutisso, mgronlun ! src/share/vm/trace/trace.xml From Alan.Bateman at oracle.com Mon Jul 1 11:47:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 01 Jul 2013 19:47:34 +0100 Subject: JDK 8 code review request for doclint issues in java.lang.instrument In-Reply-To: <51D1C974.80704@oracle.com> References: <51D1C974.80704@oracle.com> Message-ID: <51D1CEC6.7080702@oracle.com> On 01/07/2013 19:24, Joe Darcy wrote: > Hello, > > Yet another found of doclint fixes for review; this batch to > java.lang.instrument. > > Thanks, > > -Joe This looks okay to me. -Alan From joe.darcy at oracle.com Mon Jul 1 11:59:03 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 01 Jul 2013 18:59:03 +0000 Subject: hg: jdk8/tl/langtools: 7162089: Add support for repeating annotations to javax.annotation.processing Message-ID: <20130701185910.5457F486D4@hg.openjdk.java.net> Changeset: 1908e86ee49a Author: darcy Date: 2013-07-01 11:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1908e86ee49a 7162089: Add support for repeating annotations to javax.annotation.processing Reviewed-by: abuckley, jjg, jfranck ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/javax/annotation/processing/AbstractProcessor.java ! src/share/classes/javax/annotation/processing/Processor.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java + test/tools/javac/processing/environment/round/TpAnno.java + test/tools/javac/processing/environment/round/TypeParameterAnnotations.java From alan.bateman at oracle.com Mon Jul 1 12:41:10 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 01 Jul 2013 19:41:10 +0000 Subject: hg: jdk8/tl/jdk: 8017540: Improve multi-threaded contention behavior of radix conversion cache Message-ID: <20130701194122.08C8B486DC@hg.openjdk.java.net> Changeset: c8cf01de8fa8 Author: bpb Date: 2013-07-01 11:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8cf01de8fa8 8017540: Improve multi-threaded contention behavior of radix conversion cache Summary: Replace array of ArrayList of BigIntegers with a volatile two-dimensional BigInteger array eliminate the synchronization of getRadixConversionCache() Reviewed-by: plevart, shade, bpb, alanb Contributed-by: Peter Levart , Dmitry Nadezhin , Aleksey Shipilev ! src/share/classes/java/math/BigInteger.java From joe.darcy at oracle.com Mon Jul 1 13:30:53 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 01 Jul 2013 20:30:53 +0000 Subject: hg: jdk8/tl/jdk: 8019527: Fix doclint issues in java.lang.instrument Message-ID: <20130701203106.934D4486DE@hg.openjdk.java.net> Changeset: 3736ad2636aa Author: darcy Date: 2013-07-01 13:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3736ad2636aa 8019527: Fix doclint issues in java.lang.instrument Reviewed-by: lancea, alanb ! src/share/classes/java/lang/instrument/Instrumentation.java From joe.darcy at oracle.com Mon Jul 1 13:43:20 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 01 Jul 2013 20:43:20 +0000 Subject: hg: jdk8/tl/jdk: 8019529: Fix doclint issues in java.util.spi Message-ID: <20130701204333.CB309486DF@hg.openjdk.java.net> Changeset: 8e5376324e4b Author: darcy Date: 2013-07-01 13:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e5376324e4b 8019529: Fix doclint issues in java.util.spi Reviewed-by: lancea ! src/share/classes/java/util/spi/LocaleServiceProvider.java From joe.darcy at oracle.com Mon Jul 1 14:34:19 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 01 Jul 2013 21:34:19 +0000 Subject: hg: jdk8/tl/jdk: 8019535: Fix doclint issues in java.time.format Message-ID: <20130701213430.EA27D486E0@hg.openjdk.java.net> Changeset: 5427f7316633 Author: darcy Date: 2013-07-01 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5427f7316633 8019535: Fix doclint issues in java.time.format Reviewed-by: lancea, rriggs ! src/share/classes/java/time/format/DateTimeFormatter.java From jason.uh at oracle.com Mon Jul 1 17:46:46 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Tue, 02 Jul 2013 00:46:46 +0000 Subject: hg: jdk8/tl/jdk: 8019539: Fix doclint errors in java.security and its subpackages Message-ID: <20130702004713.5D7BC486E3@hg.openjdk.java.net> Changeset: 17f44b2dde41 Author: juh Date: 2013-07-01 17:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17f44b2dde41 8019539: Fix doclint errors in java.security and its subpackages Reviewed-by: darcy ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509CRLEntry.java ! src/share/classes/java/security/cert/X509Certificate.java From serguei.spitsyn at oracle.com Mon Jul 1 22:55:26 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 02 Jul 2013 05:55:26 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8009204: [dtrace] signatures returned by Java 7 jstack() are corrupted on Solaris Message-ID: <20130702055531.A18DF486F0@hg.openjdk.java.net> Changeset: 7f11c12d7a90 Author: sspitsyn Date: 2013-07-01 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7f11c12d7a90 8009204: [dtrace] signatures returned by Java 7 jstack() are corrupted on Solaris Summary: The fix is basically a backport of JDK-7019165 (pstack issue) to jhelper.d. Reviewed-by: coleenp, sspitsyn Contributed-by: tomas.hurka at oracle.com ! src/os/solaris/dtrace/jhelper.d From Alan.Bateman at oracle.com Tue Jul 2 02:11:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Jul 2013 10:11:30 +0100 Subject: RFR: 8019500: Exclude MemoryTest.java and MemoryTestAllGC.sh to enable integration In-Reply-To: <20130701153202.GE2213@ehelin-thinkpad> References: <20130701153202.GE2213@ehelin-thinkpad> Message-ID: <51D29942.4090802@oracle.com> On 01/07/2013 16:32, Erik Helin wrote: > Hi all, > > this change excludes the following two MemoryMXBean tests: > - java/lang/management/MemoryMXBean/MemoryTestAllGC.sh > - java/lang/management/MemoryMXBean/MemoryTest.java > > This is needed since a change in hotspot added a new memory pool for > metaspace: > >> hg log hotspot-main/hotspot: >> changeset: 4861:71963b3f802a >> user: ehelin >> date: Wed Jun 26 16:58:37 2013 >> summary: 8013590: NPG: Add a memory pool MXBean for Metaspace > These tests need to be excluded for a (very short) time to be able to > integrate hotspot-main into jdk8/jdk8. > > Webrev: http://cr.openjdk.java.net/~ehelin/8019500/webrev.00/ > > Please note that the change is for jdk8/jdk8 (not jdk8/tl) since hotspot > needs to be integrated into jdk8/jdk8. > > I have also sent out a review request for a change that fixes the test > and removes the tests from ProblemList.txt. This change can be applied > to jdk8/tl as soon as hotspot has been integrated and pulled down to jdk8/tl. > > Thanks, > Erik This looks okay to me, although you might want to push-out "generic-all" so that it's consistent with the other lines. -Alan From vicente.romero at oracle.com Tue Jul 2 02:22:30 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 02 Jul 2013 09:22:30 +0000 Subject: hg: jdk8/tl/langtools: 8019397: javap does not show SourceDebugExtension properly Message-ID: <20130702092238.4CEA6486F9@hg.openjdk.java.net> Changeset: 27a2e8c78bd0 Author: vromero Date: 2013-07-02 10:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/27a2e8c78bd0 8019397: javap does not show SourceDebugExtension properly Reviewed-by: jjg Contributed-by: dmytro_sheyko at hotmail.com ! src/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java From erik.helin at oracle.com Tue Jul 2 02:27:44 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 2 Jul 2013 11:27:44 +0200 Subject: RFR: 8019500: Exclude MemoryTest.java and MemoryTestAllGC.sh to enable integration In-Reply-To: <51D29942.4090802@oracle.com> References: <20130701153202.GE2213@ehelin-thinkpad> <51D29942.4090802@oracle.com> Message-ID: <20130702092744.GE1976@ehelin-thinkpad> On 2013-07-02, Alan Bateman wrote: > On 01/07/2013 16:32, Erik Helin wrote: > >Hi all, > > > >this change excludes the following two MemoryMXBean tests: > >- java/lang/management/MemoryMXBean/MemoryTestAllGC.sh > >- java/lang/management/MemoryMXBean/MemoryTest.java > > > >This is needed since a change in hotspot added a new memory pool for > >metaspace: > > > >>hg log hotspot-main/hotspot: > >> changeset: 4861:71963b3f802a > >> user: ehelin > >> date: Wed Jun 26 16:58:37 2013 > >> summary: 8013590: NPG: Add a memory pool MXBean for Metaspace > >These tests need to be excluded for a (very short) time to be able to > >integrate hotspot-main into jdk8/jdk8. > > > >Webrev: http://cr.openjdk.java.net/~ehelin/8019500/webrev.00/ > > > >Please note that the change is for jdk8/jdk8 (not jdk8/tl) since hotspot > >needs to be integrated into jdk8/jdk8. > > > >I have also sent out a review request for a change that fixes the test > >and removes the tests from ProblemList.txt. This change can be applied > >to jdk8/tl as soon as hotspot has been integrated and pulled down to jdk8/tl. > > > >Thanks, > >Erik > This looks okay to me, although you might want to push-out > "generic-all" so that it's consistent with the other lines. Thanks! I will make sure to use the correct alignment for "generic-all" before I push. Again, thanks for your quick reply! Erik > -Alan From daniel.fuchs at oracle.com Tue Jul 2 03:07:24 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Tue, 02 Jul 2013 10:07:24 +0000 Subject: hg: jdk8/tl/jdk: 8017174: NPE when using Logger.getAnonymousLogger or LogManager.getLogManager().getLogger Message-ID: <20130702100749.8AFAA486FB@hg.openjdk.java.net> Changeset: 020f023f87d1 Author: dfuchs Date: 2013-07-02 11:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/020f023f87d1 8017174: NPE when using Logger.getAnonymousLogger or LogManager.getLogManager().getLogger Summary: This patch makes sure that LoggerContext instances created for applets have a root and global logger. Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java ! test/java/util/logging/LogManagerInstanceTest.java + test/java/util/logging/TestAppletLoggerContext.java From kumar.x.srinivasan at oracle.com Tue Jul 2 05:30:26 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 02 Jul 2013 12:30:26 +0000 Subject: hg: jdk8/tl/jdk: 8017463: [TEST_BUG] 2 tests from tools/pack200/ remain about 1 GB of data in work directory after execution Message-ID: <20130702123051.57A2948703@hg.openjdk.java.net> Changeset: b1fffbbdf58c Author: ksrini Date: 2013-07-02 05:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1fffbbdf58c 8017463: [TEST_BUG] 2 tests from tools/pack200/ remain about 1 GB of data in work directory after execution Reviewed-by: mchung ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/BandIntegrity.java ! test/tools/pack200/CommandLineTests.java ! test/tools/pack200/InstructionTests.java ! test/tools/pack200/Pack200Props.java ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/PackageVersionTest.java ! test/tools/pack200/RepackTest.java ! test/tools/pack200/T7007157.java ! test/tools/pack200/TestExceptions.java ! test/tools/pack200/TimeStamp.java ! test/tools/pack200/UnpackerMemoryTest.java ! test/tools/pack200/Utils.java ! test/tools/pack200/typeannos/TestTypeAnnotations.java From sundararajan.athijegannathan at oracle.com Tue Jul 2 06:21:03 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 02 Jul 2013 13:21:03 +0000 Subject: hg: jdk8/tl/nashorn: 12 new changesets Message-ID: <20130702132114.5AF2E48706@hg.openjdk.java.net> Changeset: 218c2833c344 Author: sundar Date: 2013-06-28 19:36 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/218c2833c344 8019365: Error stack format Reviewed-by: hannesw ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/internal/objects/NativeError.java ! test/script/basic/JDK-8014781.js.EXPECTED ! test/script/basic/JDK-8017950.js.EXPECTED ! test/script/basic/JDK-8019226.js ! test/script/basic/JDK-8019226.js.EXPECTED Changeset: 02588d68399d Author: sundar Date: 2013-07-01 12:38 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/02588d68399d 8019473: Parser issues related to functions and blocks Reviewed-by: lagergren ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8019473.js Changeset: 10c7a1e9e24f Author: sundar Date: 2013-07-01 14:15 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/10c7a1e9e24f 8019478: Object.prototype.toString.call(/a/.exec("a")) === "[object Array]" should be true Reviewed-by: hannesw ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java + test/script/basic/JDK-8019478.js Changeset: 47099609a48b Author: sundar Date: 2013-07-01 17:21 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/47099609a48b 8019482: Number("0x0.0p0") should evaluate to NaN Reviewed-by: lagergren ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/JSType.java + test/script/basic/JDK-8019482.js Changeset: ab3ea5b3e507 Author: sundar Date: 2013-07-01 19:52 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ab3ea5b3e507 8019488: switch on literals result in NoSuchMethodError or VerifyError Reviewed-by: hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8019488.js Changeset: 9165138b427c Author: sundar Date: 2013-07-01 23:36 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9165138b427c 8019508: Comma handling in object literal parsing is wrong Reviewed-by: hannesw ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8019508.js + test/script/basic/JDK-8019508.js.EXPECTED Changeset: 5f9abeb0bb50 Author: jlaskey Date: 2013-07-02 07:45 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5f9abeb0bb50 8019580: Build Script Change for Nashorn promotion testing Reviewed-by: jlaskey Contributed-by: eugene.drobitko at oracle.com ! make/build.xml Changeset: a7b82e333c31 Author: lagergren Date: 2013-07-02 13:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a7b82e333c31 8016667: Wrong bytecode when testing/setting due to null check shortcut checking against primitive too Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8016667.js Changeset: 74049fe3ba46 Author: sundar Date: 2013-07-02 18:00 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/74049fe3ba46 8019553: NPE on illegal l-value for increment and decrement Reviewed-by: jlaskey, attila, lagergren ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8019553.js + test/script/basic/JDK-8019553.js.EXPECTED ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-51.js.EXPECTED ! test/script/error/NASHORN-57.js.EXPECTED Changeset: 9396e42bae4f Author: lagergren Date: 2013-07-02 14:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9396e42bae4f 8017082: Long array literals were slightly broken Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/LiteralNode.java + test/script/basic/JDK-8017082.js Changeset: 69ec02d12a31 Author: lagergren Date: 2013-07-02 15:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/69ec02d12a31 Merge Changeset: 16c4535abcf8 Author: sundar Date: 2013-07-02 18:39 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/16c4535abcf8 Merge From coleen.phillimore at oracle.com Tue Jul 2 09:43:40 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 02 Jul 2013 16:43:40 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130702164348.A8DBF4870E@hg.openjdk.java.net> Changeset: de2d15ce3d4a Author: coleenp Date: 2013-07-02 08:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/de2d15ce3d4a 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadata space could occur when metaspace is almost empty Summary: Allocate medium chunks for class metaspace when class loader has lots of classes Reviewed-by: mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: cedf20e2a655 Author: coleenp Date: 2013-07-02 16:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cedf20e2a655 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/vmStructs.cpp From dmitry.samersoff at oracle.com Tue Jul 2 10:52:34 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 02 Jul 2013 21:52:34 +0400 Subject: RR(S): 8011038 sourceObj validation during desereliazation of RelationNotification should be relaxed Message-ID: <51D31362.3040707@oracle.com> Hi Everybody, *problem* Despite the fact, that validation in constructor of RelationNotification prohibit creation of the class instance with null sourceObj its possible to set it to null later by public setSource() method. So we should relax validation rules to preserve serialization behavior compatibility. *webrev* http://cr.openjdk.java.net/~dsamersoff/8011038/webrev.01/ *testing* JCK, no separate regression tests required. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From kumar.x.srinivasan at oracle.com Tue Jul 2 11:02:51 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 02 Jul 2013 18:02:51 +0000 Subject: hg: jdk8/tl/langtools: 8019460: tests in changeset do not have @bug tag Message-ID: <20130702180256.6783C48710@hg.openjdk.java.net> Changeset: 565341d436e2 Author: ksrini Date: 2013-07-01 16:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/565341d436e2 8019460: tests in changeset do not have @bug tag Reviewed-by: darcy ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.out ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary1.out ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary2.out ! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java From daniel.fuchs at oracle.com Tue Jul 2 11:26:15 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Tue, 02 Jul 2013 18:26:15 +0000 Subject: hg: jdk8/tl/jdk: 7184195: java.util.logging.Logger.getGlobal().info() doesn't log without configuration Message-ID: <20130702182637.740EA48712@hg.openjdk.java.net> Changeset: 70bff2d12af0 Author: dfuchs Date: 2013-07-02 19:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70bff2d12af0 7184195: java.util.logging.Logger.getGlobal().info() doesn't log without configuration Summary: Due to subtle synchronization issues between LogManager & Logger class initialization the global logger doesn't have its 'manager' field initialized until the LogManager is initialized. This fix will ensure that the global logger has its 'manager' field set when getGlobal() is called. Reviewed-by: mchung, plevart ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/Logger/getGlobal/TestGetGlobal.java + test/java/util/logging/Logger/getGlobal/TestGetGlobalByName.java + test/java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java + test/java/util/logging/Logger/getGlobal/logging.properties + test/java/util/logging/Logger/getGlobal/policy + test/java/util/logging/Logger/getGlobal/testgetglobal/BadLogManagerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/DummyLogManagerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/HandlerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl1.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl2.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl3.java From vicente.romero at oracle.com Tue Jul 2 14:50:44 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 02 Jul 2013 21:50:44 +0000 Subject: hg: jdk8/tl/langtools: 6326693: variable x might already have been assigned, when assignment is in catch block Message-ID: <20130702215049.B6D8C48724@hg.openjdk.java.net> Changeset: 3b4f92a3797f Author: vromero Date: 2013-07-02 22:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3b4f92a3797f 6326693: variable x might already have been assigned, when assignment is in catch block Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.java + test/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.out From mandy.chung at oracle.com Tue Jul 2 16:01:31 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 02 Jul 2013 23:01:31 +0000 Subject: hg: jdk8/tl/jdk: 8007035: deprecate public void SecurityManager.checkMemberAccess(Class clazz, int which) Message-ID: <20130702230213.79CF848732@hg.openjdk.java.net> Changeset: cf7202b32a34 Author: mchung Date: 2013-07-02 15:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf7202b32a34 8007035: deprecate public void SecurityManager.checkMemberAccess(Class clazz, int which) Reviewed-by: jrose, alanb, dfuchs ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/reflect/Member.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java + test/java/lang/invoke/TestPrivateMember.java From shanliang.jiang at oracle.com Tue Jul 2 23:47:42 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 03 Jul 2013 08:47:42 +0200 Subject: RR(S): 8011038 sourceObj validation during desereliazation of RelationNotification should be relaxed In-Reply-To: <51D31362.3040707@oracle.com> References: <51D31362.3040707@oracle.com> Message-ID: <51D3C90E.4050705@oracle.com> The constructor Javadoc says: "Throws IllegalArgumentException if no source object", we have to modify the spec if the implementation is changed. Shanliang Dmitry Samersoff wrote: > Hi Everybody, > > *problem* > > Despite the fact, that validation in constructor of RelationNotification > prohibit creation of the class instance with null sourceObj its possible > to set it to null later by public setSource() method. So we should relax > validation rules to preserve serialization behavior compatibility. > > *webrev* > > http://cr.openjdk.java.net/~dsamersoff/8011038/webrev.01/ > > *testing* > > JCK, no separate regression tests required. > > From shanliang.jiang at oracle.com Wed Jul 3 00:00:51 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 03 Jul 2013 09:00:51 +0200 Subject: RR(S): 8011038 sourceObj validation during desereliazation of RelationNotification should be relaxed In-Reply-To: <51D3C90E.4050705@oracle.com> References: <51D31362.3040707@oracle.com> <51D3C90E.4050705@oracle.com> Message-ID: <51D3CC23.3080100@oracle.com> After reading again the constructor Javadoc: "sourceObj - source object, sending the notification. This is either an ObjectName or a RelationService object. In the latter case it must be the MBean emitting the notification; the MBean Server will rewrite the source to be the ObjectName under which that MBean is registered." In this case, should we override instead the method "setSource" to refuse a null value and do the necessary check? like setSource(Object source) { if (!(sourceObj instanceof RelationService) && !(sourceObj instanceof ObjectName))) { throw new IllegalArgumentException(); } } Shanliang shanliang wrote: > The constructor Javadoc says: "Throws IllegalArgumentException if no > source object", we have to modify the spec if the implementation is > changed. > > Shanliang > > Dmitry Samersoff wrote: >> Hi Everybody, >> >> *problem* >> >> Despite the fact, that validation in constructor of RelationNotification >> prohibit creation of the class instance with null sourceObj its possible >> to set it to null later by public setSource() method. So we should relax >> validation rules to preserve serialization behavior compatibility. >> >> *webrev* >> >> http://cr.openjdk.java.net/~dsamersoff/8011038/webrev.01/ >> >> *testing* >> >> JCK, no separate regression tests required. >> >> > > From dmitry.samersoff at oracle.com Wed Jul 3 01:51:59 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 03 Jul 2013 12:51:59 +0400 Subject: RR(S): 8011038 sourceObj validation during desereliazation of RelationNotification should be relaxed In-Reply-To: <51D3CC23.3080100@oracle.com> References: <51D31362.3040707@oracle.com> <51D3C90E.4050705@oracle.com> <51D3CC23.3080100@oracle.com> Message-ID: <51D3E62F.1000701@oracle.com> Shanlinag, The main goal of this fix - is preserve a compatibility in cross-version environment upon request of JCK team. i.e. it's possible to create an RelationNotification instance using early version of JDK, set sourceObj to null, serialize it and give this serialized object to latest update with the validation. So we can't refuse such serialized stream and as soon as null sourceObject can't cause any harm I decided to relax a valiadation during *desereliazion*. Constructor is not affected - it still throws IAE if sourceObj is null, as it happens today and described in javadoc. I'm not sure whether it make sense to change setSource as well to prevent setting sourceObject to null in the future - probably yes, but compatibility impact of these changes have to be evaluated separately and it's clearly out of scope of this CR. -Dmitry On 2013-07-03 11:00, shanliang wrote: > After reading again the constructor Javadoc: > > "sourceObj - source object, sending the notification. This is either an > ObjectName or a RelationService object. In the latter case it must be > the MBean emitting the notification; the MBean Server will rewrite the > source to be the ObjectName under which that MBean is registered." > > In this case, should we override instead the method "setSource" to > refuse a null value and do the necessary check? like > setSource(Object source) { > if (!(sourceObj instanceof RelationService) && > !(sourceObj instanceof ObjectName))) { > throw new IllegalArgumentException(); > } > } > Shanliang > > shanliang wrote: >> The constructor Javadoc says: "Throws IllegalArgumentException if no >> source object", we have to modify the spec if the implementation is >> changed. >> >> Shanliang >> >> Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> *problem* >>> >>> Despite the fact, that validation in constructor of RelationNotification >>> prohibit creation of the class instance with null sourceObj its possible >>> to set it to null later by public setSource() method. So we should relax >>> validation rules to preserve serialization behavior compatibility. >>> >>> *webrev* >>> >>> http://cr.openjdk.java.net/~dsamersoff/8011038/webrev.01/ >>> >>> *testing* >>> >>> JCK, no separate regression tests required. >>> >>> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From shanliang.jiang at oracle.com Wed Jul 3 02:12:15 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 03 Jul 2013 11:12:15 +0200 Subject: RR(S): 8011038 sourceObj validation during desereliazation of RelationNotification should be relaxed In-Reply-To: <51D3E62F.1000701@oracle.com> References: <51D31362.3040707@oracle.com> <51D3C90E.4050705@oracle.com> <51D3CC23.3080100@oracle.com> <51D3E62F.1000701@oracle.com> Message-ID: <51D3EAEF.40708@oracle.com> According to the spec, source should not be null and should be a validated type, and as the spec says: "the MBean Server will rewrite the source to be the ObjectName under which that MBean is registered." in case the source is a RelationService object this means that the MBean Server might get a NPE when treating the source, or a user will get NPE, so it is definitively a bug to set the source null. I am OK if you prefer to fix JCP break at first, then to fix non-null issue in setSource and readObject, but I am afraid that fixing non-null issue would break JCK again, not sure. Shanliang Dmitry Samersoff wrote: > Shanlinag, > > The main goal of this fix - is preserve a compatibility in cross-version > environment upon request of JCK team. > > i.e. it's possible to create an RelationNotification instance using > early version of JDK, set sourceObj to null, serialize it and give this > serialized object to latest update with the validation. > > So we can't refuse such serialized stream and as soon as null > sourceObject can't cause any harm I decided to relax a > valiadation during *desereliazion*. > > Constructor is not affected - it still throws IAE if sourceObj is null, > as it happens today and described in javadoc. > > I'm not sure whether it make sense to change setSource as well to > prevent setting sourceObject to null in the future - probably yes, but > compatibility impact of these changes have to be evaluated separately > and it's clearly out of scope of this CR. > > -Dmitry > > > > On 2013-07-03 11:00, shanliang wrote: > >> After reading again the constructor Javadoc: >> >> "sourceObj - source object, sending the notification. This is either an >> ObjectName or a RelationService object. In the latter case it must be >> the MBean emitting the notification; the MBean Server will rewrite the >> source to be the ObjectName under which that MBean is registered." >> >> In this case, should we override instead the method "setSource" to >> refuse a null value and do the necessary check? like >> setSource(Object source) { >> if (!(sourceObj instanceof RelationService) && >> !(sourceObj instanceof ObjectName))) { >> throw new IllegalArgumentException(); >> } >> } >> Shanliang >> >> shanliang wrote: >> >>> The constructor Javadoc says: "Throws IllegalArgumentException if no >>> source object", we have to modify the spec if the implementation is >>> changed. >>> >>> Shanliang >>> >>> Dmitry Samersoff wrote: >>> >>>> Hi Everybody, >>>> >>>> *problem* >>>> >>>> Despite the fact, that validation in constructor of RelationNotification >>>> prohibit creation of the class instance with null sourceObj its possible >>>> to set it to null later by public setSource() method. So we should relax >>>> validation rules to preserve serialization behavior compatibility. >>>> >>>> *webrev* >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/8011038/webrev.01/ >>>> >>>> *testing* >>>> >>>> JCK, no separate regression tests required. >>>> >>>> >>>> >>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130703/a1309c48/attachment.html From daniel.fuchs at oracle.com Wed Jul 3 02:37:43 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 03 Jul 2013 11:37:43 +0200 Subject: RR(S): 8011038 sourceObj validation during desereliazation of RelationNotification should be relaxed In-Reply-To: <51D31362.3040707@oracle.com> References: <51D31362.3040707@oracle.com> Message-ID: <51D3F0E7.8020300@oracle.com> Hi Dmitry, This looks reasonable to me. You should probably log an RFE on javax.management, to make RelationNotification override setSource() and throw IAE when source is null, so that the behavior of setSource is consistent with the constructor. That would be a spec change - but maybe it's something that could be included in the next JMX Maintenance Review, if there is one. best regards, -- daniel On 7/2/13 7:52 PM, Dmitry Samersoff wrote: > Hi Everybody, > > *problem* > > Despite the fact, that validation in constructor of RelationNotification > prohibit creation of the class instance with null sourceObj its possible > to set it to null later by public setSource() method. So we should relax > validation rules to preserve serialization behavior compatibility. > > *webrev* > > http://cr.openjdk.java.net/~dsamersoff/8011038/webrev.01/ > > *testing* > > JCK, no separate regression tests required. > From dmitry.samersoff at oracle.com Wed Jul 3 02:41:08 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 03 Jul 2013 13:41:08 +0400 Subject: RR(S): 8011038 sourceObj validation during desereliazation of RelationNotification should be relaxed In-Reply-To: <51D3F0E7.8020300@oracle.com> References: <51D31362.3040707@oracle.com> <51D3F0E7.8020300@oracle.com> Message-ID: <51D3F1B4.6010908@oracle.com> Daniel, Will do! -Dmitry On 2013-07-03 13:37, Daniel Fuchs wrote: > Hi Dmitry, > > This looks reasonable to me. > > You should probably log an RFE on javax.management, to make > RelationNotification override setSource() and throw IAE when > source is null, so that the behavior of setSource is consistent > with the constructor. > > That would be a spec change - but maybe it's something that > could be included in the next JMX Maintenance Review, if there > is one. > > best regards, > > -- daniel > > > On 7/2/13 7:52 PM, Dmitry Samersoff wrote: >> Hi Everybody, >> >> *problem* >> >> Despite the fact, that validation in constructor of RelationNotification >> prohibit creation of the class instance with null sourceObj its possible >> to set it to null later by public setSource() method. So we should relax >> validation rules to preserve serialization behavior compatibility. >> >> *webrev* >> >> http://cr.openjdk.java.net/~dsamersoff/8011038/webrev.01/ >> >> *testing* >> >> JCK, no separate regression tests required. >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Wed Jul 3 02:43:34 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 03 Jul 2013 13:43:34 +0400 Subject: RR(S): 8011038 sourceObj validation during desereliazation of RelationNotification should be relaxed In-Reply-To: <51D3EAEF.40708@oracle.com> References: <51D31362.3040707@oracle.com> <51D3C90E.4050705@oracle.com> <51D3CC23.3080100@oracle.com> <51D3E62F.1000701@oracle.com> <51D3EAEF.40708@oracle.com> Message-ID: <51D3F246.2000802@oracle.com> Shanliang, Thank you for gnarly details. On 2013-07-03 13:12, shanliang wrote: > According to the spec, source should not be null and should be a > validated type, and as the spec says: > "the MBean Server will rewrite the source to be the ObjectName under > which that MBean is registered." in case the source is a RelationService > object > > this means that the MBean Server might get a NPE when treating the > source, or a user will get NPE, so it is definitively a bug to set the > source null. > > I am OK if you prefer to fix JCP break at first, then to fix non-null > issue in setSource and readObject, but I am afraid that fixing non-null > issue would break JCK again, not sure. I'm working with JCK team to have it cleaned up. -Dmitry > > Shanliang > > Dmitry Samersoff wrote: >> Shanlinag, >> >> The main goal of this fix - is preserve a compatibility in cross-version >> environment upon request of JCK team. >> >> i.e. it's possible to create an RelationNotification instance using >> early version of JDK, set sourceObj to null, serialize it and give this >> serialized object to latest update with the validation. >> >> So we can't refuse such serialized stream and as soon as null >> sourceObject can't cause any harm I decided to relax a >> valiadation during *desereliazion*. >> >> Constructor is not affected - it still throws IAE if sourceObj is null, >> as it happens today and described in javadoc. >> >> I'm not sure whether it make sense to change setSource as well to >> prevent setting sourceObject to null in the future - probably yes, but >> compatibility impact of these changes have to be evaluated separately >> and it's clearly out of scope of this CR. >> >> -Dmitry >> >> >> >> On 2013-07-03 11:00, shanliang wrote: >> >>> After reading again the constructor Javadoc: >>> >>> "sourceObj - source object, sending the notification. This is either an >>> ObjectName or a RelationService object. In the latter case it must be >>> the MBean emitting the notification; the MBean Server will rewrite the >>> source to be the ObjectName under which that MBean is registered." >>> >>> In this case, should we override instead the method "setSource" to >>> refuse a null value and do the necessary check? like >>> setSource(Object source) { >>> if (!(sourceObj instanceof RelationService) && >>> !(sourceObj instanceof ObjectName))) { >>> throw new IllegalArgumentException(); >>> } >>> } >>> Shanliang >>> >>> shanliang wrote: >>> >>>> The constructor Javadoc says: "Throws IllegalArgumentException if no >>>> source object", we have to modify the spec if the implementation is >>>> changed. >>>> >>>> Shanliang >>>> >>>> Dmitry Samersoff wrote: >>>> >>>>> Hi Everybody, >>>>> >>>>> *problem* >>>>> >>>>> Despite the fact, that validation in constructor of RelationNotification >>>>> prohibit creation of the class instance with null sourceObj its possible >>>>> to set it to null later by public setSource() method. So we should relax >>>>> validation rules to preserve serialization behavior compatibility. >>>>> >>>>> *webrev* >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/8011038/webrev.01/ >>>>> >>>>> *testing* >>>>> >>>>> JCK, no separate regression tests required. >>>>> >>>>> >>>>> >>>> >> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From shanliang.jiang at oracle.com Wed Jul 3 03:33:11 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 03 Jul 2013 12:33:11 +0200 Subject: Codereview for JDK-8016221: A unit test should not use a fixed port to run a jmx connector (JDCMD MBean Tests) In-Reply-To: <51C16D83.2030709@oracle.com> References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com> <51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com> <51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com> <51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com> <51B8259A.10409@oracle.com> <51B829B5.3030305@oracle.com> <51C16D83.2030709@oracle.com> Message-ID: <51D3FDE7.7000809@oracle.com> Thanks Jaroslav and Daniel for the code review. Still not get review from a code reviewer, not sure I could do push with the current reviews, this is a simple test fix, and only changing way to start a JMX connector server/client: allowing RMI Sever to use an any free port, instead to specify a fixed port. Thanks, Shanliang Daniel Fuchs wrote: > Hi Shanliang, > > This change looks good. > There's probably a subtle difference between invoking a command > through a user created JMXConnectorServer as opposed as sending it > through the default agent - but I don't think that's what matters > here. > > cheers, > > -- daniel > > On 6/12/13 9:56 AM, shanliang wrote: >> Re-send with right subject :) >> >> Shanliang >> >> shanliang wrote: >>> Hi, >>> >>> The fix is to address https://jbs.oracle.com/bugs/browse/JDK-8016221 >>> >>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8016221/webrev.00/ >>> >>> Instead to use a fixed port to run a JMX connector, we specify the >>> port as 0: >>> JMXServiceURL url = new JMXServiceURL("rmi", null, 0); >>> to allow JMX to select a free port. >>> >>> and the fix makes sure to close the client and server when the test is >>> finished (passed or failed). >>> >>> Shanliang >>> >>> >> > From paul.sandoz at oracle.com Wed Jul 3 05:54:18 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 03 Jul 2013 12:54:18 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130703125507.2369B4875F@hg.openjdk.java.net> Changeset: dfd7fb0ce54b Author: psandoz Date: 2013-07-03 11:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfd7fb0ce54b 8011427: java.util.concurrent collection Spliterator implementations Reviewed-by: martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/BlockingDeque.java ! src/share/classes/java/util/concurrent/BlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ! src/share/classes/java/util/concurrent/DelayQueue.java ! src/share/classes/java/util/concurrent/Delayed.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java Changeset: bb4ae17c98cf Author: psandoz Date: 2013-07-03 11:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb4ae17c98cf 8019481: Sync misc j.u.c classes from 166 to tl Reviewed-by: martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/BrokenBarrierException.java ! src/share/classes/java/util/concurrent/CountDownLatch.java ! src/share/classes/java/util/concurrent/CyclicBarrier.java ! src/share/classes/java/util/concurrent/Exchanger.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/TimeUnit.java ! src/share/classes/java/util/concurrent/TimeoutException.java ! src/share/classes/java/util/concurrent/package-info.java From ivan.gerasimov at oracle.com Wed Jul 3 10:12:44 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 03 Jul 2013 21:12:44 +0400 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification Message-ID: <51D45B8C.7010109@oracle.com> Hello everybody! We have a request to improve jtreg test. The test had been written to verify fix for memory leak during class redefinition. The problem is that it always is reported as PASSED even in the presence of the leak. The proposed change is platform specific. It allows memory leak detection only on Linux. This is because the memory leak was in native code, so there's no easy way to detect it from within Java code. Here's the webrev for JDK8 repository: http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ The surprising thing is that modified test detected the leak with the latest JDK8! Latest 6 and 7 are fine, so it might be regression in JDK8. I've filled a bug http://bugs.sun.com/view_bug.do?bug_id=8019845 "Memory leak during class redefenition" (not yet available.) Sincerely yours, Ivan Gerasimov From christian.thalinger at oracle.com Wed Jul 3 11:35:35 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 03 Jul 2013 18:35:35 +0000 Subject: hg: jdk8/tl/jdk: 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs Message-ID: <20130703183551.94D184877E@hg.openjdk.java.net> Changeset: bd6949f9dbb2 Author: twisti Date: 2013-07-03 11:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd6949f9dbb2 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandleImpl.java + test/java/lang/invoke/TestCatchExceptionWithVarargs.java From paul.sandoz at oracle.com Wed Jul 3 12:45:33 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 03 Jul 2013 19:45:33 +0000 Subject: hg: jdk8/tl/jdk: 8017329: 8b92-lambda regression: TreeSet("a", "b").stream().substream(1).parallel().iterator() is empty Message-ID: <20130703194555.B9B5748789@hg.openjdk.java.net> Changeset: 7532bb2d6476 Author: psandoz Date: 2013-07-03 21:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7532bb2d6476 8017329: 8b92-lambda regression: TreeSet("a", "b").stream().substream(1).parallel().iterator() is empty Reviewed-by: alanb ! src/share/classes/java/util/stream/SliceOps.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java From jason.uh at oracle.com Wed Jul 3 12:52:27 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Wed, 03 Jul 2013 19:52:27 +0000 Subject: hg: jdk8/tl/jdk: 8019772: Fix doclint issues in javax.crypto and javax.security subpackages Message-ID: <20130703195302.91BF24878A@hg.openjdk.java.net> Changeset: d5de500c99a3 Author: juh Date: 2013-07-03 12:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5de500c99a3 8019772: Fix doclint issues in javax.crypto and javax.security subpackages Reviewed-by: darcy ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/CipherInputStream.java ! src/share/classes/javax/crypto/ExemptionMechanism.java ! src/share/classes/javax/crypto/KeyAgreement.java ! src/share/classes/javax/crypto/KeyGenerator.java ! src/share/classes/javax/crypto/NullCipher.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/cert/X509Certificate.java From bill.pittore at oracle.com Wed Jul 3 14:17:29 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 03 Jul 2013 17:17:29 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents Message-ID: <51D494E9.2020200@oracle.com> These changes address bug 8014135 which adds support for statically linked agents in the VM. This is a followup to the recent JNI spec changes that addressed statically linked JNI libraries( 8005716). The JEP for this change is the same JEP as the JNI changes: http://openjdk.java.net/jeps/178 Webrevs are here: http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ The changes to jvmti.xml can also be seen in the output file that I placed here: http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html Thanks, bill From vincent.x.ryan at oracle.com Wed Jul 3 14:38:21 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 03 Jul 2013 21:38:21 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130703213902.CE2F048792@hg.openjdk.java.net> Changeset: e594ee7a7c2f Author: vinnie Date: 2013-07-02 16:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e594ee7a7c2f 7165807: Non optimized initialization of NSS crypto library leads to scalability issues Reviewed-by: mullan, valeriep ! make/sun/security/pkcs11/mapfile-vers ! makefiles/mapfiles/libj2pkcs11/mapfile-vers ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/native/sun/security/pkcs11/j2secmod.c ! src/solaris/native/sun/security/pkcs11/j2secmod_md.h ! src/windows/native/sun/security/pkcs11/j2secmod_md.h Changeset: cbee2e595600 Author: vinnie Date: 2013-07-03 14:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cbee2e595600 Merge From joe.darcy at oracle.com Wed Jul 3 14:42:32 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 03 Jul 2013 21:42:32 +0000 Subject: hg: jdk8/tl/jdk: 8019857: Fix doclint errors in java.util.Format* Message-ID: <20130703214302.B967148793@hg.openjdk.java.net> Changeset: a49208237599 Author: bpb Date: 2013-07-03 13:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a49208237599 8019857: Fix doclint errors in java.util.Format* Summary: Fix doclint errors in java.util.Format*. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/Formattable.java ! src/share/classes/java/util/Formatter.java From jeremymanson at google.com Wed Jul 3 15:32:10 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 3 Jul 2013 15:32:10 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51D494E9.2020200@oracle.com> References: <51D494E9.2020200@oracle.com> Message-ID: I know that this is mentioned in the JEP, but does it really make sense to have -agentpath work here, rather than just -agentlib? I would think that specifying a full pathname and getting the library loaded out of the launcher would be a little surprising to people who are basically saying "please load this agent from the given path". Also, in practice, we do something very similar at Google, and, when testing, I find it occasionally useful to be able to say "please load this agent on the command line via the agentpath I gave you, rather than loading the one with the same name I baked into the launcher". (FWIW, when we did this internally at Google, we added a special -XX flag for when the agent is in the launcher. I know that you don't want to go that way, though.) On Wed, Jul 3, 2013 at 2:17 PM, BILL PITTORE wrote: > These changes address bug 8014135 which adds support for statically linked > agents in the VM. This is a followup to the recent JNI spec changes that > addressed statically linked JNI libraries( 8005716). > The JEP for this change is the same JEP as the JNI changes: > http://openjdk.java.net/jeps/**178 > > Webrevs are here: > > http://cr.openjdk.java.net/~**bpittore/8014135/jdk/webrev.**00/ > http://cr.openjdk.java.net/~**bpittore/8014135/hotspot/**webrev.00/ > > The changes to jvmti.xml can also be seen in the output file that I placed > here: > http://cr.openjdk.java.net/~**bpittore/8014135/hotspot/** > webrev.00/jvmti.html > > Thanks, > bill > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130703/001bee01/attachment.html From coleen.phillimore at oracle.com Wed Jul 3 16:18:01 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 03 Jul 2013 23:18:01 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8019833: Wrong JNI error code for preexisting JVM Message-ID: <20130703231806.6DF024879D@hg.openjdk.java.net> Changeset: f323bbb0e6c1 Author: coleenp Date: 2013-07-03 13:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f323bbb0e6c1 8019833: Wrong JNI error code for preexisting JVM Summary: Return the appropriate JNI error message (instead of the generic one) when the JVM is already started Reviewed-by: coleenp, hseigel Contributed-by: sylvestre at debian.org ! src/share/vm/prims/jni.cpp From eric.mccorkle at oracle.com Wed Jul 3 16:47:43 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Wed, 03 Jul 2013 23:47:43 +0000 Subject: hg: jdk8/tl/jdk: 8016285: Add java.lang.reflect.Parameter.isNamePresent() Message-ID: <20130703234807.76FD2487A5@hg.openjdk.java.net> Changeset: a8f51c3341a5 Author: emc Date: 2013-07-03 19:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8f51c3341a5 8016285: Add java.lang.reflect.Parameter.isNamePresent() Summary: Add isNamePresent method to parameter reflection library, which indicates whether or real parameter data is available Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Parameter.java ! test/java/lang/reflect/Parameter/WithParameters.java ! test/java/lang/reflect/Parameter/WithoutParameters.java From joe.darcy at oracle.com Wed Jul 3 17:20:39 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 04 Jul 2013 00:20:39 +0000 Subject: hg: jdk8/tl/jdk: 8019862: Fix doclint errors in java.lang.*. Message-ID: <20130704002121.C1D9D487A6@hg.openjdk.java.net> Changeset: 043b2eb76b0e Author: bpb Date: 2013-07-03 17:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/043b2eb76b0e 8019862: Fix doclint errors in java.lang.*. Summary: Fix doclint errors in java.lang.* Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadLocal.java From rickard.backman at oracle.com Thu Jul 4 02:30:25 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Thu, 4 Jul 2013 11:30:25 +0200 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' Message-ID: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> Hi, can I please have a couple of reviews for this change? The problem in this crash was that we were given an incorrect fp (in this case 0x0) and had a pc that matched the C -> Java entry frame. The code then dereferenced fp +- offset. This change verifies that the fp +- offset is actually on the stack of the thread before doing the derefencing. Webrev: http://cr.openjdk.java.net/~rbackman/8016131/ Thanks /R From vicente.romero at oracle.com Thu Jul 4 02:36:38 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 04 Jul 2013 09:36:38 +0000 Subject: hg: jdk8/tl/langtools: 8009924: some langtools tools do not accept -cp as an alias for -classpath Message-ID: <20130704093643.35F32487C1@hg.openjdk.java.net> Changeset: d6158f8d7235 Author: vromero Date: 2013-07-04 10:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d6158f8d7235 8009924: some langtools tools do not accept -cp as an alias for -classpath Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! src/share/classes/com/sun/tools/javadoc/ToolOption.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/resources/l10n.properties ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties ! test/tools/doclint/tool/HelpTest.out From vicente.romero at oracle.com Thu Jul 4 02:43:43 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 04 Jul 2013 09:43:43 +0000 Subject: hg: jdk8/tl/langtools: 6356530: -Xlint:serial does not flag abstract classes with concrete methods/members Message-ID: <20130704094348.55780487C2@hg.openjdk.java.net> Changeset: 79c3146e417b Author: vromero Date: 2013-07-04 10:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/79c3146e417b 6356530: -Xlint:serial does not flag abstract classes with concrete methods/members Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.java + test/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.out From serguei.spitsyn at oracle.com Thu Jul 4 03:25:29 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 04 Jul 2013 03:25:29 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51D494E9.2020200@oracle.com> References: <51D494E9.2020200@oracle.com> Message-ID: <51D54D99.8090103@oracle.com> Hi Bill, I've already had a chance to read your webrev several weeks ago, but need more time. Thanks, Serguei On 7/3/13 2:17 PM, BILL PITTORE wrote: > These changes address bug 8014135 which adds support for statically > linked agents in the VM. This is a followup to the recent JNI spec > changes that addressed statically linked JNI libraries( 8005716). > The JEP for this change is the same JEP as the JNI changes: > http://openjdk.java.net/jeps/178 > > Webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ > > The changes to jvmti.xml can also be seen in the output file that I > placed here: > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html > > Thanks, > bill > > From alex.schenkman at oracle.com Thu Jul 4 05:26:57 2013 From: alex.schenkman at oracle.com (Alex Schenkman) Date: Thu, 04 Jul 2013 14:26:57 +0200 Subject: RFR 8014506: Test for Jdp (Java Discovery Protocol) feature In-Reply-To: <7E2E50A8-1FB1-429B-8AAB-94863C215623@oracle.com> References: <51A31867.9080602@oracle.com> <51CAC09B.7070706@oracle.com> <7E2E50A8-1FB1-429B-8AAB-94863C215623@oracle.com> Message-ID: <51D56A11.5030600@oracle.com> Thanks Staffan for your comments. The indentation is corrected in all files, sorry about that. About the racing condition in PortFinder.java, you are absolutely right, there is no warranty that this port will be free. I do not know a better way to do this. Any suggestions? On the other hand, even if this fails every now and then, it will work most of the times and it is better than what we have today. I have added better comments in PortFinder to reflect the problem. The new webrev is here [1], at the same address than before. Thanks! [1] http://cr.openjdk.java.net/~dsamersoff/8014506/webrev.01/ PS: PortFinder.java, line 37: There is an extra

tag that should be removed. On 2013-06-26 13:54, Staffan Larsen wrote: > test/lib/testlibrary/jdk/testlibrary/PortFinder.java: > > - This looks racy to me. There is no guarantee that the port will still be available after the call to close(). > - Missing copyright notice. > - In comment "on of them" -> "one of them" > > test/sun/management/jdp/ClientConnection.java: > > - broken indentation > - inconsistent spacing in method calls. Sometime "joinGroup(address);" and sometimes "setSoTimeout( msTimeOut );". Should be without spaces. > > test/sun/management/jdp/DynamicLauncher.java: > > - type: binded -> bound > - inconsistent spacing in method calls > > test/sun/management/jdp/JdpOffTest.java > > - broken indentation > > test/sun/management/jdp/JdpTestUtil.java > > - broken indentation > > > I stopped reading here. Can we get these basic things fixed before the next review round, please? > > /Staffan > > > On 26 jun 2013, at 12:21, Dmitry Samersoff wrote: > >> Nils, >> >> I'm sponsoring this push but don't see any review replies in this thread. >> >> Webrev refreshed against latest tl is here: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8014506/webrev.01/ >> >> -Dmitry >> >> >> On 2013-05-27 12:25, Alex Schenkman wrote: >>> Please review these tests for the Jdp protocol. >>> >>> There are three cases: >>> 1) Jdp is off. >>> 2) Jdp is on and using default address and port. >>> 3) Jdp is on using custom address and port. >>> >>> Tests:http://cr.openjdk.java.net/~nloodin/8014506/webrev.00/ >>> >>> Jdp feature enhancement:https://jbs.oracle.com/bugs/browse/JDK-8002048 >>> JDK CCC:http://ccc.us.oracle.com/8002048 >>> >>> >>> Thanks in advance! >>> >>> -- >>> Alex Schenkman >>> Java VM SQE Stockholm >>> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -- Alex Schenkman Java VM SQE Stockholm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130704/608832a1/attachment.html From ivan.gerasimov at oracle.com Thu Jul 4 07:14:53 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 04 Jul 2013 18:14:53 +0400 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51D45B8C.7010109@oracle.com> References: <51D45B8C.7010109@oracle.com> Message-ID: <51D5835D.606@oracle.com> Hello again! > > We have a request to improve jtreg test. > The test had been written to verify fix for memory leak during class > redefinition. > The problem is that it always is reported as PASSED even in the > presence of the leak. > > The proposed change is platform specific. > It allows memory leak detection only on Linux. > This is because the memory leak was in native code, so there's no easy > way to detect it from within Java code. > > Here's the webrev for JDK8 repository: > http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ > > The surprising thing is that modified test detected the leak with the > latest JDK8! > Latest 6 and 7 are fine, so it might be regression in JDK8. > > I've filled a bug http://bugs.sun.com/view_bug.do?bug_id=8019845 > "Memory leak during class redefenition" (not yet available.) > As pointed out by Stefan Karlsson, the detected leak may not be related to the class redefinition and be related to [1] instead. However the webrev is still relevant, so welcome to review! [1] http://bugs.sun.com/view_bug.do?bug_id=8003419 > Sincerely yours, > Ivan Gerasimov > > From alan.bateman at oracle.com Thu Jul 4 06:56:02 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 04 Jul 2013 13:56:02 +0000 Subject: hg: jdk8/tl/jdk: 8019622: (sl) ServiceLoader.next incorrect when creation and usages are in different contexts Message-ID: <20130704135636.738E3487CA@hg.openjdk.java.net> Changeset: dd69273a0240 Author: alanb Date: 2013-07-04 14:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd69273a0240 8019622: (sl) ServiceLoader.next incorrect when creation and usages are in different contexts Reviewed-by: mchung, ahgross, forax, psandoz ! src/share/classes/java/util/ServiceLoader.java From daniel.daugherty at oracle.com Thu Jul 4 08:34:05 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 04 Jul 2013 09:34:05 -0600 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51D45B8C.7010109@oracle.com> References: <51D45B8C.7010109@oracle.com> Message-ID: <51D595ED.7050902@oracle.com> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: > Hello everybody! > > We have a request to improve jtreg test. > The test had been written to verify fix for memory leak during class > redefinition. > The problem is that it always is reported as PASSED even in the > presence of the leak. > > The proposed change is platform specific. > It allows memory leak detection only on Linux. > This is because the memory leak was in native code, so there's no easy > way to detect it from within Java code. > > Here's the webrev for JDK8 repository: > http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ Very nicely done! The logic in RedefineBigClass.sh only catches a leak big enough to cause an Exception to be thrown. When I originally wrote this test and its companion: test/java/lang/instrument/RetransformBigClass* I could not come up with a platform independent way to put a small upper limit on memory growth. It never dawned on me that putting in something on one platform (Linux) was better than nothing. Are you planning to add this same logic to RetransformBigClass*? test/java/lang/instrument/RedefineBigClass.sh No comments. test/java/lang/instrument/RedefineBigClassApp.java line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb Would be better at the top of RedefineBigClassApp rather than "buried" down here. line 51: Long.valueOf(vmMemDelta) There are several places where a long is passed to Long.valueOf(). Is there some reason you're not passing them directly to println()? line 54: } else { The "else" is redundant due to the "System.exit(1)" call above it. You can drop the "else {" and "}" and shift that last println() to the left. line 71: return Long.parseLong(line.split(" ")[22]) / 1024; How about at least a comment referring to the Linux proc(5) man page... and the fact that the 23rd field is: vsize %lu Virtual memory size in bytes. Again, very nicely done! Dan > > The surprising thing is that modified test detected the leak with the > latest JDK8! > Latest 6 and 7 are fine, so it might be regression in JDK8. > > I've filled a bug http://bugs.sun.com/view_bug.do?bug_id=8019845 > "Memory leak during class redefenition" (not yet available.) > > Sincerely yours, > Ivan Gerasimov > > > From Alan.Bateman at oracle.com Thu Jul 4 09:41:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Jul 2013 17:41:49 +0100 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51D494E9.2020200@oracle.com> References: <51D494E9.2020200@oracle.com> Message-ID: <51D5A5CD.2070805@oracle.com> On 03/07/2013 22:17, BILL PITTORE wrote: > These changes address bug 8014135 which adds support for statically > linked agents in the VM. This is a followup to the recent JNI spec > changes that addressed statically linked JNI libraries( 8005716). > The JEP for this change is the same JEP as the JNI changes: > http://openjdk.java.net/jeps/178 > > Webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ I looked at the javadoc updates to the attach API. One thing that doesn't come across very clearly is the mapping from the agentLibrary parameter to "agent-lib-name". I think that needs a few words so that it's clear that it is not literally looking for "Agent_OnAttach_agent-lib-name" but rather "Agent_OnAttach" + where is the library name in the agentLibrary parameter. As I recall, the JVM Tool Interface is supposed to be referred so as "JVM TI" rather than "JVMTI". Otherwise it looks okay to me. -Alan From ivan.gerasimov at oracle.com Thu Jul 4 10:19:50 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 04 Jul 2013 21:19:50 +0400 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51D595ED.7050902@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> Message-ID: <51D5AEB6.3060608@oracle.com> Daniel, thank you for review! Here's the updated with all all your suggestions adopted. http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ I haven't yet considered applying the approach to RetransformBigClass. Do you want me to include this into this same change set or should I make it separately? Sincerely yours, Ivan On 04.07.2013 19:34, Daniel D. Daugherty wrote: > On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >> Hello everybody! >> >> We have a request to improve jtreg test. >> The test had been written to verify fix for memory leak during class >> redefinition. >> The problem is that it always is reported as PASSED even in the >> presence of the leak. >> >> The proposed change is platform specific. >> It allows memory leak detection only on Linux. >> This is because the memory leak was in native code, so there's no >> easy way to detect it from within Java code. >> >> Here's the webrev for JDK8 repository: >> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ > > Very nicely done! The logic in RedefineBigClass.sh only catches a > leak big enough to cause an Exception to be thrown. > > When I originally wrote this test and its companion: > > test/java/lang/instrument/RetransformBigClass* > > I could not come up with a platform independent way to put a small > upper limit on memory growth. It never dawned on me that putting in > something on one platform (Linux) was better than nothing. > > Are you planning to add this same logic to RetransformBigClass*? > > > > test/java/lang/instrument/RedefineBigClass.sh > No comments. > > test/java/lang/instrument/RedefineBigClassApp.java > line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb > Would be better at the top of RedefineBigClassApp rather than > "buried" down here. > > line 51: Long.valueOf(vmMemDelta) > There are several places where a long is passed to > Long.valueOf(). > Is there some reason you're not passing them directly to > println()? > > line 54: } else { > The "else" is redundant due to the "System.exit(1)" call above > it. > You can drop the "else {" and "}" and shift that last > println() to > the left. > > line 71: return Long.parseLong(line.split(" ")[22]) / 1024; > How about at least a comment referring to the Linux proc(5) > man page... and the fact that the 23rd field is: > > vsize %lu Virtual memory size in bytes. > > Again, very nicely done! > > Dan > > >> >> The surprising thing is that modified test detected the leak with the >> latest JDK8! >> Latest 6 and 7 are fine, so it might be regression in JDK8. >> >> I've filled a bug http://bugs.sun.com/view_bug.do?bug_id=8019845 >> "Memory leak during class redefenition" (not yet available.) >> >> Sincerely yours, >> Ivan Gerasimov >> >> >> > > > From daniel.daugherty at oracle.com Thu Jul 4 10:45:41 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 04 Jul 2013 11:45:41 -0600 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51D5AEB6.3060608@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> Message-ID: <51D5B4C5.7060402@oracle.com> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: > Daniel, thank you for review! > > Here's the updated with all all your suggestions adopted. > http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ Looks good. > > I haven't yet considered applying the approach to RetransformBigClass. > Do you want me to include this into this same change set or should I > make it separately? I would include it in the same changeset. Dan > > Sincerely yours, > Ivan > > > On 04.07.2013 19:34, Daniel D. Daugherty wrote: >> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>> Hello everybody! >>> >>> We have a request to improve jtreg test. >>> The test had been written to verify fix for memory leak during class >>> redefinition. >>> The problem is that it always is reported as PASSED even in the >>> presence of the leak. >>> >>> The proposed change is platform specific. >>> It allows memory leak detection only on Linux. >>> This is because the memory leak was in native code, so there's no >>> easy way to detect it from within Java code. >>> >>> Here's the webrev for JDK8 repository: >>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >> >> Very nicely done! The logic in RedefineBigClass.sh only catches a >> leak big enough to cause an Exception to be thrown. >> >> When I originally wrote this test and its companion: >> >> test/java/lang/instrument/RetransformBigClass* >> >> I could not come up with a platform independent way to put a small >> upper limit on memory growth. It never dawned on me that putting in >> something on one platform (Linux) was better than nothing. >> >> Are you planning to add this same logic to RetransformBigClass*? >> >> >> >> test/java/lang/instrument/RedefineBigClass.sh >> No comments. >> >> test/java/lang/instrument/RedefineBigClassApp.java >> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb >> Would be better at the top of RedefineBigClassApp rather than >> "buried" down here. >> >> line 51: Long.valueOf(vmMemDelta) >> There are several places where a long is passed to >> Long.valueOf(). >> Is there some reason you're not passing them directly to >> println()? >> >> line 54: } else { >> The "else" is redundant due to the "System.exit(1)" call >> above it. >> You can drop the "else {" and "}" and shift that last >> println() to >> the left. >> >> line 71: return Long.parseLong(line.split(" ")[22]) / 1024; >> How about at least a comment referring to the Linux proc(5) >> man page... and the fact that the 23rd field is: >> >> vsize %lu Virtual memory size in bytes. >> >> Again, very nicely done! >> >> Dan >> >> >>> >>> The surprising thing is that modified test detected the leak with >>> the latest JDK8! >>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>> >>> I've filled a bug http://bugs.sun.com/view_bug.do?bug_id=8019845 >>> "Memory leak during class redefenition" (not yet available.) >>> >>> Sincerely yours, >>> Ivan Gerasimov >>> >>> >>> >> >> >> > From alan.bateman at oracle.com Thu Jul 4 12:07:10 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 04 Jul 2013 19:07:10 +0000 Subject: hg: jdk8/tl/jdk: 8017231: Add StringJoiner.merge Message-ID: <20130704190737.15232487DD@hg.openjdk.java.net> Changeset: aa9fefb5d9c4 Author: alanb Date: 2013-07-04 20:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aa9fefb5d9c4 8017231: Add StringJoiner.merge Reviewed-by: psandoz, alanb Contributed-by: brian.goetz at oracle.com, henry.jen at oracle.com ! src/share/classes/java/util/StringJoiner.java + test/java/util/StringJoiner/MergeTest.java ! test/java/util/StringJoiner/StringJoinerTest.java From zhengyu.gu at oracle.com Thu Jul 4 13:07:01 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Thu, 04 Jul 2013 20:07:01 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130704200715.29CF1487E0@hg.openjdk.java.net> Changeset: 5f7a4367c787 Author: zgu Date: 2013-07-04 06:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5f7a4367c787 8016074: NMT: assertion failed: assert(thread->thread_state() == from) failed: coming from wrong thread state Summary: Uses os::NakedYield() on Solaris instead of os::yield_all() Reviewed-by: acorn, coleenp, hseigel ! src/share/vm/services/memTracker.hpp Changeset: a55aa67bce1a Author: zgu Date: 2013-07-04 04:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a55aa67bce1a Merge From ivan.gerasimov at oracle.com Thu Jul 4 17:59:18 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 05 Jul 2013 04:59:18 +0400 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51D5B4C5.7060402@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> Message-ID: <51D61A66.5010001@oracle.com> Thank you, Daniel! Please find an updated webrev at http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. It now includes the RetransformBigClass test modified in the same way as RedefineBigClass. If the changes look fine, may I ask you to sponsor the commit, as I'm not a committer? Here's a link to hg export: http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch Thanks in advance, Ivan On 04.07.2013 21:45, Daniel D. Daugherty wrote: > On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >> Daniel, thank you for review! >> >> Here's the updated with all all your suggestions adopted. >> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ > > Looks good. > > >> >> I haven't yet considered applying the approach to RetransformBigClass. >> Do you want me to include this into this same change set or should I >> make it separately? > > I would include it in the same changeset. > > Dan > > >> >> Sincerely yours, >> Ivan >> >> >> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>> Hello everybody! >>>> >>>> We have a request to improve jtreg test. >>>> The test had been written to verify fix for memory leak during >>>> class redefinition. >>>> The problem is that it always is reported as PASSED even in the >>>> presence of the leak. >>>> >>>> The proposed change is platform specific. >>>> It allows memory leak detection only on Linux. >>>> This is because the memory leak was in native code, so there's no >>>> easy way to detect it from within Java code. >>>> >>>> Here's the webrev for JDK8 repository: >>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>> >>> Very nicely done! The logic in RedefineBigClass.sh only catches a >>> leak big enough to cause an Exception to be thrown. >>> >>> When I originally wrote this test and its companion: >>> >>> test/java/lang/instrument/RetransformBigClass* >>> >>> I could not come up with a platform independent way to put a small >>> upper limit on memory growth. It never dawned on me that putting in >>> something on one platform (Linux) was better than nothing. >>> >>> Are you planning to add this same logic to RetransformBigClass*? >>> >>> >>> >>> test/java/lang/instrument/RedefineBigClass.sh >>> No comments. >>> >>> test/java/lang/instrument/RedefineBigClassApp.java >>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb >>> Would be better at the top of RedefineBigClassApp rather than >>> "buried" down here. >>> >>> line 51: Long.valueOf(vmMemDelta) >>> There are several places where a long is passed to >>> Long.valueOf(). >>> Is there some reason you're not passing them directly to >>> println()? >>> >>> line 54: } else { >>> The "else" is redundant due to the "System.exit(1)" call >>> above it. >>> You can drop the "else {" and "}" and shift that last >>> println() to >>> the left. >>> >>> line 71: return Long.parseLong(line.split(" ")[22]) / 1024; >>> How about at least a comment referring to the Linux proc(5) >>> man page... and the fact that the 23rd field is: >>> >>> vsize %lu Virtual memory size in bytes. >>> >>> Again, very nicely done! >>> >>> Dan >>> >>> >>>> >>>> The surprising thing is that modified test detected the leak with >>>> the latest JDK8! >>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>> >>>> I've filled a bug http://bugs.sun.com/view_bug.do?bug_id=8019845 >>>> "Memory leak during class redefenition" (not yet available.) >>>> >>>> Sincerely yours, >>>> Ivan Gerasimov >>>> >>>> >>>> >>> >>> >>> >> > > > From luchsh at linux.vnet.ibm.com Thu Jul 4 19:53:29 2013 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Fri, 05 Jul 2013 02:53:29 +0000 Subject: hg: jdk8/tl/jdk: 8019381: HashMap.isEmpty is non-final, potential issues for get/remove Message-ID: <20130705025350.81E7F487E6@hg.openjdk.java.net> Changeset: ed111451b77a Author: zhangshj Date: 2013-07-05 10:51 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ed111451b77a 8019381: HashMap.isEmpty is non-final, potential issues for get/remove Reviewed-by: chegar, mduigou ! src/share/classes/java/util/HashMap.java + test/java/util/HashMap/OverrideIsEmpty.java From john.coomes at oracle.com Thu Jul 4 21:22:39 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:22:39 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b97 for changeset 469995a8e974 Message-ID: <20130705042243.3730C48809@hg.openjdk.java.net> Changeset: 3370fb6146e4 Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/3370fb6146e4 Added tag jdk8-b97 for changeset 469995a8e974 ! .hgtags From john.coomes at oracle.com Thu Jul 4 21:22:49 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:22:49 +0000 Subject: hg: hsx/hotspot-rt/jaxp: 3 new changesets Message-ID: <20130705042310.77B444880B@hg.openjdk.java.net> Changeset: c96691d84a7c Author: katleman Date: 2013-06-28 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/c96691d84a7c 8019347: JDK8 b96 source with GPL header errors Reviewed-by: iris, alanb, lancea ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_de.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_es.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_it.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_zh_TW.properties Changeset: 6c830db28d21 Author: katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/6c830db28d21 Merge Changeset: 15e5bb51bc0c Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/15e5bb51bc0c Added tag jdk8-b97 for changeset 6c830db28d21 ! .hgtags From john.coomes at oracle.com Thu Jul 4 21:23:21 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:23:21 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b97 for changeset dcde7f049111 Message-ID: <20130705042328.70DCF4880C@hg.openjdk.java.net> Changeset: b1fb4612a2ca Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/b1fb4612a2ca Added tag jdk8-b97 for changeset dcde7f049111 ! .hgtags From john.coomes at oracle.com Thu Jul 4 21:23:38 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:23:38 +0000 Subject: hg: hsx/hotspot-rt/jdk: 4 new changesets Message-ID: <20130705042513.5C3094880D@hg.openjdk.java.net> Changeset: 8339c83b16c6 Author: ehelin Date: 2013-07-02 13:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8339c83b16c6 8019500: Exclude MemoryTest.java and MemoryTestAllGC.sh to enable integration Reviewed-by: erikj, alanb ! test/ProblemList.txt Changeset: 87cab043cb5e Author: katleman Date: 2013-06-28 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/87cab043cb5e 8019347: JDK8 b96 source with GPL header errors Reviewed-by: iris, alanb, lancea ! makefiles/sun/awt/ToBin.java ! src/share/classes/javax/xml/crypto/dsig/dom/DOMValidateContext.java ! test/java/awt/Mouse/EnterExitEvents/FullscreenEnterEventTest.java ! test/java/lang/ThreadGroup/Suspend.java Changeset: 978a95239044 Author: katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/978a95239044 Merge Changeset: 4b21dcfdcc3b Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4b21dcfdcc3b Added tag jdk8-b97 for changeset 978a95239044 ! .hgtags From john.coomes at oracle.com Thu Jul 4 21:26:37 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:26:37 +0000 Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b97 for changeset 6a11a81a8824 Message-ID: <20130705042646.F298F4880E@hg.openjdk.java.net> Changeset: 2364e94ae67b Author: cl Date: 2013-07-04 01:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/2364e94ae67b Added tag jdk8-b97 for changeset 6a11a81a8824 ! .hgtags From john.coomes at oracle.com Thu Jul 4 21:26:51 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:26:51 +0000 Subject: hg: hsx/hotspot-rt/nashorn: Added tag jdk8-b97 for changeset 1bf1d6ce3042 Message-ID: <20130705042654.8A6ED4880F@hg.openjdk.java.net> Changeset: da63a99481da Author: cl Date: 2013-07-04 01:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/da63a99481da Added tag jdk8-b97 for changeset 1bf1d6ce3042 ! .hgtags From daniel.daugherty at oracle.com Thu Jul 4 21:35:33 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 04 Jul 2013 22:35:33 -0600 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51D61A66.5010001@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> Message-ID: <51D64D15.2090105@oracle.com> Ivan, The changes look fine, I can sponsor your commit, looks like your OpenJDK user name is 'igerasim', but I need to know a little bit more about your testing of these fixes. Did you do a test JPRT job to run the JLI tests (or just the two tests themselves)? Based on e-mail about this bug fix, I believe you've found a new leak in JDK8/HSX-25 with test java/lang/instrument/RedefineBigClass.sh. That's a good thing, but I think Alan and company would be a bit grumpy with me if I pushed a test that failed as soon as someone ran it. :-) Do you know if the revised RetransformBigClass.sh also finds a new memory leak in JDK8/HSX-25? The way to deal with that is to put the test on the Problem.list as part of the same changeset. However, the T&L folks might not like that either... Dan On 7/4/13 6:59 PM, Ivan Gerasimov wrote: > Thank you, Daniel! > > Please find an updated webrev at > http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. > It now includes the RetransformBigClass test modified in the same way > as RedefineBigClass > If the changes look fine, may I ask you to sponsor the commit, as I'm > not a committer? > Here's a link to hg export: > http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch > > > Thanks in advance, > Ivan > > On 04.07.2013 21:45, Daniel D. Daugherty wrote: >> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>> Daniel, thank you for review! >>> >>> Here's the updated with all all your suggestions adopted. >>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >> >> Looks good. >> >> >>> >>> I haven't yet considered applying the approach to RetransformBigClass. >>> Do you want me to include this into this same change set or should I >>> make it separately? >> >> I would include it in the same changeset. >> >> Dan >> >> >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>> Hello everybody! >>>>> >>>>> We have a request to improve jtreg test. >>>>> The test had been written to verify fix for memory leak during >>>>> class redefinition. >>>>> The problem is that it always is reported as PASSED even in the >>>>> presence of the leak. >>>>> >>>>> The proposed change is platform specific. >>>>> It allows memory leak detection only on Linux. >>>>> This is because the memory leak was in native code, so there's no >>>>> easy way to detect it from within Java code. >>>>> >>>>> Here's the webrev for JDK8 repository: >>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>> >>>> Very nicely done! The logic in RedefineBigClass.sh only catches a >>>> leak big enough to cause an Exception to be thrown. >>>> >>>> When I originally wrote this test and its companion: >>>> >>>> test/java/lang/instrument/RetransformBigClass* >>>> >>>> I could not come up with a platform independent way to put a small >>>> upper limit on memory growth. It never dawned on me that putting in >>>> something on one platform (Linux) was better than nothing. >>>> >>>> Are you planning to add this same logic to RetransformBigClass*? >>>> >>>> >>>> >>>> test/java/lang/instrument/RedefineBigClass.sh >>>> No comments. >>>> >>>> test/java/lang/instrument/RedefineBigClassApp.java >>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb >>>> Would be better at the top of RedefineBigClassApp rather than >>>> "buried" down here. >>>> >>>> line 51: Long.valueOf(vmMemDelta) >>>> There are several places where a long is passed to >>>> Long.valueOf(). >>>> Is there some reason you're not passing them directly to >>>> println()? >>>> >>>> line 54: } else { >>>> The "else" is redundant due to the "System.exit(1)" call >>>> above it. >>>> You can drop the "else {" and "}" and shift that last >>>> println() to >>>> the left. >>>> >>>> line 71: return Long.parseLong(line.split(" ")[22]) / 1024; >>>> How about at least a comment referring to the Linux proc(5) >>>> man page... and the fact that the 23rd field is: >>>> >>>> vsize %lu Virtual memory size in bytes. >>>> >>>> Again, very nicely done! >>>> >>>> Dan >>>> >>>> >>>>> >>>>> The surprising thing is that modified test detected the leak with >>>>> the latest JDK8! >>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>> >>>>> I've filled a bug http://bugs.sun.com/view_bug.do?bug_id=8019845 >>>>> "Memory leak during class redefenition" (not yet available.) >>>>> >>>>> Sincerely yours, >>>>> Ivan Gerasimov >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130704/aca006b5/attachment.html From john.coomes at oracle.com Thu Jul 4 21:22:32 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:22:32 +0000 Subject: hg: hsx/hotspot-rt: 9 new changesets Message-ID: <20130705042233.3CDBA48807@hg.openjdk.java.net> Changeset: f5eb23490e6a Author: erikj Date: 2013-06-27 09:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/f5eb23490e6a 8017047: Can't use --with-java-devtools and --with-devkit at the same time Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: e5cf1735638c Author: erikj Date: 2013-06-28 11:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/e5cf1735638c 8016605: New files dont apear in src.zip Reviewed-by: tbell ! common/makefiles/JavaCompilation.gmk Changeset: 0871b5799149 Author: erikj Date: 2013-06-28 11:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/0871b5799149 8019229: Build Configuration Fail in Windows Platform Reviewed-by: chegar, tbell, dxu ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 0e533ceee717 Author: erikj Date: 2013-06-28 12:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/0e533ceee717 8016303: make CONF= isn't working Reviewed-by: tbell ! NewMakefile.gmk Changeset: 78aaf5d3314d Author: erikj Date: 2013-06-28 12:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/78aaf5d3314d 8010385: build with LOG=trace broken on mac Reviewed-by: dholmes, tbell, prr ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/MakeBase.gmk Changeset: dd3b314f4471 Author: erikj Date: 2013-07-01 15:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/dd3b314f4471 8009744: build-infra: REGRESSION: Publisher was NOT set for some JDK files Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: b2b87e9e8683 Author: erikj Date: 2013-07-02 15:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/b2b87e9e8683 8019537: jdk8-build prebuild fails in source bundle generation, The path of TOOLS_DIR ... is not found Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: a1c1e8bf71f3 Author: katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/a1c1e8bf71f3 Merge Changeset: 99ad803f8c4e Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/99ad803f8c4e Added tag jdk8-b97 for changeset a1c1e8bf71f3 ! .hgtags From daniel.daugherty at oracle.com Thu Jul 4 22:37:54 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 04 Jul 2013 23:37:54 -0600 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51D64D15.2090105@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> <51D64D15.2090105@oracle.com> Message-ID: <51D65BB2.90503@oracle.com> In a JPRT test job I just ran: RedefineBigClass.sh passed on 9 platforms and failed on Linux 64-bit. RetransformBigClass.sh passed on all 10 platforms. Does your own testing only showing failure on the Linux 64-bit VM and passed on the Linux 32-bit VM? Dan On 7/4/13 10:35 PM, Daniel D. Daugherty wrote: > Ivan, > > The changes look fine, I can sponsor your commit, looks like your > OpenJDK user name is 'igerasim', but I need to know a little bit > more about your testing of these fixes. Did you do a test JPRT > job to run the JLI tests (or just the two tests themselves)? > > Based on e-mail about this bug fix, I believe you've found a new > leak in JDK8/HSX-25 with test java/lang/instrument/RedefineBigClass.sh. > That's a good thing, but I think Alan and company would be a bit > grumpy with me if I pushed a test that failed as soon as someone > ran it. :-) Do you know if the revised RetransformBigClass.sh also > finds a new memory leak in JDK8/HSX-25? > > The way to deal with that is to put the test on the Problem.list > as part of the same changeset. However, the T&L folks might not like > that either... > > Dan > > > On 7/4/13 6:59 PM, Ivan Gerasimov wrote: >> Thank you, Daniel! >> >> Please find an updated webrev at >> http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. >> It now includes the RetransformBigClass test modified in the same way >> as RedefineBigClass >> If the changes look fine, may I ask you to sponsor the commit, as I'm >> not a committer? >> Here's a link to hg export: >> http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch >> >> >> Thanks in advance, >> Ivan >> >> On 04.07.2013 21:45, Daniel D. Daugherty wrote: >>> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>>> Daniel, thank you for review! >>>> >>>> Here's the updated with all all your suggestions adopted. >>>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >>> >>> Looks good. >>> >>> >>>> >>>> I haven't yet considered applying the approach to RetransformBigClass. >>>> Do you want me to include this into this same change set or should >>>> I make it separately? >>> >>> I would include it in the same changeset. >>> >>> Dan >>> >>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>>> Hello everybody! >>>>>> >>>>>> We have a request to improve jtreg test. >>>>>> The test had been written to verify fix for memory leak during >>>>>> class redefinition. >>>>>> The problem is that it always is reported as PASSED even in the >>>>>> presence of the leak. >>>>>> >>>>>> The proposed change is platform specific. >>>>>> It allows memory leak detection only on Linux. >>>>>> This is because the memory leak was in native code, so there's no >>>>>> easy way to detect it from within Java code. >>>>>> >>>>>> Here's the webrev for JDK8 repository: >>>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>>> >>>>> Very nicely done! The logic in RedefineBigClass.sh only catches a >>>>> leak big enough to cause an Exception to be thrown. >>>>> >>>>> When I originally wrote this test and its companion: >>>>> >>>>> test/java/lang/instrument/RetransformBigClass* >>>>> >>>>> I could not come up with a platform independent way to put a small >>>>> upper limit on memory growth. It never dawned on me that putting in >>>>> something on one platform (Linux) was better than nothing. >>>>> >>>>> Are you planning to add this same logic to RetransformBigClass*? >>>>> >>>>> >>>>> >>>>> test/java/lang/instrument/RedefineBigClass.sh >>>>> No comments. >>>>> >>>>> test/java/lang/instrument/RedefineBigClassApp.java >>>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb >>>>> Would be better at the top of RedefineBigClassApp rather than >>>>> "buried" down here. >>>>> >>>>> line 51: Long.valueOf(vmMemDelta) >>>>> There are several places where a long is passed to >>>>> Long.valueOf(). >>>>> Is there some reason you're not passing them directly to >>>>> println()? >>>>> >>>>> line 54: } else { >>>>> The "else" is redundant due to the "System.exit(1)" call >>>>> above it. >>>>> You can drop the "else {" and "}" and shift that last >>>>> println() to >>>>> the left. >>>>> >>>>> line 71: return Long.parseLong(line.split(" ")[22]) / 1024; >>>>> How about at least a comment referring to the Linux proc(5) >>>>> man page... and the fact that the 23rd field is: >>>>> >>>>> vsize %lu Virtual memory size in bytes. >>>>> >>>>> Again, very nicely done! >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> The surprising thing is that modified test detected the leak with >>>>>> the latest JDK8! >>>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>>> >>>>>> I've filled a bug http://bugs.sun.com/view_bug.do?bug_id=8019845 >>>>>> "Memory leak during class redefenition" (not yet available.) >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan Gerasimov >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130704/7d81c7d8/attachment-0001.html From daniel.daugherty at oracle.com Thu Jul 4 23:43:49 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 05 Jul 2013 06:43:49 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8015884: runThese crashed with SIGSEGV, hs_err has an error instead of stacktrace Message-ID: <20130705064354.D3BC148812@hg.openjdk.java.net> Changeset: 59b052799158 Author: dcubed Date: 2013-07-04 21:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/59b052799158 8015884: runThese crashed with SIGSEGV, hs_err has an error instead of stacktrace Summary: Dl_info struct should only be used if dladdr() has returned non-zero (no errors) and always check the dladdr() return value; Dl_info.dli_sname and Dl_info.dli_saddr fields should only be used if non-NULL; update/improve runtime/6888954/vmerrors.sh test Reviewed-by: dsamersoff, zgu, hseigel, coleenp ! 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/os/windows/vm/os_windows.hpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! test/runtime/6888954/vmerrors.sh From maurizio.cimadamore at oracle.com Fri Jul 5 03:08:01 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 05 Jul 2013 10:08:01 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20130705100822.11A394881A@hg.openjdk.java.net> Changeset: 7b756b307e12 Author: mcimadamore Date: 2013-07-05 11:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7b756b307e12 8017618: NullPointerException in RichDiagnosticFormatter for bad input program Summary: RDF crashes when diagnostic contains type 'void' Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/lambda/BadNestedLambda.java + test/tools/javac/lambda/BadNestedLambda.out Changeset: 70b37cdb19d5 Author: mcimadamore Date: 2013-07-05 11:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/70b37cdb19d5 8019480: Javac crashes when method is called on a type-variable receiver from lambda expression Summary: Logic for shortcircuiting speculative attribution doesn't handle type-variable receivers Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/lambda/8019480/T8019480.java + test/tools/javac/lambda/8019480/T8019480.out Changeset: b0386f0dc28e Author: mcimadamore Date: 2013-07-05 11:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b0386f0dc28e 8016059: Cannot compile following lambda 8016060: Lambda isn't compiled with return statement Summary: Spurious error triggered during unnecessary recovery round Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/lambda/TargetType75.java Changeset: bfbedbfc522a Author: mcimadamore Date: 2013-07-05 11:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bfbedbfc522a 8016702: use of ternary operator in lambda expression gives incorrect results Summary: Constant types erroneously creep in during inference Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/conditional/T8016702.java Changeset: 42b3c5e92461 Author: mcimadamore Date: 2013-07-05 11:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/42b3c5e92461 8019824: very long error messages on inference error Summary: Inference error messages shows several spurious captured variables generated during an inference loop Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8019824/T8019824.java + test/tools/javac/generics/inference/8019824/T8019824.out From ivan.gerasimov at oracle.com Fri Jul 5 03:18:01 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 05 Jul 2013 14:18:01 +0400 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51D65BB2.90503@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> <51D64D15.2090105@oracle.com> <51D65BB2.90503@oracle.com> Message-ID: <51D69D59.9020002@oracle.com> I'm looking at the log of the job you've run: http://prt-web.us.oracle.com//archive/2013/07/2013-07-05-045326.ddaugher.8016838_exp/logs/linux_x64-product-c2-jdk_lang.log.FAILED.log And it looks like both tests failed, not only the first one: FAIL: Virtual memory usage increased by 1411072Kb (greater than 32768Kb) FAIL: RedefineBigClassApp exited with status of 1 ... FAIL: Virtual memory usage increased by 1411072Kb (greater than 32768Kb) FAIL: RetransformBigClassApp exited with status of 1 I have these two tests locally on 64-bit Linux and they both fail with similar results in logs. I may not tell for sure why the tests didn't fail on 32-bit Linux. Whether it was because the /proc/self/stat approach didn't work or because the leak is specific to 64-bit platform. I have tested the RedefineBigClass test on JPRT with JDK6 (the code was a bit different, but the approach was the same). The test passed with JDK6u60 and failed (as expected) with JDK6u51 on both 32 and 64-bit Linux machines. I'm going to do more testings today. Sincerely yours, Ivan On 05.07.2013 9:37, Daniel D. Daugherty wrote: > In a JPRT test job I just ran: > > RedefineBigClass.sh passed on 9 platforms and failed on Linux 64-bit. > RetransformBigClass.sh passed on all 10 platforms. > > Does your own testing only showing failure on the Linux 64-bit VM > and passed on the Linux 32-bit VM? > > Dan > > > > On 7/4/13 10:35 PM, Daniel D. Daugherty wrote: >> Ivan, >> >> The changes look fine, I can sponsor your commit, looks like your >> OpenJDK user name is 'igerasim', but I need to know a little bit >> more about your testing of these fixes. Did you do a test JPRT >> job to run the JLI tests (or just the two tests themselves)? >> >> Based on e-mail about this bug fix, I believe you've found a new >> leak in JDK8/HSX-25 with test java/lang/instrument/RedefineBigClass.sh. >> That's a good thing, but I think Alan and company would be a bit >> grumpy with me if I pushed a test that failed as soon as someone >> ran it. :-) Do you know if the revised RetransformBigClass.sh also >> finds a new memory leak in JDK8/HSX-25? >> >> The way to deal with that is to put the test on the Problem.list >> as part of the same changeset. However, the T&L folks might not like >> that either... >> >> Dan >> >> >> On 7/4/13 6:59 PM, Ivan Gerasimov wrote: >>> Thank you, Daniel! >>> >>> Please find an updated webrev at >>> http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. >>> It now includes the RetransformBigClass test modified in the same >>> way as RedefineBigClass >>> If the changes look fine, may I ask you to sponsor the commit, as >>> I'm not a committer? >>> Here's a link to hg export: >>> http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch >>> >>> >>> Thanks in advance, >>> Ivan >>> >>> On 04.07.2013 21:45, Daniel D. Daugherty wrote: >>>> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>>>> Daniel, thank you for review! >>>>> >>>>> Here's the updated with all all your suggestions adopted. >>>>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >>>> >>>> Looks good. >>>> >>>> >>>>> >>>>> I haven't yet considered applying the approach to >>>>> RetransformBigClass. >>>>> Do you want me to include this into this same change set or should >>>>> I make it separately? >>>> >>>> I would include it in the same changeset. >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>>>> Hello everybody! >>>>>>> >>>>>>> We have a request to improve jtreg test. >>>>>>> The test had been written to verify fix for memory leak during >>>>>>> class redefinition. >>>>>>> The problem is that it always is reported as PASSED even in the >>>>>>> presence of the leak. >>>>>>> >>>>>>> The proposed change is platform specific. >>>>>>> It allows memory leak detection only on Linux. >>>>>>> This is because the memory leak was in native code, so there's >>>>>>> no easy way to detect it from within Java code. >>>>>>> >>>>>>> Here's the webrev for JDK8 repository: >>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>>>> >>>>>> Very nicely done! The logic in RedefineBigClass.sh only catches a >>>>>> leak big enough to cause an Exception to be thrown. >>>>>> >>>>>> When I originally wrote this test and its companion: >>>>>> >>>>>> test/java/lang/instrument/RetransformBigClass* >>>>>> >>>>>> I could not come up with a platform independent way to put a small >>>>>> upper limit on memory growth. It never dawned on me that putting in >>>>>> something on one platform (Linux) was better than nothing. >>>>>> >>>>>> Are you planning to add this same logic to RetransformBigClass*? >>>>>> >>>>>> >>>>>> >>>>>> test/java/lang/instrument/RedefineBigClass.sh >>>>>> No comments. >>>>>> >>>>>> test/java/lang/instrument/RedefineBigClassApp.java >>>>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb >>>>>> Would be better at the top of RedefineBigClassApp rather >>>>>> than >>>>>> "buried" down here. >>>>>> >>>>>> line 51: Long.valueOf(vmMemDelta) >>>>>> There are several places where a long is passed to >>>>>> Long.valueOf(). >>>>>> Is there some reason you're not passing them directly to >>>>>> println()? >>>>>> >>>>>> line 54: } else { >>>>>> The "else" is redundant due to the "System.exit(1)" call >>>>>> above it. >>>>>> You can drop the "else {" and "}" and shift that last >>>>>> println() to >>>>>> the left. >>>>>> >>>>>> line 71: return Long.parseLong(line.split(" ")[22]) / 1024; >>>>>> How about at least a comment referring to the Linux proc(5) >>>>>> man page... and the fact that the 23rd field is: >>>>>> >>>>>> vsize %lu Virtual memory size in bytes. >>>>>> >>>>>> Again, very nicely done! >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> The surprising thing is that modified test detected the leak >>>>>>> with the latest JDK8! >>>>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>>>> >>>>>>> I've filled a bug http://bugs.sun.com/view_bug.do?bug_id=8019845 >>>>>>> "Memory leak during class redefenition" (not yet available.) >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan Gerasimov >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130705/86b09f6a/attachment.html From frederic.parain at oracle.com Fri Jul 5 03:31:17 2013 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Fri, 05 Jul 2013 10:31:17 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8016465: The hs_err file gets wrong name Message-ID: <20130705103122.81FE54881D@hg.openjdk.java.net> Changeset: 93e6dce53ba7 Author: fparain Date: 2013-07-05 08:26 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/93e6dce53ba7 8016465: The hs_err file gets wrong name Reviewed-by: dcubed, dholmes, rdurbin ! src/share/vm/utilities/vmError.cpp From ivan.gerasimov at oracle.com Fri Jul 5 03:53:14 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 05 Jul 2013 14:53:14 +0400 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51D64D15.2090105@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> <51D64D15.2090105@oracle.com> Message-ID: <51D6A59A.1060703@oracle.com> On 05.07.2013 8:35, Daniel D. Daugherty wrote: > Ivan, > > The changes look fine, I can sponsor your commit, looks like your > OpenJDK user name is 'igerasim', but I need to know a little bit > more about your testing of these fixes. Did you do a test JPRT > job to run the JLI tests (or just the two tests themselves)? > I've only run test from java/lang/instrument when checked the change with JDK6u60 (all passed) and with JDK6u51 (the test failed as expected, since the leak had still been there.) > Based on e-mail about this bug fix, I believe you've found a new > leak in JDK8/HSX-25 with test java/lang/instrument/RedefineBigClass.sh. Right. The test shown a memleak with the the latest jdk8. I filed a bug 8019845 about this leak. Stefan Karlsson guessed that this may be related to 8003419 (NPG: Clean up metadata created during class loading if failure) Then I've checked the builds b57 (test failed) and b58 (test passed), so I confirmed that it may be the reason of the leak being observed now. But now I think that the reason may be different. It just turns out that the test shows failures for (at least) three different leaks - the one you, Daniel, solved (7121600), the one Stefan wrote about (8003419) and the one currently observed (8019845). > That's a good thing, but I think Alan and company would be a bit > grumpy with me if I pushed a test that failed as soon as someone > ran it. :-) Do you know if the revised RetransformBigClass.sh also > finds a new memory leak in JDK8/HSX-25? > > The way to deal with that is to put the test on the Problem.list > as part of the same changeset. However, the T&L folks might not like > that either... Well, the leak is there, and why not have a failing test as a reminder to have it fixed? Sincerely yours, Ivan Gerasimov > > Dan > > > On 7/4/13 6:59 PM, Ivan Gerasimov wrote: >> Thank you, Daniel! >> >> Please find an updated webrev at >> http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. >> It now includes the RetransformBigClass test modified in the same way >> as RedefineBigClass >> If the changes look fine, may I ask you to sponsor the commit, as I'm >> not a committer? >> Here's a link to hg export: >> http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch >> >> >> Thanks in advance, >> Ivan >> >> On 04.07.2013 21:45, Daniel D. Daugherty wrote: >>> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>>> Daniel, thank you for review! >>>> >>>> Here's the updated with all all your suggestions adopted. >>>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >>> >>> Looks good. >>> >>> >>>> >>>> I haven't yet considered applying the approach to RetransformBigClass. >>>> Do you want me to include this into this same change set or should >>>> I make it separately? >>> >>> I would include it in the same changeset. >>> >>> Dan >>> >>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>>> Hello everybody! >>>>>> >>>>>> We have a request to improve jtreg test. >>>>>> The test had been written to verify fix for memory leak during >>>>>> class redefinition. >>>>>> The problem is that it always is reported as PASSED even in the >>>>>> presence of the leak. >>>>>> >>>>>> The proposed change is platform specific. >>>>>> It allows memory leak detection only on Linux. >>>>>> This is because the memory leak was in native code, so there's no >>>>>> easy way to detect it from within Java code. >>>>>> >>>>>> Here's the webrev for JDK8 repository: >>>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>>> >>>>> Very nicely done! The logic in RedefineBigClass.sh only catches a >>>>> leak big enough to cause an Exception to be thrown. >>>>> >>>>> When I originally wrote this test and its companion: >>>>> >>>>> test/java/lang/instrument/RetransformBigClass* >>>>> >>>>> I could not come up with a platform independent way to put a small >>>>> upper limit on memory growth. It never dawned on me that putting in >>>>> something on one platform (Linux) was better than nothing. >>>>> >>>>> Are you planning to add this same logic to RetransformBigClass*? >>>>> >>>>> >>>>> >>>>> test/java/lang/instrument/RedefineBigClass.sh >>>>> No comments. >>>>> >>>>> test/java/lang/instrument/RedefineBigClassApp.java >>>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb >>>>> Would be better at the top of RedefineBigClassApp rather than >>>>> "buried" down here. >>>>> >>>>> line 51: Long.valueOf(vmMemDelta) >>>>> There are several places where a long is passed to >>>>> Long.valueOf(). >>>>> Is there some reason you're not passing them directly to >>>>> println()? >>>>> >>>>> line 54: } else { >>>>> The "else" is redundant due to the "System.exit(1)" call >>>>> above it. >>>>> You can drop the "else {" and "}" and shift that last >>>>> println() to >>>>> the left. >>>>> >>>>> line 71: return Long.parseLong(line.split(" ")[22]) / 1024; >>>>> How about at least a comment referring to the Linux proc(5) >>>>> man page... and the fact that the 23rd field is: >>>>> >>>>> vsize %lu Virtual memory size in bytes. >>>>> >>>>> Again, very nicely done! >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> The surprising thing is that modified test detected the leak with >>>>>> the latest JDK8! >>>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>>> >>>>>> I've filled a bug http://bugs.sun.com/view_bug.do?bug_id=8019845 >>>>>> "Memory leak during class redefenition" (not yet available.) >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan Gerasimov >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130705/947a96d4/attachment.html From sean.coffey at oracle.com Fri Jul 5 04:45:49 2013 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 05 Jul 2013 12:45:49 +0100 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51D6A59A.1060703@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> <51D64D15.2090105@oracle.com> <51D6A59A.1060703@oracle.com> Message-ID: <51D6B1ED.9090709@oracle.com> Nice work indeed Ivan. Good to have a reliable testcase to catch leaks in this area. I'd also suggest that this test goes on the ProblemList until the new leak is sorted out for jdk8. The goal of JPRT runs is to have clean runs. If it's on the problemList, then it's a known issue and is normally tagged with the relevant bug ID so that the responsible engineer knows the current state. regards, Sean. On 05/07/2013 11:53, Ivan Gerasimov wrote: > > On 05.07.2013 8:35, Daniel D. Daugherty wrote: >> Ivan, >> >> The changes look fine, I can sponsor your commit, looks like your >> OpenJDK user name is 'igerasim', but I need to know a little bit >> more about your testing of these fixes. Did you do a test JPRT >> job to run the JLI tests (or just the two tests themselves)? >> > I've only run test from java/lang/instrument when checked the change > with JDK6u60 (all passed) and with JDK6u51 (the test failed as > expected, since the leak had still been there.) > >> Based on e-mail about this bug fix, I believe you've found a new >> leak in JDK8/HSX-25 with test java/lang/instrument/RedefineBigClass.sh. > Right. The test shown a memleak with the the latest jdk8. > I filed a bug 8019845 about this leak. > Stefan Karlsson guessed that this may be related to 8003419 (NPG: > Clean up metadata created during class loading if failure) > Then I've checked the builds b57 (test failed) and b58 (test passed), > so I confirmed that it may be the reason of the leak being observed now. > But now I think that the reason may be different. > It just turns out that the test shows failures for (at least) three > different leaks - the one you, Daniel, solved (7121600), the one > Stefan wrote about (8003419) and the one currently observed (8019845). > >> That's a good thing, but I think Alan and company would be a bit >> grumpy with me if I pushed a test that failed as soon as someone >> ran it. :-) Do you know if the revised RetransformBigClass.sh also >> finds a new memory leak in JDK8/HSX-25? >> >> The way to deal with that is to put the test on the Problem.list >> as part of the same changeset. However, the T&L folks might not like >> that either... > > Well, the leak is there, and why not have a failing test as a reminder > to have it fixed? > > Sincerely yours, > Ivan Gerasimov > >> >> Dan >> >> >> On 7/4/13 6:59 PM, Ivan Gerasimov wrote: >>> Thank you, Daniel! >>> >>> Please find an updated webrev at >>> http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. >>> It now includes the RetransformBigClass test modified in the same >>> way as RedefineBigClass >>> If the changes look fine, may I ask you to sponsor the commit, as >>> I'm not a committer? >>> Here's a link to hg export: >>> http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch >>> >>> >>> Thanks in advance, >>> Ivan >>> >>> On 04.07.2013 21:45, Daniel D. Daugherty wrote: >>>> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>>>> Daniel, thank you for review! >>>>> >>>>> Here's the updated with all all your suggestions adopted. >>>>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >>>> >>>> Looks good. >>>> >>>> >>>>> >>>>> I haven't yet considered applying the approach to >>>>> RetransformBigClass. >>>>> Do you want me to include this into this same change set or should >>>>> I make it separately? >>>> >>>> I would include it in the same changeset. >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>>>> Hello everybody! >>>>>>> >>>>>>> We have a request to improve jtreg test. >>>>>>> The test had been written to verify fix for memory leak during >>>>>>> class redefinition. >>>>>>> The problem is that it always is reported as PASSED even in the >>>>>>> presence of the leak. >>>>>>> >>>>>>> The proposed change is platform specific. >>>>>>> It allows memory leak detection only on Linux. >>>>>>> This is because the memory leak was in native code, so there's >>>>>>> no easy way to detect it from within Java code. >>>>>>> >>>>>>> Here's the webrev for JDK8 repository: >>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>>>> >>>>>> Very nicely done! The logic in RedefineBigClass.sh only catches a >>>>>> leak big enough to cause an Exception to be thrown. >>>>>> >>>>>> When I originally wrote this test and its companion: >>>>>> >>>>>> test/java/lang/instrument/RetransformBigClass* >>>>>> >>>>>> I could not come up with a platform independent way to put a small >>>>>> upper limit on memory growth. It never dawned on me that putting in >>>>>> something on one platform (Linux) was better than nothing. >>>>>> >>>>>> Are you planning to add this same logic to RetransformBigClass*? >>>>>> >>>>>> >>>>>> >>>>>> test/java/lang/instrument/RedefineBigClass.sh >>>>>> No comments. >>>>>> >>>>>> test/java/lang/instrument/RedefineBigClassApp.java >>>>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb >>>>>> Would be better at the top of RedefineBigClassApp rather >>>>>> than >>>>>> "buried" down here. >>>>>> >>>>>> line 51: Long.valueOf(vmMemDelta) >>>>>> There are several places where a long is passed to >>>>>> Long.valueOf(). >>>>>> Is there some reason you're not passing them directly to >>>>>> println()? >>>>>> >>>>>> line 54: } else { >>>>>> The "else" is redundant due to the "System.exit(1)" call >>>>>> above it. >>>>>> You can drop the "else {" and "}" and shift that last >>>>>> println() to >>>>>> the left. >>>>>> >>>>>> line 71: return Long.parseLong(line.split(" ")[22]) / 1024; >>>>>> How about at least a comment referring to the Linux proc(5) >>>>>> man page... and the fact that the 23rd field is: >>>>>> >>>>>> vsize %lu Virtual memory size in bytes. >>>>>> >>>>>> Again, very nicely done! >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> The surprising thing is that modified test detected the leak >>>>>>> with the latest JDK8! >>>>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>>>> >>>>>>> I've filled a bug http://bugs.sun.com/view_bug.do?bug_id=8019845 >>>>>>> "Memory leak during class redefenition" (not yet available.) >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan Gerasimov >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> > From erik.helin at oracle.com Fri Jul 5 07:08:05 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 5 Jul 2013 16:08:05 +0200 Subject: RFR: 8010734: NPG: The test MemoryTest.java needs to be updated to support metaspace In-Reply-To: <20130701153520.GF2213@ehelin-thinkpad> References: <20130701153520.GF2213@ehelin-thinkpad> Message-ID: <20130705140805.GC14318@ehelin-thinkpad> Hi all, still looking for a review for this testfix. Looping in hotspot-gc-dev at openjdk.java.net as well. Thanks, Erik On 2013-07-01, Erik Helin wrote: > Hi all, > > this change updates MemoryTest.java to take the newly added Metaspace > and Compressed Class Space MemoryMXBeans into account, as well as the > new Metaspace Memory Manager. > > This change also removes the following two tests from ProblemList.txt > since they are now passing again: > -java/lang/management/MemoryMXBean/MemoryTestAllGC.sh generic-all > -java/lang/management/MemoryMXBean/MemoryTest.java generic-all > > Webrev: http://cr.openjdk.java.net/~ehelin/8010734/webrev.00/ > > Thanks, > Erik From Alan.Bateman at oracle.com Fri Jul 5 07:27:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Jul 2013 15:27:36 +0100 Subject: RFR: 8010734: NPG: The test MemoryTest.java needs to be updated to support metaspace In-Reply-To: <20130705140805.GC14318@ehelin-thinkpad> References: <20130701153520.GF2213@ehelin-thinkpad> <20130705140805.GC14318@ehelin-thinkpad> Message-ID: <51D6D7D8.5080809@oracle.com> On 05/07/2013 15:08, Erik Helin wrote: > Hi all, > > still looking for a review for this testfix. Looping in > hotspot-gc-dev at openjdk.java.net as well. > It looks like okay to me and the comments make it clear the memory pools that it expects. -Alan From ebaron at redhat.com Fri Jul 5 09:03:42 2013 From: ebaron at redhat.com (Elliott Baron) Date: Fri, 05 Jul 2013 12:03:42 -0400 Subject: Attach API on Linux and Root In-Reply-To: <51AFB637.1000107@redhat.com> References: <51AFB637.1000107@redhat.com> Message-ID: <51D6EE5E.1000204@redhat.com> Hi, On 06/05/2013 06:05 PM, Elliott Baron wrote: > Hi, > > We use Hotspot's dynamic attach mechanism in our Thermostat monitoring > tool [1], however we have discovered a bit of a problem with access > control. One of our typical use-cases is to have our agent running as > root, which will monitor all JVMs on the machine. We have noticed that > our agent with root privileges cannot attach to other unprivileged > users VMs, which seems to go against the principle of the root user. > > I have attached a Hotspot patch and JDK patch targeting 7u-dev to > allow root to attach to any user's VMs. I'd appreciate it if someone > could take a look. > > Thanks, > Elliott > > [1] http://icedtea.classpath.org/thermostat/ Ping, just making sure this patch doesn't slip through the cracks. Thanks, Elliott From sean.mullan at oracle.com Fri Jul 5 14:16:21 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 05 Jul 2013 21:16:21 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130705211658.8363648850@hg.openjdk.java.net> Changeset: 028ef97797c1 Author: mullan Date: 2013-07-05 15:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/028ef97797c1 8011547: Update XML Signature implementation to Apache Santuario 1.5.4 Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/Algorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/JCEMapper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/MessageDigestAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithmSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizationException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizerSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/InvalidCanonicalizerException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/AttrCompare.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/C14nHelper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_OmitComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclOmitComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315OmitComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java + src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerPhysical.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/NameSpaceSymbTable.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/UtfHelpper.java + src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AbstractSerializer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AgreementMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherReference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherValue.java + src/share/classes/com/sun/org/apache/xml/internal/security/encryption/DocumentSerializer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedKey.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedType.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperties.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperty.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/ReferenceList.java + src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Serializer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Transforms.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherParameters.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLEncryptionException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/AlgorithmAlreadyRegisteredException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/Base64DecodingException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/XMLSecurityException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/XMLSecurityRuntimeException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/ContentHandlerAlreadyRegisteredException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyUtils.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/DEREncodedKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyInfoContent.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyInfoReference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyName.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/MgmtData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/PGPData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/RetrievalMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/SPKIData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/X509Data.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/DSAKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/KeyValueContent.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/RSAKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509CRL.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509Certificate.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509DataContent.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509Digest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509IssuerSerial.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SubjectName.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/InvalidKeyResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverSpi.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/DEREncodedKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/DSAKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/EncryptedKeyResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/KeyInfoReferenceResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/PrivateKeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RSAKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/SecretKeyResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/SingleKeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509CertificateResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509DigestResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509IssuerSerialResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509SKIResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509SubjectNameResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/KeyStoreResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/SingleCertificateResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.xml - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_en.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/InvalidDigestValueException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/InvalidSignatureValueException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/MissingResourceFailureException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/NodeFilter.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/ObjectContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/ReferenceNotInitializedException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperties.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperty.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignedInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInputDebugger.java + src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceData.java + src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceNodeSetData.java + src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceOctetStreamData.java + src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceSubTreeData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/InvalidTransformException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformParam.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformationException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transforms.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHere.java - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformBase64Decode.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N11_WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NExclusive.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NExclusiveWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformEnvelopedSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPointer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXSLT.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/InclusiveNamespaces.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPath2FilterContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPath2FilterContainer04.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPathContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPathFilterCHGPContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Constants.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/DOMNamespaceContext.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/DigesterOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementChecker.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementCheckerImpl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionConstants.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/HelperNodeList.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IgnoreAllErrorHandler.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/JDKXPathAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/JDKXPathFactory.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/Signature11ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/SignatureElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/SignerOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncBufferedOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncByteArrayOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFactory.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/XalanXPathAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/XalanXPathFactory.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverContext.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverAnonymous.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverFragment.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverLocalFilesystem.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverXPointer.java ! src/share/classes/org/jcp/xml/dsig/internal/DigesterOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/MacOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/SignerOutputStream.java + src/share/classes/org/jcp/xml/dsig/internal/dom/AbstractDOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMBase64Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14N11Method.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java Changeset: e3208dbf6926 Author: mullan Date: 2013-07-05 16:30 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3208dbf6926 Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java From lana.steuck at oracle.com Fri Jul 5 14:40:23 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Jul 2013 21:40:23 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b97 for changeset 469995a8e974 Message-ID: <20130705214025.361BE48859@hg.openjdk.java.net> Changeset: 3370fb6146e4 Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/3370fb6146e4 Added tag jdk8-b97 for changeset 469995a8e974 ! .hgtags From lana.steuck at oracle.com Fri Jul 5 14:40:29 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Jul 2013 21:40:29 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20130705214032.7F3144885B@hg.openjdk.java.net> Changeset: da63a99481da Author: cl Date: 2013-07-04 01:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/da63a99481da Added tag jdk8-b97 for changeset 1bf1d6ce3042 ! .hgtags Changeset: 542b7803f038 Author: lana Date: 2013-07-05 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/542b7803f038 Merge From lana.steuck at oracle.com Fri Jul 5 14:40:32 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Jul 2013 21:40:32 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b97 for changeset dcde7f049111 Message-ID: <20130705214036.0BA464885C@hg.openjdk.java.net> Changeset: b1fb4612a2ca Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b1fb4612a2ca Added tag jdk8-b97 for changeset dcde7f049111 ! .hgtags From lana.steuck at oracle.com Fri Jul 5 14:40:28 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Jul 2013 21:40:28 +0000 Subject: hg: jdk8/tl: 9 new changesets Message-ID: <20130705214029.033E44885A@hg.openjdk.java.net> Changeset: f5eb23490e6a Author: erikj Date: 2013-06-27 09:27 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f5eb23490e6a 8017047: Can't use --with-java-devtools and --with-devkit at the same time Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: e5cf1735638c Author: erikj Date: 2013-06-28 11:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e5cf1735638c 8016605: New files dont apear in src.zip Reviewed-by: tbell ! common/makefiles/JavaCompilation.gmk Changeset: 0871b5799149 Author: erikj Date: 2013-06-28 11:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0871b5799149 8019229: Build Configuration Fail in Windows Platform Reviewed-by: chegar, tbell, dxu ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 0e533ceee717 Author: erikj Date: 2013-06-28 12:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0e533ceee717 8016303: make CONF= isn't working Reviewed-by: tbell ! NewMakefile.gmk Changeset: 78aaf5d3314d Author: erikj Date: 2013-06-28 12:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/78aaf5d3314d 8010385: build with LOG=trace broken on mac Reviewed-by: dholmes, tbell, prr ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/MakeBase.gmk Changeset: dd3b314f4471 Author: erikj Date: 2013-07-01 15:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dd3b314f4471 8009744: build-infra: REGRESSION: Publisher was NOT set for some JDK files Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: b2b87e9e8683 Author: erikj Date: 2013-07-02 15:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b2b87e9e8683 8019537: jdk8-build prebuild fails in source bundle generation, The path of TOOLS_DIR ... is not found Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: a1c1e8bf71f3 Author: katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a1c1e8bf71f3 Merge Changeset: 99ad803f8c4e Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/99ad803f8c4e Added tag jdk8-b97 for changeset a1c1e8bf71f3 ! .hgtags From lana.steuck at oracle.com Fri Jul 5 14:40:33 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Jul 2013 21:40:33 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20130705214043.3469B4885D@hg.openjdk.java.net> Changeset: c96691d84a7c Author: katleman Date: 2013-06-28 16:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c96691d84a7c 8019347: JDK8 b96 source with GPL header errors Reviewed-by: iris, alanb, lancea ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_de.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_es.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_it.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_zh_TW.properties Changeset: 6c830db28d21 Author: katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6c830db28d21 Merge Changeset: 15e5bb51bc0c Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/15e5bb51bc0c Added tag jdk8-b97 for changeset 6c830db28d21 ! .hgtags From lana.steuck at oracle.com Fri Jul 5 14:40:32 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Jul 2013 21:40:32 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130705214045.302BB4885E@hg.openjdk.java.net> Changeset: 2364e94ae67b Author: cl Date: 2013-07-04 01:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2364e94ae67b Added tag jdk8-b97 for changeset 6a11a81a8824 ! .hgtags Changeset: ce5a90df517b Author: lana Date: 2013-07-05 11:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ce5a90df517b Merge Changeset: 49654c9c705b Author: lana Date: 2013-07-05 13:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/49654c9c705b Merge From lana.steuck at oracle.com Fri Jul 5 14:40:39 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Jul 2013 21:40:39 +0000 Subject: hg: jdk8/tl/hotspot: 26 new changesets Message-ID: <20130705214136.249194885F@hg.openjdk.java.net> Changeset: fc8a1a5de78e Author: amurillo Date: 2013-06-21 00:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fc8a1a5de78e 8017253: new hotspot build - hs25-b39 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 91acb82a8b7a Author: dholmes Date: 2013-06-19 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/91acb82a8b7a 8014326: [OSX] All libjvm symbols are exported Summary: Add support for a MacOS X compatible form of the libjvm mapfile. Reviewed-by: dcubed, rdurbin, coleenp ! make/bsd/makefiles/build_vm_def.sh ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product Changeset: b9f4c4ec0f50 Author: iklam Date: 2013-06-19 20:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9f4c4ec0f50 8008964: NPG: Memory regression: Thread::_metadata_handles uses 1 KB per thread. Summary: Reduce default size of Thread::_metadata_handles from 300 to 30 Reviewed-by: coleenp, sspitsyn ! src/share/vm/runtime/thread.cpp Changeset: b3cd8b58b798 Author: mgronlun Date: 2013-06-20 11:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b3cd8b58b798 8016735: Remove superfluous EnableInvokeDynamic warning from UnlockDiagnosticVMOptions check Reviewed-by: sla, dholmes ! src/share/vm/runtime/globals.cpp Changeset: 9ba41a4a71ff Author: coleenp Date: 2013-06-21 10:50 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ba41a4a71ff 8004124: Handle and/or warn about SI_KERNEL Summary: Detect this crash in the signal handler and give a fatal error message instead of making us chase down bugs that don't reproduce Reviewed-by: kvn, mgerdin, dholmes ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: bed34a7a3b9b Author: coleenp Date: 2013-06-21 10:57 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bed34a7a3b9b 8017177: more explicit code location information in hs_err crash log Summary: Add code pc location for compiled code Reviewed-by: kvn, coleenp Contributed-by: doug.simon at oracle.com ! src/share/vm/runtime/frame.cpp Changeset: bb6c7f2f10fd Author: dcubed Date: 2013-06-21 08:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bb6c7f2f10fd Merge Changeset: b7bc7c94b4b5 Author: dcubed Date: 2013-06-21 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b7bc7c94b4b5 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp Changeset: d9eed26d638a Author: iklam Date: 2013-06-23 22:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d9eed26d638a 8009575: Reduce Symbol::_refcount from 4 bytes to 2 bytes Summary: Added Atomic::inc(short*) to support this change. Reviewed-by: coleenp, dcubed, dholmes, minqi ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: e0c9a1d29eb4 Author: coleenp Date: 2013-06-24 18:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0c9a1d29eb4 8016325: JVM hangs verifying system dictionary Summary: Minimize redundant verifications of Klasses. Reviewed-by: hseigel, jmasa ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constantPool.cpp ! 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/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/shark/sharkBuilder.cpp Changeset: 01e10b366055 Author: sla Date: 2013-06-25 14:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/01e10b366055 8017561: Build errors caused by missing .PHONY Reviewed-by: stefank, brutisso ! make/excludeSrc.make Changeset: feae15578b2f Author: tamao Date: 2013-06-07 09:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/feae15578b2f 7122222: GC log is limited to 2G for 32-bit Summary: Enable large file support for generated 32-bit ostream.o on Linux and Solaris (as only the two need this) by setting -D_FILE_OFFSET_BITS=64 in compilation Reviewed-by: tbell, mgerdin, dcubed Contributed-by: tamao ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! src/os/solaris/vm/os_solaris.inline.hpp Changeset: df7e1c0e3dc1 Author: jmasa Date: 2013-06-25 09:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df7e1c0e3dc1 8014546: MetaspaceAux print_metaspace_change() should print "used" after GC not capacity Reviewed-by: johnc, tschatzl ! src/share/vm/memory/metaspace.cpp Changeset: f99cd6e20ab1 Author: jmasa Date: 2013-06-25 15:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f99cd6e20ab1 8014851: UseAdaptiveGCBoundary is broken Reviewed-by: tschatzl, brutisso ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp + test/gc/parallelScavenge/AdaptiveGCBoundary.java Changeset: 71963b3f802a Author: ehelin Date: 2013-06-26 16:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/71963b3f802a 8013590: NPG: Add a memory pool MXBean for Metaspace Reviewed-by: jmasa, mgerdin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp + test/gc/metaspace/TestMetaspaceMemoryPool.java Changeset: f8972b867ded Author: ehelin Date: 2013-06-27 10:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f8972b867ded Merge Changeset: 7875ea94bea5 Author: goetz Date: 2013-06-24 11:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7875ea94bea5 8017308: Remove unused breakpoint relocation type Summary: remove unused breakpoint relocation type Reviewed-by: kvn ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp Changeset: cc63bcb47cce Author: twisti Date: 2013-06-24 17:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc63bcb47cce 8017538: Clang support broke slowdebug build for i586 Reviewed-by: kvn ! make/linux/makefiles/gcc.make Changeset: a023da4ffc15 Author: twisti Date: 2013-06-24 18:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a023da4ffc15 Merge Changeset: 3aa636f2a743 Author: adlertz Date: 2013-06-25 12:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3aa636f2a743 8017243: 8001345 is incomplete Summary: Replaces unused decodeN at MemBarAcquire with its corresponding loadN if loadN is used at more than one place. Reviewed-by: kvn, twisti ! src/share/vm/opto/memnode.cpp Changeset: 9347cae673f0 Author: adlertz Date: 2013-06-26 00:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9347cae673f0 8017510: Add a regression test for 8005956 Summary: Regression test for 8005956 Reviewed-by: kvn, twisti + test/compiler/8005956/PolynomialRoot.java Changeset: 6a0ead6dc6db Author: goetz Date: 2013-06-24 16:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6a0ead6dc6db 8017531: 8010460 changes broke bytecodeInterpreter.cpp Summary: Replace _indy by _jsr292 and also fix VERIFY_OOP macros. Reviewed-by: kvn ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: be0600ec1102 Author: kvn Date: 2013-06-27 11:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be0600ec1102 Merge Changeset: 2b9380b0bf0b Author: amurillo Date: 2013-06-28 02:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b9380b0bf0b Merge ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp Changeset: d197d377ab2e Author: amurillo Date: 2013-06-28 02:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d197d377ab2e Added tag hs25-b39 for changeset 2b9380b0bf0b ! .hgtags Changeset: 2bfa00fac03f Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2bfa00fac03f Added tag jdk8-b97 for changeset d197d377ab2e ! .hgtags From lana.steuck at oracle.com Fri Jul 5 14:44:30 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Jul 2013 21:44:30 +0000 Subject: hg: jdk8/tl/jdk: 20 new changesets Message-ID: <20130705214839.9E12248860@hg.openjdk.java.net> Changeset: 8339c83b16c6 Author: ehelin Date: 2013-07-02 13:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8339c83b16c6 8019500: Exclude MemoryTest.java and MemoryTestAllGC.sh to enable integration Reviewed-by: erikj, alanb ! test/ProblemList.txt Changeset: 87cab043cb5e Author: katleman Date: 2013-06-28 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/87cab043cb5e 8019347: JDK8 b96 source with GPL header errors Reviewed-by: iris, alanb, lancea ! makefiles/sun/awt/ToBin.java ! src/share/classes/javax/xml/crypto/dsig/dom/DOMValidateContext.java ! test/java/awt/Mouse/EnterExitEvents/FullscreenEnterEventTest.java ! test/java/lang/ThreadGroup/Suspend.java Changeset: 978a95239044 Author: katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/978a95239044 Merge Changeset: 4b21dcfdcc3b Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b21dcfdcc3b Added tag jdk8-b97 for changeset 978a95239044 ! .hgtags Changeset: 5cfcd545ce4a Author: vadim Date: 2013-06-26 13:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5cfcd545ce4a 8016254: several sun/java2d/OpenGL tests failed with SIGFPE Reviewed-by: prr, bae ! src/share/native/sun/java2d/opengl/OGLContext.c Changeset: 3ffa38871143 Author: lana Date: 2013-06-28 19:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ffa38871143 Merge - make/sun/xawt/ToBin.java - makefiles/sun/awt/X11/ToBin.java - src/share/classes/sun/misc/FDBigInt.java - src/share/classes/sun/misc/Hashing.java - src/solaris/classes/sun/awt/X11/XIconInfo.java - src/solaris/classes/sun/awt/X11/security-icon-bw16.png - src/solaris/classes/sun/awt/X11/security-icon-bw24.png - src/solaris/classes/sun/awt/X11/security-icon-bw32.png - src/solaris/classes/sun/awt/X11/security-icon-bw48.png - src/solaris/classes/sun/awt/X11/security-icon-interim16.png - src/solaris/classes/sun/awt/X11/security-icon-interim24.png - src/solaris/classes/sun/awt/X11/security-icon-interim32.png - src/solaris/classes/sun/awt/X11/security-icon-interim48.png - src/solaris/classes/sun/awt/X11/security-icon-yellow16.png - src/solaris/classes/sun/awt/X11/security-icon-yellow24.png - src/solaris/classes/sun/awt/X11/security-icon-yellow32.png - src/solaris/classes/sun/awt/X11/security-icon-yellow48.png - test/java/lang/invoke/7196190/MHProxyTest.java - test/sun/misc/Hashing.java Changeset: 6dda4a069a83 Author: prr Date: 2013-07-01 12:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6dda4a069a83 8015144: Performance regression in ICU OpenType Layout library Reviewed-by: srl, jgodinez ! make/sun/font/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/LETableReference.h ! src/share/native/sun/font/layout/OpenTypeUtilities.cpp Changeset: 6d2b5ec2ec79 Author: prr Date: 2013-07-02 14:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d2b5ec2ec79 8019692: JDK build CC_OPT_HIGHEST setting isn't valid for Sun C++ compiler Reviewed-by: jgodinez ! make/sun/font/Makefile ! makefiles/CompileNativeLibraries.gmk Changeset: 1c607ebfc180 Author: leonidr Date: 2013-06-20 18:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c607ebfc180 8014264: The applet pathguy_TimeDead throws java.lang.NullPointerException in java console once click drop-down check box. Reviewed-by: art, anthony, serb ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XListPeer.java Changeset: b7b95b7ab2cb Author: malenkov Date: 2013-06-21 17:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7b95b7ab2cb 8016545: java.beans.XMLEncoder.writeObject output is wrong Reviewed-by: alexsch ! src/share/classes/java/beans/XMLEncoder.java + test/java/beans/XMLEncoder/Test8016545.java Changeset: eed321190272 Author: alitvinov Date: 2013-06-21 21:30 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eed321190272 8007642: Media Names on Java Print Do Not Match the Printer???s and Confuse Users Reviewed-by: prr, jgodinez ! src/windows/classes/sun/print/Win32PrintService.java Changeset: e5bac76282f7 Author: pchelko Date: 2013-06-27 13:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e5bac76282f7 8019236: [macosx] Add javadoc to the handleWindowFocusEvent in CEmbeddedFrame Reviewed-by: serb, ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: 72f167edf630 Author: dmarkov Date: 2013-06-28 18:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72f167edf630 8016534: javax/swing/text/View/8014863/bug8014863.java failed Reviewed-by: alexp, alexsch ! test/javax/swing/text/View/8014863/bug8014863.java Changeset: 228ec4b9111a Author: lana Date: 2013-06-28 18:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/228ec4b9111a Merge - make/sun/xawt/ToBin.java - makefiles/sun/awt/X11/ToBin.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java - src/share/classes/sun/misc/FDBigInt.java - src/share/classes/sun/misc/Hashing.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java - src/solaris/classes/sun/awt/X11/XIconInfo.java ! src/solaris/classes/sun/awt/X11/XListPeer.java - src/solaris/classes/sun/awt/X11/security-icon-bw16.png - src/solaris/classes/sun/awt/X11/security-icon-bw24.png - src/solaris/classes/sun/awt/X11/security-icon-bw32.png - src/solaris/classes/sun/awt/X11/security-icon-bw48.png - src/solaris/classes/sun/awt/X11/security-icon-interim16.png - src/solaris/classes/sun/awt/X11/security-icon-interim24.png - src/solaris/classes/sun/awt/X11/security-icon-interim32.png - src/solaris/classes/sun/awt/X11/security-icon-interim48.png - src/solaris/classes/sun/awt/X11/security-icon-yellow16.png - src/solaris/classes/sun/awt/X11/security-icon-yellow24.png - src/solaris/classes/sun/awt/X11/security-icon-yellow32.png - src/solaris/classes/sun/awt/X11/security-icon-yellow48.png ! src/windows/classes/sun/print/Win32PrintService.java - test/java/lang/invoke/7196190/MHProxyTest.java - test/sun/misc/Hashing.java Changeset: 6fc558b41d8e Author: lana Date: 2013-07-02 15:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6fc558b41d8e Merge Changeset: 11c074904fce Author: lana Date: 2013-07-02 15:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11c074904fce Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: 974b94f944ce Author: lana Date: 2013-07-03 19:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/974b94f944ce Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: f2342dedf04a Author: lana Date: 2013-07-05 11:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2342dedf04a Merge Changeset: 49c5547d9e8e Author: lana Date: 2013-07-05 13:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49c5547d9e8e Merge Changeset: 4fcabe8e22ce Author: lana Date: 2013-07-05 14:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fcabe8e22ce Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java From frederic.parain at oracle.com Fri Jul 5 15:32:01 2013 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Fri, 05 Jul 2013 22:32:01 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 24 new changesets Message-ID: <20130705223249.8E78F48862@hg.openjdk.java.net> Changeset: c92b74c62d97 Author: brutisso Date: 2013-06-27 09:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c92b74c62d97 8017483: G1 tests fail with native OOME on Solaris x86 after HeapBaseMinAddress has been increased Summary: Set HeapBaseMinAddress as default rather than ergo Reviewed-by: stefank, jmasa, kvn ! src/share/vm/runtime/arguments.cpp Changeset: 3ea89789ba39 Author: ehelin Date: 2013-06-28 18:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3ea89789ba39 Merge Changeset: b30744960351 Author: brutisso Date: 2013-06-30 21:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b30744960351 8014022: G1: Non Java threads should lock the shared SATB queue lock without safepoint checks. Reviewed-by: tschatzl, brutisso, jmasa, ysr Contributed-by: per.liden at oracle.com ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp Changeset: 5ea20b3bd249 Author: johnc Date: 2013-07-01 09:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5ea20b3bd249 8017070: G1: assert(_card_counts[card_num] <= G1ConcRSHotCardLimit) failed Summary: The assert is invalid when a card is being refined by two different threads and its count crosses the hot threshold - the refinement count will be updated once by each thread triggering the assert. Remove the assert and update the count using a bounded expression. Reviewed-by: jmasa, tamao, brutisso ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp Changeset: 6e3634222155 Author: tamao Date: 2013-06-28 20:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6e3634222155 8017611: Auto corrector for mistyped vm options Summary: The auto corrector for mistyped vm options fuzzy-matches existing flags based on string similarity (Dice's coefficient). Reviewed-by: kvn, dsamersoff, hseigel, johnc ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp + test/gc/arguments/TestUnrecognizedVMOptionsHandling.java Changeset: 536976a22f5f Author: tamao Date: 2013-07-03 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/536976a22f5f Merge Changeset: 70bea4a43c6d Author: tamao Date: 2013-07-03 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/70bea4a43c6d Merge Changeset: ac7193063af8 Author: jiangli Date: 2013-07-01 19:44 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ac7193063af8 8006023: Embedded Builds fail management test because of requirement for UsePerfData being enabled. Summary: Added -XX:+UsePerfData to Test7196045.java. Reviewed-by: dholmes, collins ! test/runtime/7196045/Test7196045.java Changeset: 94aa8de029c5 Author: clucasius Date: 2013-07-03 22:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/94aa8de029c5 Merge Changeset: fea6a49c2762 Author: bdelsart Date: 2013-07-04 01:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fea6a49c2762 Merge Changeset: f765bfec8f07 Author: kvn Date: 2013-07-01 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f765bfec8f07 8006629: NEED_TEST: need test for JDK-8001071 Summary: added regression test Reviewed-by: kvn, coleenp Contributed-by: Filipp Zhinkin + test/runtime/8001071/Test8001071.java + test/runtime/8001071/Test8001071.sh Changeset: a023ec3452c7 Author: simonis Date: 2013-07-01 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a023ec3452c7 8019382: PPC64: Fix bytecodeInterpreter to compile with '-Wunused-value' Summary: cast the offending expressions to (void) Reviewed-by: kvn, coleenp ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 2b3fe74309b6 Author: kvn Date: 2013-07-02 10:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2b3fe74309b6 8019247: SIGSEGV in compiled method c8e.e.t_.getArray(Ljava/lang/Class;)[Ljava/lang/Object Summary: Undo recent changes (and add more comments) in Ideal_allocation(). Reviewed-by: roland ! src/share/vm/opto/graphKit.cpp Changeset: 738e04fb1232 Author: anoll Date: 2013-07-02 07:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/738e04fb1232 8014972: Crash with specific values for -XX:InitialCodeCacheSize=500K -XX:ReservedCodeCacheSize=500k Summary: Introduce a minimum code cache size that guarantees that the VM can startup. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: b800986664f4 Author: drchase Date: 2013-07-02 20:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b800986664f4 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 Summary: add intrinsics using new instruction to interpreter, C1, C2, for suitable x86; add test Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp + src/cpu/x86/vm/stubRoutines_x86.cpp + src/cpu/x86/vm/stubRoutines_x86.hpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp + test/compiler/7088419/CRCTest.java Changeset: c1bd7b5bdc70 Author: twisti Date: 2013-07-02 20:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c1bd7b5bdc70 8017571: JSR292: JVM crashing on assert "cast to instanceKlass" while producing MethodHandle for array methods with MethodHandle.findVirtual Reviewed-by: kvn ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/reflection.cpp Changeset: bed0eddd82cd Author: twisti Date: 2013-07-02 22:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bed0eddd82cd Merge Changeset: 8b789ce47503 Author: roland Date: 2013-07-04 01:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8b789ce47503 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: fece0ee013fc Author: roland Date: 2013-07-04 03:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fece0ee013fc Merge Changeset: 2bfa00fac03f Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2bfa00fac03f Added tag jdk8-b97 for changeset d197d377ab2e ! .hgtags Changeset: c9dd82da51ed Author: amurillo Date: 2013-07-04 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c9dd82da51ed Merge Changeset: 30b5b75c42ac Author: amurillo Date: 2013-07-04 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/30b5b75c42ac Added tag hs25-b40 for changeset c9dd82da51ed ! .hgtags Changeset: ea4d24c1e0c6 Author: amurillo Date: 2013-07-04 14:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ea4d24c1e0c6 8019934: new hotspot build - hs25-b41 Reviewed-by: jcoomes ! make/hotspot_version Changeset: cc5b7915104e Author: fparain Date: 2013-07-05 08:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cc5b7915104e Merge From bradford.wetmore at oracle.com Fri Jul 5 18:24:01 2013 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Sat, 06 Jul 2013 01:24:01 +0000 Subject: hg: jdk8/tl/jdk: 8019341: Update CookieHttpsClientTest to use the newer framework. Message-ID: <20130706012427.9957D4886A@hg.openjdk.java.net> Changeset: 11c15607e43f Author: wetmore Date: 2013-07-05 18:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11c15607e43f 8019341: Update CookieHttpsClientTest to use the newer framework. Reviewed-by: xuelei, smarks, michaelm ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java ! test/sun/security/ssl/templates/SSLEngineTemplate.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java ! test/sun/security/ssl/templates/SSLSocketTemplate.java From erik.helin at oracle.com Sat Jul 6 00:14:15 2013 From: erik.helin at oracle.com (Erik Helin) Date: Sat, 6 Jul 2013 09:14:15 +0200 Subject: RFR: 8010734: NPG: The test MemoryTest.java needs to be updated to support metaspace In-Reply-To: <51D6D7D8.5080809@oracle.com> References: <20130701153520.GF2213@ehelin-thinkpad> <20130705140805.GC14318@ehelin-thinkpad> <51D6D7D8.5080809@oracle.com> Message-ID: <20130706071415.GC2056@ehelin-thinkpad> Thanks! Erik On 2013-07-05, Alan Bateman wrote: > On 05/07/2013 15:08, Erik Helin wrote: > >Hi all, > > > >still looking for a review for this testfix. Looping in > >hotspot-gc-dev at openjdk.java.net as well. > > > It looks like okay to me and the comments make it clear the memory > pools that it expects. > > -Alan From staffan.larsen at oracle.com Sun Jul 7 11:14:47 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Sun, 7 Jul 2013 20:14:47 +0200 Subject: Attach API on Linux and Root In-Reply-To: <51D6EE5E.1000204@redhat.com> References: <51AFB637.1000107@redhat.com> <51D6EE5E.1000204@redhat.com> Message-ID: <338BF620-F6A5-44F4-A7E9-DCC81A4B86A6@oracle.com> Thanks for the patch, I think it sounds like a good idea. For consistency, however, we need to do the same modifications to the other platforms (solaris, windows) and preferably add tests for this functionality as well. /Staffan On 5 jul 2013, at 18:03, Elliott Baron wrote: > Hi, > > On 06/05/2013 06:05 PM, Elliott Baron wrote: >> Hi, >> >> We use Hotspot's dynamic attach mechanism in our Thermostat monitoring tool [1], however we have discovered a bit of a problem with access control. One of our typical use-cases is to have our agent running as root, which will monitor all JVMs on the machine. We have noticed that our agent with root privileges cannot attach to other unprivileged users VMs, which seems to go against the principle of the root user. >> >> I have attached a Hotspot patch and JDK patch targeting 7u-dev to allow root to attach to any user's VMs. I'd appreciate it if someone could take a look. >> >> Thanks, >> Elliott >> >> [1] http://icedtea.classpath.org/thermostat/ > > Ping, just making sure this patch doesn't slip through the cracks. > > Thanks, > Elliott From jesper.wilhelmsson at oracle.com Mon Jul 8 03:56:47 2013 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Mon, 08 Jul 2013 10:56:47 +0000 Subject: hg: jdk8/tl/jdk: 8010734: NPG: The test MemoryTest.java needs to be updated to support metaspace Message-ID: <20130708105700.286CF48890@hg.openjdk.java.net> Changeset: 715d00c95fb2 Author: ehelin Date: 2013-07-08 11:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/715d00c95fb2 8010734: NPG: The test MemoryTest.java needs to be updated to support metaspace Reviewed-by: alanb ! test/ProblemList.txt ! test/java/lang/management/MemoryMXBean/MemoryTest.java From sundararajan.athijegannathan at oracle.com Mon Jul 8 06:31:03 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 08 Jul 2013 13:31:03 +0000 Subject: hg: jdk8/tl/nashorn: 20 new changesets Message-ID: <20130708133120.3DFB54889B@hg.openjdk.java.net> Changeset: 313bdcd2fd22 Author: sundar Date: 2013-07-03 00:08 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/313bdcd2fd22 8019629: void operator should always evaluate to undefined Reviewed-by: jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8019629.js Changeset: 9d3a9fdab668 Author: sundar Date: 2013-07-03 13:13 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9d3a9fdab668 8019783: typeof does not work properly for java methods and foreign objects Reviewed-by: hannesw ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8019783.js + test/script/basic/JDK-8019783.js.EXPECTED ! test/script/basic/NASHORN-759.js.EXPECTED Changeset: 4afdc5bec43b Author: sundar Date: 2013-07-03 14:08 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4afdc5bec43b 8019791: ~ is a unary operator Reviewed-by: hannesw ! src/jdk/nashorn/internal/parser/TokenType.java + test/script/basic/JDK-8019791.js + test/script/basic/JDK-8019791.js.EXPECTED Changeset: 18d467e94150 Author: attila Date: 2013-07-03 12:39 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/18d467e94150 8010946: AccessControl.doPrivileged is broken when called from js script Reviewed-by: jlaskey, sundar ! make/build.xml ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java + src/jdk/internal/dynalink/beans/CallerSensitiveDetector.java + src/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk/internal/dynalink/beans/ClassString.java ! src/jdk/internal/dynalink/beans/DynamicMethod.java ! src/jdk/internal/dynalink/beans/DynamicMethodLinker.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java ! src/jdk/internal/dynalink/beans/MaximallySpecific.java ! src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk/internal/dynalink/beans/OverloadedMethod.java ! src/jdk/internal/dynalink/beans/SimpleDynamicMethod.java + src/jdk/internal/dynalink/beans/SingleDynamicMethod.java ! src/jdk/internal/dynalink/beans/StaticClassIntrospector.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java + test/script/basic/JDK-8010946-2.js + test/script/basic/JDK-8010946-2.js.EXPECTED + test/script/basic/JDK-8010946-privileged.js + test/script/basic/JDK-8010946.js + test/script/basic/JDK-8010946.js.EXPECTED Changeset: b1980b5f00a1 Author: lagergren Date: 2013-07-03 13:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b1980b5f00a1 8019585: Sometimes a var declaration using itself in its init wasn't declared as canBeUndefined, causing erroneous bytecode Reviewed-by: sundar, attila ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java + test/script/basic/JDK-8019585.js Changeset: eb1437d16ab4 Author: sundar Date: 2013-07-03 17:26 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/eb1437d16ab4 8019805: for each (init; test; modify) is invalid Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8019805.js + test/script/basic/JDK-8019805.js.EXPECTED ! test/script/basic/forin.js ! test/script/basic/forin.js.EXPECTED Changeset: 961cffae0828 Author: lagergren Date: 2013-07-03 15:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/961cffae0828 8019811: Static calls - self referential functions needed a return type conversion if they were specialized, as they can't use the same mechanism as indy calls Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! test/script/basic/JDK-8016667.js + test/script/basic/JDK-8019808.js + test/script/basic/JDK-8019810.js + test/script/basic/JDK-8019810.js.EXPECTED + test/script/basic/JDK-8019811.js + test/script/basic/JDK-8019817.js + test/script/currently-failing/JDK-8019809.js Changeset: fcb484c43348 Author: sundar Date: 2013-07-03 19:20 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fcb484c43348 8019814: Add regression test for passing cases Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ListAdapter.java + test/script/basic/JDK-8019814.js + test/script/basic/JDK-8019814.js.EXPECTED Changeset: 29b2b2ed954c Author: attila Date: 2013-07-03 18:10 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/29b2b2ed954c 8017768: allow dot as inner class name separator for Java.type Reviewed-by: jlaskey, sundar ! docs/JavaScriptingProgrammersGuide.html ! src/jdk/nashorn/internal/objects/NativeJava.java + test/script/basic/JDK-8017768.js + test/script/basic/JDK-8017768.js.EXPECTED ! test/src/jdk/nashorn/test/models/OuterClass.java Changeset: 7b072ebdf5aa Author: jlaskey Date: 2013-07-03 13:41 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7b072ebdf5aa 8011629: Object.defineProperty performance issue Reviewed-by: sundar, attila Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/AccessorProperty.java Changeset: ad6b18ee4666 Author: attila Date: 2013-07-04 14:10 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ad6b18ee4666 8019809: return after break incorrectly sets the block as terminal Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/BlockLexicalContext.java + test/script/basic/JDK-8019809.js - test/script/currently-failing/JDK-8019809.js Changeset: be2087629eb9 Author: lagergren Date: 2013-07-04 17:27 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/be2087629eb9 8019821: allInteger switches were confused by boolean cases, as they are a narrower type than int Reviewed-by: sundar, hannesw ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8019821.js Changeset: 8c4a6d9b8a23 Author: lagergren Date: 2013-07-04 17:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8c4a6d9b8a23 Merge - test/script/currently-failing/JDK-8019809.js Changeset: ec84ba68ad39 Author: sundar Date: 2013-07-05 14:38 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ec84ba68ad39 8019947: inherited property invalidation does not work with two globals in same context Reviewed-by: jlaskey, lagergren, hannesw, attila ! make/build-nasgen.xml ! make/build.xml ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/scripts/JO.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/JDK-8019947.js + test/script/basic/JDK-8019947.js.EXPECTED Changeset: edca88d3a03e Author: hannesw Date: 2013-07-05 14:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/edca88d3a03e 8017084: Use spill properties for large object literals Reviewed-by: lagergren, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java + src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/scripts/JO.java + test/script/basic/JDK-8017084.js + test/script/basic/JDK-8017084.js.EXPECTED Changeset: ce9cbe70f915 Author: attila Date: 2013-07-05 15:10 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ce9cbe70f915 8019819: scope symbol didn't get a slot in certain cases Reviewed-by: hannesw, jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8019819.js Changeset: 20b2c2dc20e8 Author: lagergren Date: 2013-07-05 19:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/20b2c2dc20e8 8019983: Void returns combined with return with expression picked the wrong return type Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8019983.js + test/script/basic/JDK-8019983.js.EXPECTED Changeset: 36d6b6a3fbe0 Author: sundar Date: 2013-07-08 16:33 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/36d6b6a3fbe0 8020015: shared PropertyMaps should not be used without duplication Reviewed-by: hannesw, attila ! buildtools/nasgen/build.xml ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! make/code_coverage.xml ! make/project.properties ! src/jdk/nashorn/internal/lookup/Lookup.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/internal/scripts/JO.java ! src/jdk/nashorn/tools/Shell.java Changeset: a75e75cc6a61 Author: sundar Date: 2013-07-08 18:36 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a75e75cc6a61 8020035: nashorn jdk buildfile BuildNashorn.gmk still renamed jdk.nashorn.internal.objects package Reviewed-by: attila, jlaskey ! makefiles/BuildNashorn.gmk Changeset: c96745616167 Author: sundar Date: 2013-07-08 18:43 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c96745616167 Merge From peter.allwin at oracle.com Mon Jul 8 06:54:58 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Mon, 8 Jul 2013 15:54:58 +0200 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Message-ID: <004101ce7be2$bd046410$370d2c30$@oracle.com> Hello! Looking for reviews of this change: http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ For CR: http://bugs.sun.com/view_bug.do?bug_id=7162400 https://jbs.oracle.com/bugs/browse/JDK-7162400 Summary: This change addresses an issue in the Attach API on Solaris, Linux and BSD where an attaching application can receive IOExceptions such as "Bad file number" (Solaris), "Connection refused" (Linux/BSD), or "well-known file is not secure". The attach process uses a file in the temporary directory as a door (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In certain circumstances stale files can be left in the file system which can cause the attaching application to believe that the VM is ready to receive a connection when it's not. With this change the stale file will be removed during VM startup. Note that there is still an issue if we don't have permission to remove the stale file, the attaching process will fail to connect. Testing: JPRT, reproducing script on Solaris, Linux. Credits: Thanks to Staffan Larsen who worked on this issue with me. Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130708/0815efbd/attachment.html From rickard.backman at oracle.com Mon Jul 8 08:33:08 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Mon, 8 Jul 2013 17:33:08 +0200 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> Message-ID: <49B7BBBD-497D-47D0-814F-6239AF7A2751@oracle.com> Trying again, can I please get reviews on this change? Thanks /R On Jul 4, 2013, at 11:30 AM, Rickard B?ckman wrote: > Hi, > > can I please have a couple of reviews for this change? > > The problem in this crash was that we were given an incorrect fp (in this case 0x0) and had a pc that matched the C -> Java entry frame. The code then dereferenced fp +- offset. > > This change verifies that the fp +- offset is actually on the stack of the thread before doing the derefencing. > > Webrev: http://cr.openjdk.java.net/~rbackman/8016131/ > > Thanks > /R From markus.gronlund at oracle.com Mon Jul 8 08:45:06 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Mon, 8 Jul 2013 08:45:06 -0700 (PDT) Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> Message-ID: Rickard, I think it looks good (not a Reviewer). Cheers Markus -----Original Message----- From: Rickard B?ckman Sent: den 4 juli 2013 11:30 To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' Hi, can I please have a couple of reviews for this change? The problem in this crash was that we were given an incorrect fp (in this case 0x0) and had a pc that matched the C -> Java entry frame. The code then dereferenced fp +- offset. This change verifies that the fp +- offset is actually on the stack of the thread before doing the derefencing. Webrev: http://cr.openjdk.java.net/~rbackman/8016131/ Thanks /R From rickard.backman at oracle.com Mon Jul 8 08:49:44 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Mon, 8 Jul 2013 17:49:44 +0200 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> Message-ID: <0D743CDF-C8AB-421C-8D20-C29F08104642@oracle.com> Thanks Markus! /R On Jul 8, 2013, at 5:45 PM, Markus Gr?nlund wrote: > Rickard, > > I think it looks good (not a Reviewer). > > Cheers > Markus > > -----Original Message----- > From: Rickard B?ckman > Sent: den 4 juli 2013 11:30 > To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' > > Hi, > > can I please have a couple of reviews for this change? > > The problem in this crash was that we were given an incorrect fp (in this case 0x0) and had a pc that matched the C -> Java entry frame. The code then dereferenced fp +- offset. > > This change verifies that the fp +- offset is actually on the stack of the thread before doing the derefencing. > > Webrev: http://cr.openjdk.java.net/~rbackman/8016131/ > > Thanks > /R From ivan.gerasimov at oracle.com Mon Jul 8 09:55:47 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 08 Jul 2013 20:55:47 +0400 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51D6B1ED.9090709@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> <51D64D15.2090105@oracle.com> <51D6A59A.1060703@oracle.com> <51D6B1ED.9090709@oracle.com> Message-ID: <51DAEF13.8010000@oracle.com> Thanks, Se?n! I located the build in which the memleak was first introduced -- it is jdk8-b69 (hs25-b13). I've updated the bug http://bugs.sun.com/view_bug.do?bug_id=8019845 with this. So what is the correct procedure to go forward now? Should I update the webrev to include changes to the problem list? I believe I shouldn't -- this list seems to be a sensitive stuff. Sincerely yours, Ivan On 05.07.2013 15:45, Se?n Coffey wrote: > Nice work indeed Ivan. Good to have a reliable testcase to catch leaks > in this area. > > I'd also suggest that this test goes on the ProblemList until the new > leak is sorted out for jdk8. The goal of JPRT runs is to have clean > runs. If it's on the problemList, then it's a known issue and is > normally tagged with the relevant bug ID so that the responsible > engineer knows the current state. > > regards, > Sean. > > On 05/07/2013 11:53, Ivan Gerasimov wrote: >> >> On 05.07.2013 8:35, Daniel D. Daugherty wrote: >>> Ivan, >>> >>> The changes look fine, I can sponsor your commit, looks like your >>> OpenJDK user name is 'igerasim', but I need to know a little bit >>> more about your testing of these fixes. Did you do a test JPRT >>> job to run the JLI tests (or just the two tests themselves)? >>> >> I've only run test from java/lang/instrument when checked the change >> with JDK6u60 (all passed) and with JDK6u51 (the test failed as >> expected, since the leak had still been there.) >> >>> Based on e-mail about this bug fix, I believe you've found a new >>> leak in JDK8/HSX-25 with test java/lang/instrument/RedefineBigClass.sh. >> Right. The test shown a memleak with the the latest jdk8. >> I filed a bug 8019845 about this leak. >> Stefan Karlsson guessed that this may be related to 8003419 (NPG: >> Clean up metadata created during class loading if failure) >> Then I've checked the builds b57 (test failed) and b58 (test passed), >> so I confirmed that it may be the reason of the leak being observed now. >> But now I think that the reason may be different. >> It just turns out that the test shows failures for (at least) three >> different leaks - the one you, Daniel, solved (7121600), the one >> Stefan wrote about (8003419) and the one currently observed (8019845). >> >>> That's a good thing, but I think Alan and company would be a bit >>> grumpy with me if I pushed a test that failed as soon as someone >>> ran it. :-) Do you know if the revised RetransformBigClass.sh also >>> finds a new memory leak in JDK8/HSX-25? >>> >>> The way to deal with that is to put the test on the Problem.list >>> as part of the same changeset. However, the T&L folks might not like >>> that either... >> >> Well, the leak is there, and why not have a failing test as a >> reminder to have it fixed? >> >> Sincerely yours, >> Ivan Gerasimov >> >>> >>> Dan >>> >>> >>> On 7/4/13 6:59 PM, Ivan Gerasimov wrote: >>>> Thank you, Daniel! >>>> >>>> Please find an updated webrev at >>>> http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. >>>> It now includes the RetransformBigClass test modified in the same >>>> way as RedefineBigClass >>>> If the changes look fine, may I ask you to sponsor the commit, as >>>> I'm not a committer? >>>> Here's a link to hg export: >>>> http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch >>>> >>>> >>>> Thanks in advance, >>>> Ivan >>>> >>>> On 04.07.2013 21:45, Daniel D. Daugherty wrote: >>>>> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>>>>> Daniel, thank you for review! >>>>>> >>>>>> Here's the updated with all all your suggestions adopted. >>>>>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >>>>> >>>>> Looks good. >>>>> >>>>> >>>>>> >>>>>> I haven't yet considered applying the approach to >>>>>> RetransformBigClass. >>>>>> Do you want me to include this into this same change set or >>>>>> should I make it separately? >>>>> >>>>> I would include it in the same changeset. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> >>>>>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>>>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>>>>> Hello everybody! >>>>>>>> >>>>>>>> We have a request to improve jtreg test. >>>>>>>> The test had been written to verify fix for memory leak during >>>>>>>> class redefinition. >>>>>>>> The problem is that it always is reported as PASSED even in the >>>>>>>> presence of the leak. >>>>>>>> >>>>>>>> The proposed change is platform specific. >>>>>>>> It allows memory leak detection only on Linux. >>>>>>>> This is because the memory leak was in native code, so there's >>>>>>>> no easy way to detect it from within Java code. >>>>>>>> >>>>>>>> Here's the webrev for JDK8 repository: >>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>>>>> >>>>>>> Very nicely done! The logic in RedefineBigClass.sh only catches a >>>>>>> leak big enough to cause an Exception to be thrown. >>>>>>> >>>>>>> When I originally wrote this test and its companion: >>>>>>> >>>>>>> test/java/lang/instrument/RetransformBigClass* >>>>>>> >>>>>>> I could not come up with a platform independent way to put a small >>>>>>> upper limit on memory growth. It never dawned on me that putting in >>>>>>> something on one platform (Linux) was better than nothing. >>>>>>> >>>>>>> Are you planning to add this same logic to RetransformBigClass*? >>>>>>> >>>>>>> >>>>>>> >>>>>>> test/java/lang/instrument/RedefineBigClass.sh >>>>>>> No comments. >>>>>>> >>>>>>> test/java/lang/instrument/RedefineBigClassApp.java >>>>>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb >>>>>>> Would be better at the top of RedefineBigClassApp rather >>>>>>> than >>>>>>> "buried" down here. >>>>>>> >>>>>>> line 51: Long.valueOf(vmMemDelta) >>>>>>> There are several places where a long is passed to >>>>>>> Long.valueOf(). >>>>>>> Is there some reason you're not passing them directly to >>>>>>> println()? >>>>>>> >>>>>>> line 54: } else { >>>>>>> The "else" is redundant due to the "System.exit(1)" call >>>>>>> above it. >>>>>>> You can drop the "else {" and "}" and shift that last >>>>>>> println() to >>>>>>> the left. >>>>>>> >>>>>>> line 71: return Long.parseLong(line.split(" ")[22]) / 1024; >>>>>>> How about at least a comment referring to the Linux proc(5) >>>>>>> man page... and the fact that the 23rd field is: >>>>>>> >>>>>>> vsize %lu Virtual memory size in bytes. >>>>>>> >>>>>>> Again, very nicely done! >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> The surprising thing is that modified test detected the leak >>>>>>>> with the latest JDK8! >>>>>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>>>>> >>>>>>>> I've filled a bug >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019845 "Memory leak >>>>>>>> during class redefenition" (not yet available.) >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan Gerasimov >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >> > > > From bill.pittore at oracle.com Mon Jul 8 09:56:06 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Mon, 08 Jul 2013 12:56:06 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51D5A5CD.2070805@oracle.com> References: <51D494E9.2020200@oracle.com> <51D5A5CD.2070805@oracle.com> Message-ID: <51DAEF26.5030204@oracle.com> On 7/4/2013 12:41 PM, Alan Bateman wrote: > On 03/07/2013 22:17, BILL PITTORE wrote: >> These changes address bug 8014135 which adds support for statically >> linked agents in the VM. This is a followup to the recent JNI spec >> changes that addressed statically linked JNI libraries( 8005716). >> The JEP for this change is the same JEP as the JNI changes: >> http://openjdk.java.net/jeps/178 >> >> Webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ > > I looked at the javadoc updates to the attach API. > > One thing that doesn't come across very clearly is the mapping from > the agentLibrary parameter to "agent-lib-name". I think that needs a > few words so that it's clear that it is not literally looking for > "Agent_OnAttach_agent-lib-name" but rather "Agent_OnAttach" + > where is the library name in the > agentLibrary parameter. > > As I recall, the JVM Tool Interface is supposed to be referred so as > "JVM TI" rather than "JVMTI". Ok, I'll try to re-word it and send it out again. bill > > Otherwise it looks okay to me. > > -Alan > > > > From sean.coffey at oracle.com Mon Jul 8 10:27:56 2013 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 08 Jul 2013 18:27:56 +0100 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51DAEF13.8010000@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> <51D64D15.2090105@oracle.com> <51D6A59A.1060703@oracle.com> <51D6B1ED.9090709@oracle.com> <51DAEF13.8010000@oracle.com> Message-ID: <51DAF69C.3000404@oracle.com> On 08/07/13 17:55, Ivan Gerasimov wrote: > Thanks, Se?n! > > I located the build in which the memleak was first introduced -- it is > jdk8-b69 (hs25-b13). > I've updated the bug http://bugs.sun.com/view_bug.do?bug_id=8019845 > with this. > > So what is the correct procedure to go forward now? > Should I update the webrev to include changes to the problem list? > I believe I shouldn't -- this list seems to be a sensitive stuff. I'd suggest updating the webrev with the ProblemList modification/addition. It's best not to add a test to testruns if it's knowingly failing. The test can be removed from ProblemList when the jdk8 regression is fixed. regards, Sean. > > Sincerely yours, > Ivan > > > On 05.07.2013 15:45, Se?n Coffey wrote: >> Nice work indeed Ivan. Good to have a reliable testcase to catch >> leaks in this area. >> >> I'd also suggest that this test goes on the ProblemList until the new >> leak is sorted out for jdk8. The goal of JPRT runs is to have clean >> runs. If it's on the problemList, then it's a known issue and is >> normally tagged with the relevant bug ID so that the responsible >> engineer knows the current state. >> >> regards, >> Sean. >> >> On 05/07/2013 11:53, Ivan Gerasimov wrote: >>> >>> On 05.07.2013 8:35, Daniel D. Daugherty wrote: >>>> Ivan, >>>> >>>> The changes look fine, I can sponsor your commit, looks like your >>>> OpenJDK user name is 'igerasim', but I need to know a little bit >>>> more about your testing of these fixes. Did you do a test JPRT >>>> job to run the JLI tests (or just the two tests themselves)? >>>> >>> I've only run test from java/lang/instrument when checked the change >>> with JDK6u60 (all passed) and with JDK6u51 (the test failed as >>> expected, since the leak had still been there.) >>> >>>> Based on e-mail about this bug fix, I believe you've found a new >>>> leak in JDK8/HSX-25 with test >>>> java/lang/instrument/RedefineBigClass.sh. >>> Right. The test shown a memleak with the the latest jdk8. >>> I filed a bug 8019845 about this leak. >>> Stefan Karlsson guessed that this may be related to 8003419 (NPG: >>> Clean up metadata created during class loading if failure) >>> Then I've checked the builds b57 (test failed) and b58 (test >>> passed), so I confirmed that it may be the reason of the leak being >>> observed now. >>> But now I think that the reason may be different. >>> It just turns out that the test shows failures for (at least) three >>> different leaks - the one you, Daniel, solved (7121600), the one >>> Stefan wrote about (8003419) and the one currently observed (8019845). >>> >>>> That's a good thing, but I think Alan and company would be a bit >>>> grumpy with me if I pushed a test that failed as soon as someone >>>> ran it. :-) Do you know if the revised RetransformBigClass.sh also >>>> finds a new memory leak in JDK8/HSX-25? >>>> >>>> The way to deal with that is to put the test on the Problem.list >>>> as part of the same changeset. However, the T&L folks might not like >>>> that either... >>> >>> Well, the leak is there, and why not have a failing test as a >>> reminder to have it fixed? >>> >>> Sincerely yours, >>> Ivan Gerasimov >>> >>>> >>>> Dan >>>> >>>> >>>> On 7/4/13 6:59 PM, Ivan Gerasimov wrote: >>>>> Thank you, Daniel! >>>>> >>>>> Please find an updated webrev at >>>>> http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. >>>>> It now includes the RetransformBigClass test modified in the same >>>>> way as RedefineBigClass >>>>> If the changes look fine, may I ask you to sponsor the commit, as >>>>> I'm not a committer? >>>>> Here's a link to hg export: >>>>> http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch >>>>> >>>>> >>>>> Thanks in advance, >>>>> Ivan >>>>> >>>>> On 04.07.2013 21:45, Daniel D. Daugherty wrote: >>>>>> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>>>>>> Daniel, thank you for review! >>>>>>> >>>>>>> Here's the updated with all all your suggestions adopted. >>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >>>>>> >>>>>> Looks good. >>>>>> >>>>>> >>>>>>> >>>>>>> I haven't yet considered applying the approach to >>>>>>> RetransformBigClass. >>>>>>> Do you want me to include this into this same change set or >>>>>>> should I make it separately? >>>>>> >>>>>> I would include it in the same changeset. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>>>>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>>>>>> Hello everybody! >>>>>>>>> >>>>>>>>> We have a request to improve jtreg test. >>>>>>>>> The test had been written to verify fix for memory leak during >>>>>>>>> class redefinition. >>>>>>>>> The problem is that it always is reported as PASSED even in >>>>>>>>> the presence of the leak. >>>>>>>>> >>>>>>>>> The proposed change is platform specific. >>>>>>>>> It allows memory leak detection only on Linux. >>>>>>>>> This is because the memory leak was in native code, so there's >>>>>>>>> no easy way to detect it from within Java code. >>>>>>>>> >>>>>>>>> Here's the webrev for JDK8 repository: >>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>>>>>> >>>>>>>> Very nicely done! The logic in RedefineBigClass.sh only catches a >>>>>>>> leak big enough to cause an Exception to be thrown. >>>>>>>> >>>>>>>> When I originally wrote this test and its companion: >>>>>>>> >>>>>>>> test/java/lang/instrument/RetransformBigClass* >>>>>>>> >>>>>>>> I could not come up with a platform independent way to put a small >>>>>>>> upper limit on memory growth. It never dawned on me that >>>>>>>> putting in >>>>>>>> something on one platform (Linux) was better than nothing. >>>>>>>> >>>>>>>> Are you planning to add this same logic to RetransformBigClass*? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> test/java/lang/instrument/RedefineBigClass.sh >>>>>>>> No comments. >>>>>>>> >>>>>>>> test/java/lang/instrument/RedefineBigClassApp.java >>>>>>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb >>>>>>>> Would be better at the top of RedefineBigClassApp >>>>>>>> rather than >>>>>>>> "buried" down here. >>>>>>>> >>>>>>>> line 51: Long.valueOf(vmMemDelta) >>>>>>>> There are several places where a long is passed to >>>>>>>> Long.valueOf(). >>>>>>>> Is there some reason you're not passing them directly >>>>>>>> to println()? >>>>>>>> >>>>>>>> line 54: } else { >>>>>>>> The "else" is redundant due to the "System.exit(1)" >>>>>>>> call above it. >>>>>>>> You can drop the "else {" and "}" and shift that last >>>>>>>> println() to >>>>>>>> the left. >>>>>>>> >>>>>>>> line 71: return Long.parseLong(line.split(" ")[22]) / 1024; >>>>>>>> How about at least a comment referring to the Linux >>>>>>>> proc(5) >>>>>>>> man page... and the fact that the 23rd field is: >>>>>>>> >>>>>>>> vsize %lu Virtual memory size in bytes. >>>>>>>> >>>>>>>> Again, very nicely done! >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> The surprising thing is that modified test detected the leak >>>>>>>>> with the latest JDK8! >>>>>>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>>>>>> >>>>>>>>> I've filled a bug >>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019845 "Memory leak >>>>>>>>> during class redefenition" (not yet available.) >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan Gerasimov >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> >> > From serguei.spitsyn at oracle.com Mon Jul 8 11:36:41 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 08 Jul 2013 11:36:41 -0700 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <004101ce7be2$bd046410$370d2c30$@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> Message-ID: <51DB06B9.10509@oracle.com> Hi Peter, The fix looks good. Thanks, Serguei On 7/8/13 6:54 AM, Peter Allwin wrote: > > Hello! > > Looking for reviews of this change: > > http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ > > > For CR: > > http://bugs.sun.com/view_bug.do?bug_id=7162400 > > https://jbs.oracle.com/bugs/browse/JDK-7162400 > > Summary: > > This change addresses an issue in the Attach API on Solaris, Linux and > BSD where an attaching application can receive IOExceptions such as > "Bad file number" (Solaris), "Connection refused" (Linux/BSD), or > "well-known file is not secure". > > The attach process uses a file in the temporary directory as a door > (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In > certain circumstances stale files can be left in the file system which > can cause the attaching application to believe that the VM is ready to > receive a connection when it's not. With this change the stale file > will be removed during VM startup. > > Note that there is still an issue if we don't have permission to > remove the stale file, the attaching process will fail to connect. > > Testing: > > JPRT, reproducing script on Solaris, Linux. > > Credits: > > Thanks to Staffan Larsen who worked on this issue with me. > > Regards, > > Peter > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130708/1e2f46ef/attachment.html From serguei.spitsyn at oracle.com Mon Jul 8 11:59:09 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 08 Jul 2013 11:59:09 -0700 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DB06B9.10509@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> Message-ID: <51DB0BFD.6040508@oracle.com> Peter, I've added the label "noreg-hard" with the comment to the report. It is not easy to reproduce the issue and demonstrate the fix in a regression test. Thanks, Serguei On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com wrote: > Hi Peter, > > The fix looks good. > > Thanks, > Serguei > > On 7/8/13 6:54 AM, Peter Allwin wrote: >> >> Hello! >> >> Looking for reviews of this change: >> >> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ >> >> >> For CR: >> >> http://bugs.sun.com/view_bug.do?bug_id=7162400 >> >> https://jbs.oracle.com/bugs/browse/JDK-7162400 >> >> Summary: >> >> This change addresses an issue in the Attach API on Solaris, Linux >> and BSD where an attaching application can receive IOExceptions such >> as "Bad file number" (Solaris), "Connection refused" (Linux/BSD), or >> "well-known file is not secure". >> >> The attach process uses a file in the temporary directory as a door >> (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In >> certain circumstances stale files can be left in the file system >> which can cause the attaching application to believe that the VM is >> ready to receive a connection when it's not. With this change the >> stale file will be removed during VM startup. >> >> Note that there is still an issue if we don't have permission to >> remove the stale file, the attaching process will fail to connect. >> >> Testing: >> >> JPRT, reproducing script on Solaris, Linux. >> >> Credits: >> >> Thanks to Staffan Larsen who worked on this issue with me. >> >> Regards, >> >> Peter >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130708/9e000b5a/attachment.html From ioi.lam at oracle.com Mon Jul 8 14:35:16 2013 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Mon, 08 Jul 2013 21:35:16 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8016903: Thread::_handle_area initial size too big Message-ID: <20130708213520.3F8EB488B9@hg.openjdk.java.net> Changeset: cf9d71d3e474 Author: iklam Date: 2013-07-08 10:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cf9d71d3e474 8016903: Thread::_handle_area initial size too big Summary: Changed initial size to Chunk::tiny_size (216 bytes) Reviewed-by: coleenp, dholmes, sspitsyn ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/handles.hpp From daniel.daugherty at oracle.com Mon Jul 8 15:27:44 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 08 Jul 2013 16:27:44 -0600 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <004101ce7be2$bd046410$370d2c30$@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> Message-ID: <51DB3CE0.9070804@oracle.com> On 7/8/13 7:54 AM, Peter Allwin wrote: > > Hello! > > Looking for reviews of this change: > > http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ > > src/share/vm/services/attachListener.hpp No comments. src/os/bsd/vm/attachListener_bsd.cpp line 443: // an attaching process to think we are ready to recieve on the typo: 'recieve' -> 'receive' src/os/linux/vm/attachListener_linux.cpp line 438: // an attaching process to think we are ready to recieve on the typo: 'recieve' -> 'receive' src/os/solaris/vm/attachListener_solaris.cpp line 582: // an attaching process to think we are ready to recieve a door_call typo: 'recieve' -> 'receive' src/os/windows/vm/attachListener_windows.cpp No comments. src/share/vm/runtime/thread.cpp No comments. Thumbs up. Dan > For CR: > > http://bugs.sun.com/view_bug.do?bug_id=7162400 > > https://jbs.oracle.com/bugs/browse/JDK-7162400 > > Summary: > > This change addresses an issue in the Attach API on Solaris, Linux and > BSD where an attaching application can receive IOExceptions such as > "Bad file number" (Solaris), "Connection refused" (Linux/BSD), or > "well-known file is not secure". > > The attach process uses a file in the temporary directory as a door > (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In > certain circumstances stale files can be left in the file system which > can cause the attaching application to believe that the VM is ready to > receive a connection when it's not. With this change the stale file > will be removed during VM startup. > > Note that there is still an issue if we don't have permission to > remove the stale file, the attaching process will fail to connect. > > Testing: > > JPRT, reproducing script on Solaris, Linux. > > Credits: > > Thanks to Staffan Larsen who worked on this issue with me. > > Regards, > > Peter > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130708/9068b54a/attachment.html From daniel.daugherty at oracle.com Mon Jul 8 15:46:17 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 08 Jul 2013 16:46:17 -0600 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DB0BFD.6040508@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> Message-ID: <51DB4139.6010106@oracle.com> Serguei, There are a number of existing tests associated with this bug. I don't think that 'noreg-hard' is the right label. I think 'noreg-sqe' is the right one: noreg-sqe Change can be verified by running an existing SQE test suite; the bug should identify the suite and the specific test case(s). Dan On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com wrote: > Peter, > > I've added the label "noreg-hard" with the comment to the report. > It is not easy to reproduce the issue and demonstrate the fix in a > regression test. > > Thanks, > Serguei > > > On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com wrote: >> Hi Peter, >> >> The fix looks good. >> >> Thanks, >> Serguei >> >> On 7/8/13 6:54 AM, Peter Allwin wrote: >>> >>> Hello! >>> >>> Looking for reviews of this change: >>> >>> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ >>> >>> >>> For CR: >>> >>> http://bugs.sun.com/view_bug.do?bug_id=7162400 >>> >>> https://jbs.oracle.com/bugs/browse/JDK-7162400 >>> >>> Summary: >>> >>> This change addresses an issue in the Attach API on Solaris, Linux >>> and BSD where an attaching application can receive IOExceptions such >>> as "Bad file number" (Solaris), "Connection refused" (Linux/BSD), or >>> "well-known file is not secure". >>> >>> The attach process uses a file in the temporary directory as a door >>> (Solaris) or domain socket (Linux,BSD) to communicate with the VM. >>> In certain circumstances stale files can be left in the file system >>> which can cause the attaching application to believe that the VM is >>> ready to receive a connection when it's not. With this change the >>> stale file will be removed during VM startup. >>> >>> Note that there is still an issue if we don't have permission to >>> remove the stale file, the attaching process will fail to connect. >>> >>> Testing: >>> >>> JPRT, reproducing script on Solaris, Linux. >>> >>> Credits: >>> >>> Thanks to Staffan Larsen who worked on this issue with me. >>> >>> Regards, >>> >>> Peter >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130708/a2c42948/attachment.html From serguei.spitsyn at oracle.com Mon Jul 8 16:07:25 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 08 Jul 2013 16:07:25 -0700 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DB4139.6010106@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> Message-ID: <51DB462D.5010300@oracle.com> Dan, Dan, thank you for the recommendation. But I'm still not sure it is a right thing to do. Even though, there are multiple test cases associated with this bug they can not be used to verify that fix because an additional condition must be present as well. This condition is a presence of stale door file which is not that easy to reproduce. However, if you insist then I can change the lable to the "noreg-sqe" with the corresponding comment. Thanks, Serguei On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: > Serguei, > > There are a number of existing tests associated with this bug. I don't > think that 'noreg-hard' is the right label. I think 'noreg-sqe' is > the right one: > > noreg-sqe > Change can be verified by running an existing SQE test suite; the bug > should identify the suite and the specific test case(s). > > Dan > > > On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com wrote: >> Peter, >> >> I've added the label "noreg-hard" with the comment to the report. >> It is not easy to reproduce the issue and demonstrate the fix in a >> regression test. >> >> Thanks, >> Serguei >> >> >> On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Peter, >>> >>> The fix looks good. >>> >>> Thanks, >>> Serguei >>> >>> On 7/8/13 6:54 AM, Peter Allwin wrote: >>>> >>>> Hello! >>>> >>>> Looking for reviews of this change: >>>> >>>> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ >>>> >>>> >>>> For CR: >>>> >>>> http://bugs.sun.com/view_bug.do?bug_id=7162400 >>>> >>>> https://jbs.oracle.com/bugs/browse/JDK-7162400 >>>> >>>> Summary: >>>> >>>> This change addresses an issue in the Attach API on Solaris, Linux >>>> and BSD where an attaching application can receive IOExceptions >>>> such as "Bad file number" (Solaris), "Connection refused" >>>> (Linux/BSD), or "well-known file is not secure". >>>> >>>> The attach process uses a file in the temporary directory as a door >>>> (Solaris) or domain socket (Linux,BSD) to communicate with the VM. >>>> In certain circumstances stale files can be left in the file system >>>> which can cause the attaching application to believe that the VM is >>>> ready to receive a connection when it's not. With this change the >>>> stale file will be removed during VM startup. >>>> >>>> Note that there is still an issue if we don't have permission to >>>> remove the stale file, the attaching process will fail to connect. >>>> >>>> Testing: >>>> >>>> JPRT, reproducing script on Solaris, Linux. >>>> >>>> Credits: >>>> >>>> Thanks to Staffan Larsen who worked on this issue with me. >>>> >>>> Regards, >>>> >>>> Peter >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130708/98c27a72/attachment-0001.html From daniel.daugherty at oracle.com Mon Jul 8 16:20:48 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 08 Jul 2013 17:20:48 -0600 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DB462D.5010300@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> Message-ID: <51DB4950.7080504@oracle.com> I definitely don't insist... :-) BTW, I noticed this in Peter's e-mail: > Testing: > JPRT, reproducing script on Solaris, Linux. so maybe Peter already has this covered with "reproducing script"... Dan On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com wrote: > Dan, > > Dan, thank you for the recommendation. > But I'm still not sure it is a right thing to do. > Even though, there are multiple test cases associated with this bug they > can not be used to verify that fix because an additional condition > must be present as well. > This condition is a presence of stale door file which is not that easy > to reproduce. > > However, if you insist then I can change the lable to the "noreg-sqe" > with the corresponding comment. > > Thanks, > Serguei > > > On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: >> Serguei, >> >> There are a number of existing tests associated with this bug. I don't >> think that 'noreg-hard' is the right label. I think 'noreg-sqe' is >> the right one: >> >> noreg-sqe >> Change can be verified by running an existing SQE test suite; the bug >> should identify the suite and the specific test case(s). >> >> Dan >> >> >> On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com wrote: >>> Peter, >>> >>> I've added the label "noreg-hard" with the comment to the report. >>> It is not easy to reproduce the issue and demonstrate the fix in a >>> regression test. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi Peter, >>>> >>>> The fix looks good. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 7/8/13 6:54 AM, Peter Allwin wrote: >>>>> >>>>> Hello! >>>>> >>>>> Looking for reviews of this change: >>>>> >>>>> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ >>>>> >>>>> >>>>> For CR: >>>>> >>>>> http://bugs.sun.com/view_bug.do?bug_id=7162400 >>>>> >>>>> https://jbs.oracle.com/bugs/browse/JDK-7162400 >>>>> >>>>> Summary: >>>>> >>>>> This change addresses an issue in the Attach API on Solaris, Linux >>>>> and BSD where an attaching application can receive IOExceptions >>>>> such as "Bad file number" (Solaris), "Connection refused" >>>>> (Linux/BSD), or "well-known file is not secure". >>>>> >>>>> The attach process uses a file in the temporary directory as a >>>>> door (Solaris) or domain socket (Linux,BSD) to communicate with >>>>> the VM. In certain circumstances stale files can be left in the >>>>> file system which can cause the attaching application to believe >>>>> that the VM is ready to receive a connection when it's not. With >>>>> this change the stale file will be removed during VM startup. >>>>> >>>>> Note that there is still an issue if we don't have permission to >>>>> remove the stale file, the attaching process will fail to connect. >>>>> >>>>> Testing: >>>>> >>>>> JPRT, reproducing script on Solaris, Linux. >>>>> >>>>> Credits: >>>>> >>>>> Thanks to Staffan Larsen who worked on this issue with me. >>>>> >>>>> Regards, >>>>> >>>>> Peter >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130708/51a12b67/attachment.html From serguei.spitsyn at oracle.com Mon Jul 8 16:26:02 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 08 Jul 2013 16:26:02 -0700 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DB4950.7080504@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> <51DB4950.7080504@oracle.com> Message-ID: <51DB4A8A.7010205@oracle.com> Ok, thanks! Peter, did you manage to reproduce this issue with your script? If so, then, please, include it into the bug report and remove the "noreg-sqe" label. It is Ok if you did not reproduce it, though. Thanks, Serguei On 7/8/13 4:20 PM, Daniel D. Daugherty wrote: > I definitely don't insist... :-) > > BTW, I noticed this in Peter's e-mail: > > > Testing: > > JPRT, reproducing script on Solaris, Linux. > > so maybe Peter already has this covered with "reproducing script"... > > Dan > > > On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com wrote: >> Dan, >> >> Dan, thank you for the recommendation. >> But I'm still not sure it is a right thing to do. >> Even though, there are multiple test cases associated with this bug they >> can not be used to verify that fix because an additional condition >> must be present as well. >> This condition is a presence of stale door file which is not that >> easy to reproduce. >> >> However, if you insist then I can change the lable to the "noreg-sqe" >> with the corresponding comment. >> >> Thanks, >> Serguei >> >> >> On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: >>> Serguei, >>> >>> There are a number of existing tests associated with this bug. I don't >>> think that 'noreg-hard' is the right label. I think 'noreg-sqe' is >>> the right one: >>> >>> noreg-sqe >>> Change can be verified by running an existing SQE test suite; >>> the bug >>> should identify the suite and the specific test case(s). >>> >>> Dan >>> >>> >>> On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com wrote: >>>> Peter, >>>> >>>> I've added the label "noreg-hard" with the comment to the report. >>>> It is not easy to reproduce the issue and demonstrate the fix in a >>>> regression test. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Peter, >>>>> >>>>> The fix looks good. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 7/8/13 6:54 AM, Peter Allwin wrote: >>>>>> >>>>>> Hello! >>>>>> >>>>>> Looking for reviews of this change: >>>>>> >>>>>> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ >>>>>> >>>>>> >>>>>> For CR: >>>>>> >>>>>> http://bugs.sun.com/view_bug.do?bug_id=7162400 >>>>>> >>>>>> https://jbs.oracle.com/bugs/browse/JDK-7162400 >>>>>> >>>>>> Summary: >>>>>> >>>>>> This change addresses an issue in the Attach API on Solaris, >>>>>> Linux and BSD where an attaching application can receive >>>>>> IOExceptions such as "Bad file number" (Solaris), "Connection >>>>>> refused" (Linux/BSD), or "well-known file is not secure". >>>>>> >>>>>> The attach process uses a file in the temporary directory as a >>>>>> door (Solaris) or domain socket (Linux,BSD) to communicate with >>>>>> the VM. In certain circumstances stale files can be left in the >>>>>> file system which can cause the attaching application to believe >>>>>> that the VM is ready to receive a connection when it's not. With >>>>>> this change the stale file will be removed during VM startup. >>>>>> >>>>>> Note that there is still an issue if we don't have permission to >>>>>> remove the stale file, the attaching process will fail to connect. >>>>>> >>>>>> Testing: >>>>>> >>>>>> JPRT, reproducing script on Solaris, Linux. >>>>>> >>>>>> Credits: >>>>>> >>>>>> Thanks to Staffan Larsen who worked on this issue with me. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Peter >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130708/1088092e/attachment-0001.html From jiangli.zhou at oracle.com Mon Jul 8 18:11:14 2013 From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com) Date: Tue, 09 Jul 2013 01:11:14 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20130709011121.C3A0A488CD@hg.openjdk.java.net> Changeset: 71180a6e5080 Author: jiangli Date: 2013-07-03 17:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/71180a6e5080 7133260: AllocationProfiler uses space in metadata and doesn't seem to do anything useful. Summary: Remove -Xaprof and Klass::_alloc_count & ArrayKlass::_alloc_size. Reviewed-by: stefank, coleenp ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.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/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fa6929d0b0a9 Author: jiangli Date: 2013-07-08 14:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fa6929d0b0a9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3c7b4b7b2625 Author: jiangli Date: 2013-07-08 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3c7b4b7b2625 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp From jason.uh at oracle.com Mon Jul 8 19:25:11 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Tue, 09 Jul 2013 02:25:11 +0000 Subject: hg: jdk8/tl/jdk: 8020091: Fix HTML doclint issues in java.io Message-ID: <20130709022534.4BB75488D3@hg.openjdk.java.net> Changeset: 52454985425d Author: juh Date: 2013-07-08 19:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/52454985425d 8020091: Fix HTML doclint issues in java.io Reviewed-by: darcy ! src/share/classes/java/io/DataInput.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/InputStreamReader.java ! src/share/classes/java/io/OutputStreamWriter.java ! src/share/classes/java/io/PipedInputStream.java ! src/share/classes/java/io/RandomAccessFile.java From harold.seigel at oracle.com Mon Jul 8 21:45:58 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 09 Jul 2013 04:45:58 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20130709044606.AB7A3488DB@hg.openjdk.java.net> Changeset: ba9dacff9c9d Author: hseigel Date: 2013-07-08 19:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d 8014399: Remove JVM_SetProtectionDomain from hotspot Summary: JVM_SetProtectionDomain has been deprecated since 1.5 and is being removed Reviewed-by: coleenp, hseigel 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/javaClasses.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 26037663c2a6 Author: hseigel Date: 2013-07-08 16:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/26037663c2a6 Merge Changeset: e79a9f26ba2e Author: hseigel Date: 2013-07-08 18:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e79a9f26ba2e Merge From joe.darcy at oracle.com Mon Jul 8 22:43:47 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 09 Jul 2013 05:43:47 +0000 Subject: hg: jdk8/tl/jdk: 8020095: Fix doclint warnings in java.util.regex Message-ID: <20130709054443.B2F2A488DC@hg.openjdk.java.net> Changeset: eab8f4e29f5e Author: darcy Date: 2013-07-08 22:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eab8f4e29f5e 8020095: Fix doclint warnings in java.util.regex Reviewed-by: mchung ! src/share/classes/java/util/regex/MatchResult.java ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java From paul.sandoz at oracle.com Tue Jul 9 00:22:39 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 09 Jul 2013 07:22:39 +0000 Subject: hg: jdk8/tl/jdk: 8017141: java.util/stream Spliterators from sequential sources should not catch OOME Message-ID: <20130709072304.6DB76488DF@hg.openjdk.java.net> Changeset: 628432ee4d68 Author: henryjen Date: 2013-07-09 09:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/628432ee4d68 8017141: java.util/stream Spliterators from sequential sources should not catch OOME Reviewed-by: mchung Contributed-by: paul.sandoz at oracle.com ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/Spliterators.java From paul.sandoz at oracle.com Tue Jul 9 01:45:21 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 09 Jul 2013 08:45:21 +0000 Subject: hg: jdk8/tl/jdk: 8019551: Make BaseStream public Message-ID: <20130709084547.A32E2488E5@hg.openjdk.java.net> Changeset: 44a634c1edc4 Author: psandoz Date: 2013-07-09 10:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44a634c1edc4 8019551: Make BaseStream public Reviewed-by: chegar, psandoz Contributed-by: brian goetz ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/BaseStream.java From kevin.walls at oracle.com Tue Jul 9 01:57:18 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 09 Jul 2013 09:57:18 +0100 Subject: RFR: 8015576: CMS: svc agent throws java.lang.RuntimeException: No type named "FreeList" in database In-Reply-To: <51D58BCC.4030803@oracle.com> References: <51D58BCC.4030803@oracle.com> Message-ID: <51DBD06E.3030005@oracle.com> Thanks Vladimir - Looks good to me. The only question would have been if there's any benefit in getting both releases in sync and taking the full backport and creating AFLBinaryTreeDictionary in hs24. There's time pressure on this at the minute as a tool (jmap) lies broken, so the simple fix you have seems appropriate (in hs24, vmStructs_cms.hpp still references BinaryTreeDictionary not AFLBinaryTreeDictionary). There is some more history in email: http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-January/008109.html I added serviceability-dev on the cc too, we should encourage a further Review there. Would be great to get this reviewed today and push ahead. Thanks Kevin On 04/07/13 15:50, Vladimir Kempik wrote: > Hi all, > > this change fixes an issue where we could not run jmap -heap on a > java process running with -XX:+UseConcMarkSweepGC. > > Partially (1 line) it's a backport of > http://bugs.sun.com/view_bug.do?bug_id=8005278 from jdk8 > > The problem originated from the following change in hotspot: > changeset 3294:9f059abe8cf2 > parent 3284:3c91f2c9fd21 > 7131629: Generalize the CMS free list code > > --- > a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Fri Apr 20 17:13:36 2012 -0700 > +++ > b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Thu Mar 29 19:46:24 2012 -0700 > @@ -44,11 +44,11 @@ > nonstatic_field(FreeChunk, _next, FreeChunk*) \ > nonstatic_field(FreeChunk, _prev, FreeChunk*) \ > nonstatic_field(LinearAllocBlock, _word_size, size_t) \ > - nonstatic_field(FreeList, _size, size_t) \ > - nonstatic_field(FreeList, _count, ssize_t) \ > - nonstatic_field(BinaryTreeDictionary, _totalSize, size_t) \ > - nonstatic_field(CompactibleFreeListSpace, _dictionary, > FreeBlockDictionary*) \ > - nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], > FreeList) \ > + nonstatic_field(FreeList, _size, size_t) \ > + nonstatic_field(FreeList, _count, ssize_t) \ > + nonstatic_field(BinaryTreeDictionary,_totalSize, size_t) \ > + nonstatic_field(CompactibleFreeListSpace, _dictionary, > FreeBlockDictionary*) \ > + nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], > FreeList) \ > nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, > LinearAllocBlock) > @@ -70,13 +70,13 @@ > declare_toplevel_type(CompactibleFreeListSpace*) \ > declare_toplevel_type(CMSCollector*) \ > declare_toplevel_type(FreeChunk*) \ > - declare_toplevel_type(BinaryTreeDictionary*) \ > - declare_toplevel_type(FreeBlockDictionary*) \ > - declare_toplevel_type(FreeList*) \ > - declare_toplevel_type(FreeList) \ > + declare_toplevel_type(BinaryTreeDictionary*) \ > + declare_toplevel_type(FreeBlockDictionary*) \ > + declare_toplevel_type(FreeList*) \ > + declare_toplevel_type(FreeList) \ > declare_toplevel_type(LinearAllocBlock) \ > - declare_toplevel_type(FreeBlockDictionary) \ > - declare_type(BinaryTreeDictionary, FreeBlockDictionary) > + declare_toplevel_type(FreeBlockDictionary) \ > + declare_type(BinaryTreeDictionary, > FreeBlockDictionary) > #define VM_INT_CONSTANTS_CMS(declare_constant) \ > declare_constant(Generation::ConcurrentMarkSweep) \ > > > This fix updates the SA code to be like the hotspot code. > > Webrev: http://cr.openjdk.java.net/~mcherkas/vladimir/8015576/webrev.00/ > > Testing: > - JPRT > - Running jmap -heap successfully on a java process using > -XX:+UseConcMarkSweepGC > > Thanks, > Vladimir From jaroslav.bachorik at oracle.com Tue Jul 9 03:02:48 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 09 Jul 2013 12:02:48 +0200 Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management Interfaces being public In-Reply-To: <51C0440B.9030601@oracle.com> References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com> <51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com> <51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com> <51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com> <51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com> <51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com> <51AF9A56.4090709@oracle.com> <51B0A937.90607@oracle.com> <51B0AAB7.7070802@oracle.com> <51B0B39C.1050305@oracle.com> <51B18803.7060406@oracle.com> <51B1A2E2.5030001@oracle.com> <51C03013.2020700@oracle.com> <51C0359F.8090201@oracle.com> <51C036AF.1030206@oracle.com> <51C0440B.9030601@oracle.com> Message-ID: <51DBDFC8.4090800@oracle.com> Please, review the final version of the changes: http://cr.openjdk.java.net/~jbachorik/8010285/webrev.07 It addresses all the concerns raised during the CCC process. I will need at least one official OpenJDK reviewer for the integration. Thanks, -JB- From david.holmes at oracle.com Tue Jul 9 04:47:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Jul 2013 21:47:29 +1000 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <004101ce7be2$bd046410$370d2c30$@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> Message-ID: <51DBF851.9090401@oracle.com> Hi Peter, Why did you change from using PATH_MAX+1 to UNIX_PATH_MAX in is_init_trigger? AFAICS the .attach_pid file is not linked to a socket and so not limited to UNIX_PATH_MAX. David On 8/07/2013 11:54 PM, Peter Allwin wrote: > Hello! > > Looking for reviews of this change: > > http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ > > For CR: > > http://bugs.sun.com/view_bug.do?bug_id=7162400 > > https://jbs.oracle.com/bugs/browse/JDK-7162400 > > Summary: > > This change addresses an issue in the Attach API on Solaris, Linux and > BSD where an attaching application can receive IOExceptions such as ?Bad > file number? (Solaris), ?Connection refused? (Linux/BSD), or ?well-known > file is not secure?. > > The attach process uses a file in the temporary directory as a door > (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In > certain circumstances stale files can be left in the file system which > can cause the attaching application to believe that the VM is ready to > receive a connection when it?s not. With this change the stale file will > be removed during VM startup. > > Note that there is still an issue if we don?t have permission to remove > the stale file, the attaching process will fail to connect. > > Testing: > > JPRT, reproducing script on Solaris, Linux. > > Credits: > > Thanks to Staffan Larsen who worked on this issue with me. > > Regards, > > Peter > From david.holmes at oracle.com Tue Jul 9 04:51:41 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Jul 2013 21:51:41 +1000 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <004101ce7be2$bd046410$370d2c30$@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> Message-ID: <51DBF94D.7080201@oracle.com> PS. Why not put the vm_start logic directly into the init method? David On 8/07/2013 11:54 PM, Peter Allwin wrote: > Hello! > > Looking for reviews of this change: > > http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ > > For CR: > > http://bugs.sun.com/view_bug.do?bug_id=7162400 > > https://jbs.oracle.com/bugs/browse/JDK-7162400 > > Summary: > > This change addresses an issue in the Attach API on Solaris, Linux and > BSD where an attaching application can receive IOExceptions such as ?Bad > file number? (Solaris), ?Connection refused? (Linux/BSD), or ?well-known > file is not secure?. > > The attach process uses a file in the temporary directory as a door > (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In > certain circumstances stale files can be left in the file system which > can cause the attaching application to believe that the VM is ready to > receive a connection when it?s not. With this change the stale file will > be removed during VM startup. > > Note that there is still an issue if we don?t have permission to remove > the stale file, the attaching process will fail to connect. > > Testing: > > JPRT, reproducing script on Solaris, Linux. > > Credits: > > Thanks to Staffan Larsen who worked on this issue with me. > > Regards, > > Peter > From peter.allwin at oracle.com Tue Jul 9 05:25:38 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Tue, 9 Jul 2013 14:25:38 +0200 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DB4A8A.7010205@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> <51DB4950.7080504@oracle.com> <51DB4A8A.7010205@oracle.com> Message-ID: <013d01ce7c9f$6d1f86b0$475e9410$@oracle.com> Hello! It is reproducible by letting the test create .java_pid* files for all possible process id's on the system, setting correct access flags, launching the target VM and attempting to connect. There are some caveats though but it should be doable. I'll convert the repro script to JTREG and add it to the webrev. Thanks for the reviews! /peter From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Tuesday, July 9, 2013 1:26 AM To: daniel.daugherty at oracle.com Cc: Peter Allwin; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Ok, thanks! Peter, did you manage to reproduce this issue with your script? If so, then, please, include it into the bug report and remove the "noreg-sqe" label. It is Ok if you did not reproduce it, though. Thanks, Serguei On 7/8/13 4:20 PM, Daniel D. Daugherty wrote: I definitely don't insist... :-) BTW, I noticed this in Peter's e-mail: > Testing: > JPRT, reproducing script on Solaris, Linux. so maybe Peter already has this covered with "reproducing script"... Dan On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com wrote: Dan, Dan, thank you for the recommendation. But I'm still not sure it is a right thing to do. Even though, there are multiple test cases associated with this bug they can not be used to verify that fix because an additional condition must be present as well. This condition is a presence of stale door file which is not that easy to reproduce. However, if you insist then I can change the lable to the "noreg-sqe" with the corresponding comment. Thanks, Serguei On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: Serguei, There are a number of existing tests associated with this bug. I don't think that 'noreg-hard' is the right label. I think 'noreg-sqe' is the right one: noreg-sqe Change can be verified by running an existing SQE test suite; the bug should identify the suite and the specific test case(s). Dan On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com wrote: Peter, I've added the label "noreg-hard" with the comment to the report. It is not easy to reproduce the issue and demonstrate the fix in a regression test. Thanks, Serguei On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com wrote: Hi Peter, The fix looks good. Thanks, Serguei On 7/8/13 6:54 AM, Peter Allwin wrote: Hello! Looking for reviews of this change: http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ For CR: http://bugs.sun.com/view_bug.do?bug_id=7162400 https://jbs.oracle.com/bugs/browse/JDK-7162400 Summary: This change addresses an issue in the Attach API on Solaris, Linux and BSD where an attaching application can receive IOExceptions such as "Bad file number" (Solaris), "Connection refused" (Linux/BSD), or "well-known file is not secure". The attach process uses a file in the temporary directory as a door (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In certain circumstances stale files can be left in the file system which can cause the attaching application to believe that the VM is ready to receive a connection when it's not. With this change the stale file will be removed during VM startup. Note that there is still an issue if we don't have permission to remove the stale file, the attaching process will fail to connect. Testing: JPRT, reproducing script on Solaris, Linux. Credits: Thanks to Staffan Larsen who worked on this issue with me. Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130709/eb21a0fd/attachment.html From peter.allwin at oracle.com Tue Jul 9 05:26:21 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Tue, 9 Jul 2013 14:26:21 +0200 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DB3CE0.9070804@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB3CE0.9070804@oracle.com> Message-ID: <014c01ce7c9f$8662f6c0$9328e440$@oracle.com> Oh my bad, I'll update the webrev. Thanks! /peter From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Tuesday, July 9, 2013 12:28 AM To: Peter Allwin Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand On 7/8/13 7:54 AM, Peter Allwin wrote: Hello! Looking for reviews of this change: http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ src/share/vm/services/attachListener.hpp No comments. src/os/bsd/vm/attachListener_bsd.cpp line 443: // an attaching process to think we are ready to recieve on the typo: 'recieve' -> 'receive' src/os/linux/vm/attachListener_linux.cpp line 438: // an attaching process to think we are ready to recieve on the typo: 'recieve' -> 'receive' src/os/solaris/vm/attachListener_solaris.cpp line 582: // an attaching process to think we are ready to recieve a door_call typo: 'recieve' -> 'receive' src/os/windows/vm/attachListener_windows.cpp No comments. src/share/vm/runtime/thread.cpp No comments. Thumbs up. Dan For CR: http://bugs.sun.com/view_bug.do?bug_id=7162400 https://jbs.oracle.com/bugs/browse/JDK-7162400 Summary: This change addresses an issue in the Attach API on Solaris, Linux and BSD where an attaching application can receive IOExceptions such as "Bad file number" (Solaris), "Connection refused" (Linux/BSD), or "well-known file is not secure". The attach process uses a file in the temporary directory as a door (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In certain circumstances stale files can be left in the file system which can cause the attaching application to believe that the VM is ready to receive a connection when it's not. With this change the stale file will be removed during VM startup. Note that there is still an issue if we don't have permission to remove the stale file, the attaching process will fail to connect. Testing: JPRT, reproducing script on Solaris, Linux. Credits: Thanks to Staffan Larsen who worked on this issue with me. Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130709/dbb2251f/attachment.html From peter.allwin at oracle.com Tue Jul 9 05:37:06 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Tue, 9 Jul 2013 14:37:06 +0200 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DBF851.9090401@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DBF851.9090401@oracle.com> Message-ID: <017701ce7ca1$07ff16e0$17fd44a0$@oracle.com> Hi David, I changed the is_init_trigger's max path to be consistent within the file. This was probably an oversight when is_init_trigger was introduced as all other paths in attachListener_(linux|bsd) use UNIX_PATH_MAX. I'm not sure which limit is correct. Should I revert those lines? Thanks! /peter -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Tuesday, July 9, 2013 1:47 PM To: Peter Allwin Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Hi Peter, Why did you change from using PATH_MAX+1 to UNIX_PATH_MAX in is_init_trigger? AFAICS the .attach_pid file is not linked to a socket and so not limited to UNIX_PATH_MAX. David On 8/07/2013 11:54 PM, Peter Allwin wrote: > Hello! > > Looking for reviews of this change: > > http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ > > For CR: > > http://bugs.sun.com/view_bug.do?bug_id=7162400 > > https://jbs.oracle.com/bugs/browse/JDK-7162400 > > Summary: > > This change addresses an issue in the Attach API on Solaris, Linux and > BSD where an attaching application can receive IOExceptions such as > "Bad file number" (Solaris), "Connection refused" (Linux/BSD), or > "well-known file is not secure". > > The attach process uses a file in the temporary directory as a door > (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In > certain circumstances stale files can be left in the file system which > can cause the attaching application to believe that the VM is ready to > receive a connection when it's not. With this change the stale file > will be removed during VM startup. > > Note that there is still an issue if we don't have permission to > remove the stale file, the attaching process will fail to connect. > > Testing: > > JPRT, reproducing script on Solaris, Linux. > > Credits: > > Thanks to Staffan Larsen who worked on this issue with me. > > Regards, > > Peter > From mikael.gerdin at oracle.com Tue Jul 9 05:48:34 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Jul 2013 14:48:34 +0200 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <013d01ce7c9f$6d1f86b0$475e9410$@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> <51DB4950.7080504@oracle.com> <51DB4A8A.7010205@oracle.com> <013d01ce7c9f$6d1f86b0$475e9410$@oracle.com> Message-ID: <51DC06A2.7040107@oracle.com> Peter, On 2013-07-09 14:25, Peter Allwin wrote: > Hello! > > It is reproducible by letting the test create .java_pid* files for all > possible process id?s on the system, setting correct access flags, > launching the target VM and attempting to connect. There are some > caveats though but it should be doable. > > I?ll convert the repro script to JTREG and add it to the webrev. It's probably not a good idea to have a test which taints the system with stale .java_pid* files. If the test execution times out and the script isn't allowed to clean up I imagine that other subsequent executions could fail. Is there a way to tell the attach api to use a specific directory so you won't need to taint /tmp? /Mikael > > Thanks for the reviews! > > /peter > > *From:*serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] > *Sent:* Tuesday, July 9, 2013 1:26 AM > *To:* daniel.daugherty at oracle.com > *Cc:* Peter Allwin; serviceability-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: RFR 7162400: Intermittent java.io.IOException: Bad file > number during HotSpotVirtualMachine.executeCommand > > Ok, thanks! > > Peter, did you manage to reproduce this issue with your script? > If so, then, please, include it into the bug report and remove the > "noreg-sqe" label. > > It is Ok if you did not reproduce it, though. > > Thanks, > Serguei > > > On 7/8/13 4:20 PM, Daniel D. Daugherty wrote: > > I definitely don't insist... :-) > > BTW, I noticed this in Peter's e-mail: > > > Testing: > > JPRT, reproducing script on Solaris, Linux. > > so maybe Peter already has this covered with "reproducing script"... > > Dan > > On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com > wrote: > > Dan, > > Dan, thank you for the recommendation. > But I'm still not sure it is a right thing to do. > Even though, there are multiple test cases associated with this > bug they > can not be used to verify that fix because an additional condition > must be present as well. > This condition is a presence of stale door file which is not > that easy to reproduce. > > However, if you insist then I can change the lable to the > "noreg-sqe" > with the corresponding comment. > > Thanks, > Serguei > > > On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: > > Serguei, > > There are a number of existing tests associated with this > bug. I don't > think that 'noreg-hard' is the right label. I think > 'noreg-sqe' is > the right one: > > noreg-sqe > Change can be verified by running an existing SQE test > suite; the bug > should identify the suite and the specific test case(s). > > Dan > > On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com > wrote: > > Peter, > > I've added the label "noreg-hard" with the comment to > the report. > It is not easy to reproduce the issue and demonstrate > the fix in a regression test. > > Thanks, > Serguei > > > On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com > wrote: > > Hi Peter, > > The fix looks good. > > Thanks, > Serguei > > On 7/8/13 6:54 AM, Peter Allwin wrote: > > Hello! > > Looking for reviews of this change: > > http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ > > > For CR: > > http://bugs.sun.com/view_bug.do?bug_id=7162400 > > https://jbs.oracle.com/bugs/browse/JDK-7162400 > > Summary: > > This change addresses an issue in the Attach API > on Solaris, Linux and BSD where an attaching > application can receive IOExceptions such as > ?Bad file number? (Solaris), ?Connection > refused? (Linux/BSD), or ?well-known file is not > secure?. > > The attach process uses a file in the temporary > directory as a door (Solaris) or domain socket > (Linux,BSD) to communicate with the VM. In > certain circumstances stale files can be left in > the file system which can cause the attaching > application to believe that the VM is ready to > receive a connection when it?s not. With this > change the stale file will be removed during VM > startup. > > Note that there is still an issue if we don?t > have permission to remove the stale file, the > attaching process will fail to connect. > > Testing: > > JPRT, reproducing script on Solaris, Linux. > > Credits: > > Thanks to Staffan Larsen who worked on this > issue with me. > > Regards, > > > Peter > From peter.allwin at oracle.com Tue Jul 9 05:50:53 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Tue, 9 Jul 2013 14:50:53 +0200 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DBF94D.7080201@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DBF94D.7080201@oracle.com> Message-ID: <017801ce7ca2$f3b5d7d0$db218770$@oracle.com> Unless -XX:+StartAttachListener is used init will only be called after the attaching process has signaled the VM to attach, at which point the attaching process will already have attempted to do a door_call/open a domain socket using the stale file. Thanks for the feedback! /peter -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Tuesday, July 9, 2013 1:52 PM To: Peter Allwin Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand PS. Why not put the vm_start logic directly into the init method? David On 8/07/2013 11:54 PM, Peter Allwin wrote: > Hello! > > Looking for reviews of this change: > > http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ > > For CR: > > http://bugs.sun.com/view_bug.do?bug_id=7162400 > > https://jbs.oracle.com/bugs/browse/JDK-7162400 > > Summary: > > This change addresses an issue in the Attach API on Solaris, Linux and > BSD where an attaching application can receive IOExceptions such as > "Bad file number" (Solaris), "Connection refused" (Linux/BSD), or > "well-known file is not secure". > > The attach process uses a file in the temporary directory as a door > (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In > certain circumstances stale files can be left in the file system which > can cause the attaching application to believe that the VM is ready to > receive a connection when it's not. With this change the stale file > will be removed during VM startup. > > Note that there is still an issue if we don't have permission to > remove the stale file, the attaching process will fail to connect. > > Testing: > > JPRT, reproducing script on Solaris, Linux. > > Credits: > > Thanks to Staffan Larsen who worked on this issue with me. > > Regards, > > Peter > From ivan.gerasimov at oracle.com Tue Jul 9 06:09:32 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 09 Jul 2013 17:09:32 +0400 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51DAF69C.3000404@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> <51D64D15.2090105@oracle.com> <51D6A59A.1060703@oracle.com> <51D6B1ED.9090709@oracle.com> <51DAEF13.8010000@oracle.com> <51DAF69C.3000404@oracle.com> Message-ID: <51DC0B8C.9010804@oracle.com> Please have a chance to review an updated webrev. It now includes a change to ProblemList.txt, so both modified tests are ignored for linux-x64. Sincerely yours, Ivan Gersimov On 08.07.2013 21:27, Se?n Coffey wrote: > > On 08/07/13 17:55, Ivan Gerasimov wrote: >> Thanks, Se?n! >> >> I located the build in which the memleak was first introduced -- it >> is jdk8-b69 (hs25-b13). >> I've updated the bug http://bugs.sun.com/view_bug.do?bug_id=8019845 >> with this. >> >> So what is the correct procedure to go forward now? >> Should I update the webrev to include changes to the problem list? >> I believe I shouldn't -- this list seems to be a sensitive stuff. > I'd suggest updating the webrev with the ProblemList > modification/addition. It's best not to add a test to testruns if it's > knowingly failing. The test can be removed from ProblemList when the > jdk8 regression is fixed. > > regards, > Sean. > >> >> Sincerely yours, >> Ivan >> >> >> On 05.07.2013 15:45, Se?n Coffey wrote: >>> Nice work indeed Ivan. Good to have a reliable testcase to catch >>> leaks in this area. >>> >>> I'd also suggest that this test goes on the ProblemList until the >>> new leak is sorted out for jdk8. The goal of JPRT runs is to have >>> clean runs. If it's on the problemList, then it's a known issue and >>> is normally tagged with the relevant bug ID so that the responsible >>> engineer knows the current state. >>> >>> regards, >>> Sean. >>> >>> On 05/07/2013 11:53, Ivan Gerasimov wrote: >>>> >>>> On 05.07.2013 8:35, Daniel D. Daugherty wrote: >>>>> Ivan, >>>>> >>>>> The changes look fine, I can sponsor your commit, looks like your >>>>> OpenJDK user name is 'igerasim', but I need to know a little bit >>>>> more about your testing of these fixes. Did you do a test JPRT >>>>> job to run the JLI tests (or just the two tests themselves)? >>>>> >>>> I've only run test from java/lang/instrument when checked the >>>> change with JDK6u60 (all passed) and with JDK6u51 (the test failed >>>> as expected, since the leak had still been there.) >>>> >>>>> Based on e-mail about this bug fix, I believe you've found a new >>>>> leak in JDK8/HSX-25 with test >>>>> java/lang/instrument/RedefineBigClass.sh. >>>> Right. The test shown a memleak with the the latest jdk8. >>>> I filed a bug 8019845 about this leak. >>>> Stefan Karlsson guessed that this may be related to 8003419 (NPG: >>>> Clean up metadata created during class loading if failure) >>>> Then I've checked the builds b57 (test failed) and b58 (test >>>> passed), so I confirmed that it may be the reason of the leak being >>>> observed now. >>>> But now I think that the reason may be different. >>>> It just turns out that the test shows failures for (at least) three >>>> different leaks - the one you, Daniel, solved (7121600), the one >>>> Stefan wrote about (8003419) and the one currently observed (8019845). >>>> >>>>> That's a good thing, but I think Alan and company would be a bit >>>>> grumpy with me if I pushed a test that failed as soon as someone >>>>> ran it. :-) Do you know if the revised RetransformBigClass.sh also >>>>> finds a new memory leak in JDK8/HSX-25? >>>>> >>>>> The way to deal with that is to put the test on the Problem.list >>>>> as part of the same changeset. However, the T&L folks might not like >>>>> that either... >>>> >>>> Well, the leak is there, and why not have a failing test as a >>>> reminder to have it fixed? >>>> >>>> Sincerely yours, >>>> Ivan Gerasimov >>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 7/4/13 6:59 PM, Ivan Gerasimov wrote: >>>>>> Thank you, Daniel! >>>>>> >>>>>> Please find an updated webrev at >>>>>> http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. >>>>>> It now includes the RetransformBigClass test modified in the same >>>>>> way as RedefineBigClass >>>>>> If the changes look fine, may I ask you to sponsor the commit, as >>>>>> I'm not a committer? >>>>>> Here's a link to hg export: >>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch >>>>>> >>>>>> >>>>>> Thanks in advance, >>>>>> Ivan >>>>>> >>>>>> On 04.07.2013 21:45, Daniel D. Daugherty wrote: >>>>>>> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>>>>>>> Daniel, thank you for review! >>>>>>>> >>>>>>>> Here's the updated with all all your suggestions adopted. >>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >>>>>>> >>>>>>> Looks good. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> I haven't yet considered applying the approach to >>>>>>>> RetransformBigClass. >>>>>>>> Do you want me to include this into this same change set or >>>>>>>> should I make it separately? >>>>>>> >>>>>>> I would include it in the same changeset. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> >>>>>>>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>>>>>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>>>>>>> Hello everybody! >>>>>>>>>> >>>>>>>>>> We have a request to improve jtreg test. >>>>>>>>>> The test had been written to verify fix for memory leak >>>>>>>>>> during class redefinition. >>>>>>>>>> The problem is that it always is reported as PASSED even in >>>>>>>>>> the presence of the leak. >>>>>>>>>> >>>>>>>>>> The proposed change is platform specific. >>>>>>>>>> It allows memory leak detection only on Linux. >>>>>>>>>> This is because the memory leak was in native code, so >>>>>>>>>> there's no easy way to detect it from within Java code. >>>>>>>>>> >>>>>>>>>> Here's the webrev for JDK8 repository: >>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>>>>>>> >>>>>>>>> Very nicely done! The logic in RedefineBigClass.sh only catches a >>>>>>>>> leak big enough to cause an Exception to be thrown. >>>>>>>>> >>>>>>>>> When I originally wrote this test and its companion: >>>>>>>>> >>>>>>>>> test/java/lang/instrument/RetransformBigClass* >>>>>>>>> >>>>>>>>> I could not come up with a platform independent way to put a >>>>>>>>> small >>>>>>>>> upper limit on memory growth. It never dawned on me that >>>>>>>>> putting in >>>>>>>>> something on one platform (Linux) was better than nothing. >>>>>>>>> >>>>>>>>> Are you planning to add this same logic to RetransformBigClass*? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> test/java/lang/instrument/RedefineBigClass.sh >>>>>>>>> No comments. >>>>>>>>> >>>>>>>>> test/java/lang/instrument/RedefineBigClassApp.java >>>>>>>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb >>>>>>>>> Would be better at the top of RedefineBigClassApp >>>>>>>>> rather than >>>>>>>>> "buried" down here. >>>>>>>>> >>>>>>>>> line 51: Long.valueOf(vmMemDelta) >>>>>>>>> There are several places where a long is passed to >>>>>>>>> Long.valueOf(). >>>>>>>>> Is there some reason you're not passing them directly >>>>>>>>> to println()? >>>>>>>>> >>>>>>>>> line 54: } else { >>>>>>>>> The "else" is redundant due to the "System.exit(1)" >>>>>>>>> call above it. >>>>>>>>> You can drop the "else {" and "}" and shift that last >>>>>>>>> println() to >>>>>>>>> the left. >>>>>>>>> >>>>>>>>> line 71: return Long.parseLong(line.split(" ")[22]) / 1024; >>>>>>>>> How about at least a comment referring to the Linux >>>>>>>>> proc(5) >>>>>>>>> man page... and the fact that the 23rd field is: >>>>>>>>> >>>>>>>>> vsize %lu Virtual memory size in bytes. >>>>>>>>> >>>>>>>>> Again, very nicely done! >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> The surprising thing is that modified test detected the leak >>>>>>>>>> with the latest JDK8! >>>>>>>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>>>>>>> >>>>>>>>>> I've filled a bug >>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019845 "Memory leak >>>>>>>>>> during class redefenition" (not yet available.) >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan Gerasimov >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >> > > > From christian.tornqvist at oracle.com Tue Jul 9 06:49:02 2013 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 9 Jul 2013 09:49:02 -0400 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <004101ce7be2$bd046410$370d2c30$@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> Message-ID: <015001ce7cab$12e80350$38b809f0$@oracle.com> Hi Peter, Looks good, thanks for fixing this. Thanks, Christian From: hotspot-runtime-dev-bounces at openjdk.java.net [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Peter Allwin Sent: den 8 juli 2013 09:55 To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Hello! Looking for reviews of this change: http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ For CR: http://bugs.sun.com/view_bug.do?bug_id=7162400 https://jbs.oracle.com/bugs/browse/JDK-7162400 Summary: This change addresses an issue in the Attach API on Solaris, Linux and BSD where an attaching application can receive IOExceptions such as "Bad file number" (Solaris), "Connection refused" (Linux/BSD), or "well-known file is not secure". The attach process uses a file in the temporary directory as a door (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In certain circumstances stale files can be left in the file system which can cause the attaching application to believe that the VM is ready to receive a connection when it's not. With this change the stale file will be removed during VM startup. Note that there is still an issue if we don't have permission to remove the stale file, the attaching process will fail to connect. Testing: JPRT, reproducing script on Solaris, Linux. Credits: Thanks to Staffan Larsen who worked on this issue with me. Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130709/a7f75cd4/attachment-0001.html From paul.sandoz at oracle.com Tue Jul 9 07:15:23 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 09 Jul 2013 14:15:23 +0000 Subject: hg: jdk8/tl/jdk: 8019370: Sync j.u.c Fork/Join from 166 to tl Message-ID: <20130709141553.2B297488F7@hg.openjdk.java.net> Changeset: 43134e79c0bb Author: psandoz Date: 2013-07-09 16:04 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43134e79c0bb 8019370: Sync j.u.c Fork/Join from 166 to tl Reviewed-by: chegar, martin Contributed-by: Doug Lea

! src/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/share/classes/java/util/concurrent/Callable.java ! src/share/classes/java/util/concurrent/CancellationException.java ! src/share/classes/java/util/concurrent/CompletableFuture.java ! src/share/classes/java/util/concurrent/CompletionService.java ! src/share/classes/java/util/concurrent/CountedCompleter.java ! src/share/classes/java/util/concurrent/ExecutionException.java ! src/share/classes/java/util/concurrent/Executor.java ! src/share/classes/java/util/concurrent/ExecutorService.java ! src/share/classes/java/util/concurrent/Executors.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 ! src/share/classes/java/util/concurrent/Future.java ! src/share/classes/java/util/concurrent/FutureTask.java ! src/share/classes/java/util/concurrent/RecursiveAction.java ! src/share/classes/java/util/concurrent/RecursiveTask.java ! src/share/classes/java/util/concurrent/RejectedExecutionException.java ! src/share/classes/java/util/concurrent/RunnableFuture.java ! src/share/classes/java/util/concurrent/RunnableScheduledFuture.java ! src/share/classes/java/util/concurrent/ScheduledExecutorService.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java From sean.coffey at oracle.com Tue Jul 9 08:04:04 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 09 Jul 2013 15:04:04 +0000 Subject: hg: jdk8/tl/jdk: 8019979: Replace CheckPackageAccess test with better one from closed repo Message-ID: <20130709150434.9A466488FA@hg.openjdk.java.net> Changeset: 83c2976ef8ee Author: coffeys Date: 2013-07-09 16:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/83c2976ef8ee 8019979: Replace CheckPackageAccess test with better one from closed repo Reviewed-by: mullan ! test/java/lang/SecurityManager/CheckPackageAccess.java From peter.allwin at oracle.com Tue Jul 9 08:25:48 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Tue, 9 Jul 2013 17:25:48 +0200 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DC06A2.7040107@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> <51DB4950.7080504@oracle.com> <51DB4A8A.7010205@oracle.com> <013d01ce7c9f$6d1f86b0$475e9410$@oracle.com> <51DC06A2.7040107@oracle.com> Message-ID: <01cf01ce7cb8$98058b90$c810a2b0$@oracle.com> Mikael, That's a good point, unfortunately attach uses os::get_temp_directory which is hardcoded to use /tmp. We could add a whitebox API to allow us to override this but now we're on the border to noreg-hard land again IMO. Any other opinions on this? Thanks! /peter > -----Original Message----- > From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > Sent: Tuesday, July 9, 2013 2:49 PM > To: Peter Allwin > Cc: serguei.spitsyn at oracle.com; daniel.daugherty at oracle.com; > serviceability-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file number > during HotSpotVirtualMachine.executeCommand > > Peter, > > On 2013-07-09 14:25, Peter Allwin wrote: > > Hello! > > > > It is reproducible by letting the test create .java_pid* files for all > > possible process id's on the system, setting correct access flags, > > launching the target VM and attempting to connect. There are some > > caveats though but it should be doable. > > > > I'll convert the repro script to JTREG and add it to the webrev. > > It's probably not a good idea to have a test which taints the system with stale > .java_pid* files. > If the test execution times out and the script isn't allowed to clean up I > imagine that other subsequent executions could fail. > Is there a way to tell the attach api to use a specific directory so you won't > need to taint /tmp? > > /Mikael > > > > > Thanks for the reviews! > > > > /peter > > > > *From:*serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] > > *Sent:* Tuesday, July 9, 2013 1:26 AM > > *To:* daniel.daugherty at oracle.com > > *Cc:* Peter Allwin; serviceability-dev at openjdk.java.net; > > hotspot-runtime-dev at openjdk.java.net > > *Subject:* Re: RFR 7162400: Intermittent java.io.IOException: Bad file > > number during HotSpotVirtualMachine.executeCommand > > > > Ok, thanks! > > > > Peter, did you manage to reproduce this issue with your script? > > If so, then, please, include it into the bug report and remove the > > "noreg-sqe" label. > > > > It is Ok if you did not reproduce it, though. > > > > Thanks, > > Serguei > > > > > > On 7/8/13 4:20 PM, Daniel D. Daugherty wrote: > > > > I definitely don't insist... :-) > > > > BTW, I noticed this in Peter's e-mail: > > > > > Testing: > > > JPRT, reproducing script on Solaris, Linux. > > > > so maybe Peter already has this covered with "reproducing script"... > > > > Dan > > > > On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com > > wrote: > > > > Dan, > > > > Dan, thank you for the recommendation. > > But I'm still not sure it is a right thing to do. > > Even though, there are multiple test cases associated with this > > bug they > > can not be used to verify that fix because an additional condition > > must be present as well. > > This condition is a presence of stale door file which is not > > that easy to reproduce. > > > > However, if you insist then I can change the lable to the > > "noreg-sqe" > > with the corresponding comment. > > > > Thanks, > > Serguei > > > > > > On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: > > > > Serguei, > > > > There are a number of existing tests associated with this > > bug. I don't > > think that 'noreg-hard' is the right label. I think > > 'noreg-sqe' is > > the right one: > > > > noreg-sqe > > Change can be verified by running an existing SQE test > > suite; the bug > > should identify the suite and the specific test case(s). > > > > Dan > > > > On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com > > wrote: > > > > Peter, > > > > I've added the label "noreg-hard" with the comment to > > the report. > > It is not easy to reproduce the issue and demonstrate > > the fix in a regression test. > > > > Thanks, > > Serguei > > > > > > On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com > > wrote: > > > > Hi Peter, > > > > The fix looks good. > > > > Thanks, > > Serguei > > > > On 7/8/13 6:54 AM, Peter Allwin wrote: > > > > Hello! > > > > Looking for reviews of this change: > > > > http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ > > > > > > > > For CR: > > > > http://bugs.sun.com/view_bug.do?bug_id=7162400 > > > > https://jbs.oracle.com/bugs/browse/JDK-7162400 > > > > Summary: > > > > This change addresses an issue in the Attach API > > on Solaris, Linux and BSD where an attaching > > application can receive IOExceptions such as > > "Bad file number" (Solaris), "Connection > > refused" (Linux/BSD), or "well-known file is not > > secure". > > > > The attach process uses a file in the temporary > > directory as a door (Solaris) or domain socket > > (Linux,BSD) to communicate with the VM. In > > certain circumstances stale files can be left in > > the file system which can cause the attaching > > application to believe that the VM is ready to > > receive a connection when it's not. With this > > change the stale file will be removed during VM > > startup. > > > > Note that there is still an issue if we don't > > have permission to remove the stale file, the > > attaching process will fail to connect. > > > > Testing: > > > > JPRT, reproducing script on Solaris, Linux. > > > > Credits: > > > > Thanks to Staffan Larsen who worked on this > > issue with me. > > > > Regards, > > > > > > Peter > > From mikael.gerdin at oracle.com Tue Jul 9 10:12:33 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Jul 2013 19:12:33 +0200 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <01cf01ce7cb8$98058b90$c810a2b0$@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> <51DB4950.7080504@oracle.com> <51DB4A8A.7010205@oracle.com> <013d01ce7c9f$6d1f86b0$475e9410$@oracle.com> <51DC06A2.7040107@oracle.com> <01cf01ce7cb8$98058b90$c810a2b0$@oracle.com> Message-ID: <51DC4481.3000700@oracle.com> On 07/09/2013 05:25 PM, Peter Allwin wrote: > Mikael, > > That's a good point, unfortunately attach uses os::get_temp_directory which > is hardcoded to use /tmp. We could add a whitebox API to allow us to > override this but now we're on the border to noreg-hard land again IMO. > > Any other opinions on this? Can you use the "-XX:+PauseAtStartup" vm flag it will create a vm.paused. file in the current work directory. You could extract the pid, touch the correct attach file in /tmp and then remove the vm.paused to let the VM resume. I didn't check if PauseAtStartup stops the VM early enough though. An alternate, even more hacky approach is to do something like (in bash): (bash -c 'echo $$; touch /tmp/.java_pid$$; exec java -version') Where you can extract the pid of the subshell process with $$ and then exec into the java launcher and keep the same pid (at least on Linux, unsure about the Solaris launcher). /Mikael > > > Thanks! > > /peter > >> -----Original Message----- >> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >> Sent: Tuesday, July 9, 2013 2:49 PM >> To: Peter Allwin >> Cc: serguei.spitsyn at oracle.com; daniel.daugherty at oracle.com; >> serviceability-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file > number >> during HotSpotVirtualMachine.executeCommand >> >> Peter, >> >> On 2013-07-09 14:25, Peter Allwin wrote: >>> Hello! >>> >>> It is reproducible by letting the test create .java_pid* files for all >>> possible process id's on the system, setting correct access flags, >>> launching the target VM and attempting to connect. There are some >>> caveats though but it should be doable. >>> >>> I'll convert the repro script to JTREG and add it to the webrev. >> >> It's probably not a good idea to have a test which taints the system with > stale >> .java_pid* files. >> If the test execution times out and the script isn't allowed to clean up I >> imagine that other subsequent executions could fail. >> Is there a way to tell the attach api to use a specific directory so you > won't >> need to taint /tmp? >> >> /Mikael >> >>> >>> Thanks for the reviews! >>> >>> /peter >>> >>> *From:*serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] >>> *Sent:* Tuesday, July 9, 2013 1:26 AM >>> *To:* daniel.daugherty at oracle.com >>> *Cc:* Peter Allwin; serviceability-dev at openjdk.java.net; >>> hotspot-runtime-dev at openjdk.java.net >>> *Subject:* Re: RFR 7162400: Intermittent java.io.IOException: Bad file >>> number during HotSpotVirtualMachine.executeCommand >>> >>> Ok, thanks! >>> >>> Peter, did you manage to reproduce this issue with your script? >>> If so, then, please, include it into the bug report and remove the >>> "noreg-sqe" label. >>> >>> It is Ok if you did not reproduce it, though. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 7/8/13 4:20 PM, Daniel D. Daugherty wrote: >>> >>> I definitely don't insist... :-) >>> >>> BTW, I noticed this in Peter's e-mail: >>> >>> > Testing: >>> > JPRT, reproducing script on Solaris, Linux. >>> >>> so maybe Peter already has this covered with "reproducing script"... >>> >>> Dan >>> >>> On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com >>> wrote: >>> >>> Dan, >>> >>> Dan, thank you for the recommendation. >>> But I'm still not sure it is a right thing to do. >>> Even though, there are multiple test cases associated with this >>> bug they >>> can not be used to verify that fix because an additional > condition >>> must be present as well. >>> This condition is a presence of stale door file which is not >>> that easy to reproduce. >>> >>> However, if you insist then I can change the lable to the >>> "noreg-sqe" >>> with the corresponding comment. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: >>> >>> Serguei, >>> >>> There are a number of existing tests associated with this >>> bug. I don't >>> think that 'noreg-hard' is the right label. I think >>> 'noreg-sqe' is >>> the right one: >>> >>> noreg-sqe >>> Change can be verified by running an existing SQE test >>> suite; the bug >>> should identify the suite and the specific test > case(s). >>> >>> Dan >>> >>> On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com >>> wrote: >>> >>> Peter, >>> >>> I've added the label "noreg-hard" with the comment to >>> the report. >>> It is not easy to reproduce the issue and demonstrate >>> the fix in a regression test. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com >>> wrote: >>> >>> Hi Peter, >>> >>> The fix looks good. >>> >>> Thanks, >>> Serguei >>> >>> On 7/8/13 6:54 AM, Peter Allwin wrote: >>> >>> Hello! >>> >>> Looking for reviews of this change: >>> >>> > http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ >>> >>> >>> >>> For CR: >>> >>> http://bugs.sun.com/view_bug.do?bug_id=7162400 >>> >>> https://jbs.oracle.com/bugs/browse/JDK-7162400 >>> >>> Summary: >>> >>> This change addresses an issue in the Attach API >>> on Solaris, Linux and BSD where an attaching >>> application can receive IOExceptions such as >>> "Bad file number" (Solaris), "Connection >>> refused" (Linux/BSD), or "well-known file is not >>> secure". >>> >>> The attach process uses a file in the temporary >>> directory as a door (Solaris) or domain socket >>> (Linux,BSD) to communicate with the VM. In >>> certain circumstances stale files can be left in >>> the file system which can cause the attaching >>> application to believe that the VM is ready to >>> receive a connection when it's not. With this >>> change the stale file will be removed during VM >>> startup. >>> >>> Note that there is still an issue if we don't >>> have permission to remove the stale file, the >>> attaching process will fail to connect. >>> >>> Testing: >>> >>> JPRT, reproducing script on Solaris, Linux. >>> >>> Credits: >>> >>> Thanks to Staffan Larsen who worked on this >>> issue with me. >>> >>> Regards, >>> >>> >>> Peter >>> > From serguei.spitsyn at oracle.com Tue Jul 9 10:15:32 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 09 Jul 2013 10:15:32 -0700 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DC06A2.7040107@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> <51DB4950.7080504@oracle.com> <51DB4A8A.7010205@oracle.com> <013d01ce7c9f$6d1f86b0$475e9410$@oracle.com> <51DC06A2.7040107@oracle.com> Message-ID: <51DC4534.9080802@oracle.com> On 7/9/13 5:48 AM, Mikael Gerdin wrote: > Peter, > > On 2013-07-09 14:25, Peter Allwin wrote: >> Hello! >> >> It is reproducible by letting the test create .java_pid* files for all >> possible process id?s on the system, setting correct access flags, >> launching the target VM and attempting to connect. There are some >> caveats though but it should be doable. >> >> I?ll convert the repro script to JTREG and add it to the webrev. > > It's probably not a good idea to have a test which taints the system > with stale .java_pid* files. > If the test execution times out and the script isn't allowed to clean > up I imagine that other subsequent executions could fail. I have the same concern. Such a test can create more problems than it solves. > Is there a way to tell the attach api to use a specific directory so > you won't need to taint /tmp? I doubt the attach api has an option to do that. But even if it has it still looks to much from the test to create many files just to check one condition. I think, the script should be enough for the SQE to verify that the issue has been fixed. We don't need to run it on regular base. This is my personal opinion, not sure everyone will agree with it. :) Thanks, Serguei > > /Mikael > >> >> Thanks for the reviews! >> >> /peter >> >> *From:*serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] >> *Sent:* Tuesday, July 9, 2013 1:26 AM >> *To:* daniel.daugherty at oracle.com >> *Cc:* Peter Allwin; serviceability-dev at openjdk.java.net; >> hotspot-runtime-dev at openjdk.java.net >> *Subject:* Re: RFR 7162400: Intermittent java.io.IOException: Bad file >> number during HotSpotVirtualMachine.executeCommand >> >> Ok, thanks! >> >> Peter, did you manage to reproduce this issue with your script? >> If so, then, please, include it into the bug report and remove the >> "noreg-sqe" label. >> >> It is Ok if you did not reproduce it, though. >> >> Thanks, >> Serguei >> >> >> On 7/8/13 4:20 PM, Daniel D. Daugherty wrote: >> >> I definitely don't insist... :-) >> >> BTW, I noticed this in Peter's e-mail: >> >> > Testing: >> > JPRT, reproducing script on Solaris, Linux. >> >> so maybe Peter already has this covered with "reproducing script"... >> >> Dan >> >> On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com >> wrote: >> >> Dan, >> >> Dan, thank you for the recommendation. >> But I'm still not sure it is a right thing to do. >> Even though, there are multiple test cases associated with this >> bug they >> can not be used to verify that fix because an additional >> condition >> must be present as well. >> This condition is a presence of stale door file which is not >> that easy to reproduce. >> >> However, if you insist then I can change the lable to the >> "noreg-sqe" >> with the corresponding comment. >> >> Thanks, >> Serguei >> >> >> On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: >> >> Serguei, >> >> There are a number of existing tests associated with this >> bug. I don't >> think that 'noreg-hard' is the right label. I think >> 'noreg-sqe' is >> the right one: >> >> noreg-sqe >> Change can be verified by running an existing SQE test >> suite; the bug >> should identify the suite and the specific test >> case(s). >> >> Dan >> >> On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com >> wrote: >> >> Peter, >> >> I've added the label "noreg-hard" with the comment to >> the report. >> It is not easy to reproduce the issue and demonstrate >> the fix in a regression test. >> >> Thanks, >> Serguei >> >> >> On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com >> wrote: >> >> Hi Peter, >> >> The fix looks good. >> >> Thanks, >> Serguei >> >> On 7/8/13 6:54 AM, Peter Allwin wrote: >> >> Hello! >> >> Looking for reviews of this change: >> >> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ >> >> >> For CR: >> >> http://bugs.sun.com/view_bug.do?bug_id=7162400 >> >> https://jbs.oracle.com/bugs/browse/JDK-7162400 >> >> Summary: >> >> This change addresses an issue in the Attach API >> on Solaris, Linux and BSD where an attaching >> application can receive IOExceptions such as >> ?Bad file number? (Solaris), ?Connection >> refused? (Linux/BSD), or ?well-known file is not >> secure?. >> >> The attach process uses a file in the temporary >> directory as a door (Solaris) or domain socket >> (Linux,BSD) to communicate with the VM. In >> certain circumstances stale files can be left in >> the file system which can cause the attaching >> application to believe that the VM is ready to >> receive a connection when it?s not. With this >> change the stale file will be removed during VM >> startup. >> >> Note that there is still an issue if we don?t >> have permission to remove the stale file, the >> attaching process will fail to connect. >> >> Testing: >> >> JPRT, reproducing script on Solaris, Linux. >> >> Credits: >> >> Thanks to Staffan Larsen who worked on this >> issue with me. >> >> Regards, >> >> >> Peter >> From mandy.chung at oracle.com Tue Jul 9 12:42:43 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 09 Jul 2013 12:42:43 -0700 Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management Interfaces being public In-Reply-To: <51DBDFC8.4090800@oracle.com> References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com> <51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com> <51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com> <51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com> <51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com> <51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com> <51AF9A56.4090709@oracle.com> <51B0A937.90607@oracle.com> <51B0AAB7.7070802@oracle.com> <51B0B39C.1050305@oracle.com> <51B18803.7060406@oracle.com> <51B1A2E2.5030001@oracle.com> <51C03013.2020700@oracle.com> <51C0359F.8090201@oracle.com> <51C036AF.1030206@oracle.com> <51C0440B.9030601@oracle.com> <51DBDFC8.4090800@oracle.com> Message-ID: <51DC67B3.8060103@oracle.com> On 7/9/13 3:02 AM, Jaroslav Bachorik wrote: > Please, review the final version of the changes: > http://cr.openjdk.java.net/~jbachorik/8010285/webrev.07 > The change looks reasonable. In the class spec for MXBean, suggest to rename interface ThisIsNotMXBean{} to something more explicit interface NonPublicInterfaceNotMXBean{} You removed JMX.checkProxyInterface. I believe the checkPackageAccess method on the given mbean interface is called somewhere as part of the MBean validation - where is that check being done? Other than that, it's fine with me. Mandy > It addresses all the concerns raised during the CCC process. > > I will need at least one official OpenJDK reviewer for the integration. > > Thanks, > > -JB- From zhengyu.gu at oracle.com Tue Jul 9 13:42:35 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Tue, 09 Jul 2013 20:42:35 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130709204241.BA92248910@hg.openjdk.java.net> Changeset: 72fce0b2d341 Author: zgu Date: 2013-07-09 13:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/72fce0b2d341 8011760: assert(delta != 0) failed: dup pointer in MemBaseline::malloc_sort_by_addr Summary: Some of qsort implementation on Linux x86 compares element to itself, which is mistakenly treated as duplicate pointer Reviewed-by: dcubed, acorn ! src/share/vm/services/memBaseline.cpp Changeset: 2839ce15e450 Author: zgu Date: 2013-07-09 19:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2839ce15e450 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp From kumar.x.srinivasan at oracle.com Tue Jul 9 14:55:00 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 09 Jul 2013 21:55:00 +0000 Subject: hg: jdk8/tl/langtools: 8020214: TEST_BUG: test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java broken Message-ID: <20130709215503.592024891D@hg.openjdk.java.net> Changeset: aedb3bb327d5 Author: ksrini Date: 2013-07-09 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aedb3bb327d5 8020214: TEST_BUG: test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java broken Reviewed-by: jjg ! test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java From karen.kinnear at oracle.com Tue Jul 9 15:41:56 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Tue, 09 Jul 2013 22:41:56 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130709224202.CBEA34891F@hg.openjdk.java.net> Changeset: 50257d6f5aaa Author: acorn Date: 2013-07-09 14:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/50257d6f5aaa 8013635: VM should no longer create bridges for generic signatures. Summary: Requires: 8013789: Compiler bridges, 8015402: metafactory Reviewed-by: sspitsyn, coleenp, bharadwaj ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/runtime/globals.hpp Changeset: 22baec423e2f Author: acorn Date: 2013-07-09 22:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/22baec423e2f Merge From huizhe.wang at oracle.com Tue Jul 9 16:35:26 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Tue, 09 Jul 2013 23:35:26 +0000 Subject: hg: jdk8/tl/jaxp: 8016648: FEATURE_SECURE_PROCESSING set to true or false causes SAXParseException to be thrown Message-ID: <20130709233528.C625748920@hg.openjdk.java.net> Changeset: 3b071f506ab9 Author: joehw Date: 2013-07-09 16:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/3b071f506ab9 8016648: FEATURE_SECURE_PROCESSING set to true or false causes SAXParseException to be thrown Summary: jaxp 1.5 feature update Reviewed-by: alanb, dfuchs, lancea ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/SecuritySupport.java + src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/DOMParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java + src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java From david.holmes at oracle.com Tue Jul 9 19:04:09 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 10 Jul 2013 02:04:09 +0000 Subject: hg: jdk8/tl/jdk: 8016341: java/lang/ref/OOMEInReferenceHandler.java failing intermittently Message-ID: <20130710020433.BEABE48927@hg.openjdk.java.net> Changeset: 7bb17aa9a09f Author: dholmes Date: 2013-07-09 22:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bb17aa9a09f 8016341: java/lang/ref/OOMEInReferenceHandler.java failing intermittently Summary: Ensure WeakRef object can't be prematurely gc'd Reviewed-by: chegar, plevart ! test/java/lang/ref/OOMEInReferenceHandler.java From david.holmes at oracle.com Tue Jul 9 21:56:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Jul 2013 14:56:29 +1000 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <017701ce7ca1$07ff16e0$17fd44a0$@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DBF851.9090401@oracle.com> <017701ce7ca1$07ff16e0$17fd44a0$@oracle.com> Message-ID: <51DCE97D.7020908@oracle.com> On 9/07/2013 10:37 PM, Peter Allwin wrote: > Hi David, > > I changed the is_init_trigger's max path to be consistent within the file. > This was probably an oversight when is_init_trigger was introduced as all > other paths in attachListener_(linux|bsd) use UNIX_PATH_MAX. I'm not sure > which limit is correct. Should I revert those lines? Given the way the temp directory is hard-wired to /tmp it will not make a practical difference here as we will be well within both limits - but otherwise this change could have caused a failure if the full path was > 108 characters. The two limits are for different things. We only need to use UNIX_PATH_MAX when the path will be linked to a socket. For regular filesystem paths it is PATH_MAX that counts. I'd prefer to see it reverted. Thanks, David > > Thanks! > > /peter > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Tuesday, July 9, 2013 1:47 PM > To: Peter Allwin > Cc: serviceability-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file > number during HotSpotVirtualMachine.executeCommand > > Hi Peter, > > Why did you change from using PATH_MAX+1 to UNIX_PATH_MAX in > is_init_trigger? AFAICS the .attach_pid file is not linked to a socket and > so not limited to UNIX_PATH_MAX. > > David > > On 8/07/2013 11:54 PM, Peter Allwin wrote: >> Hello! >> >> Looking for reviews of this change: >> >> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ >> >> For CR: >> >> http://bugs.sun.com/view_bug.do?bug_id=7162400 >> >> https://jbs.oracle.com/bugs/browse/JDK-7162400 >> >> Summary: >> >> This change addresses an issue in the Attach API on Solaris, Linux and >> BSD where an attaching application can receive IOExceptions such as >> "Bad file number" (Solaris), "Connection refused" (Linux/BSD), or >> "well-known file is not secure". >> >> The attach process uses a file in the temporary directory as a door >> (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In >> certain circumstances stale files can be left in the file system which >> can cause the attaching application to believe that the VM is ready to >> receive a connection when it's not. With this change the stale file >> will be removed during VM startup. >> >> Note that there is still an issue if we don't have permission to >> remove the stale file, the attaching process will fail to connect. >> >> Testing: >> >> JPRT, reproducing script on Solaris, Linux. >> >> Credits: >> >> Thanks to Staffan Larsen who worked on this issue with me. >> >> Regards, >> >> Peter >> > From weijun.wang at oracle.com Wed Jul 10 00:13:03 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 10 Jul 2013 07:13:03 +0000 Subject: hg: jdk8/tl/jdk: 8019267: NPE in AbstractSaslImpl when trace level >= FINER in KRB5 Message-ID: <20130710071327.63CE44892F@hg.openjdk.java.net> Changeset: 780a64979c8d Author: weijun Date: 2013-07-10 15:11 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/780a64979c8d 8019267: NPE in AbstractSaslImpl when trace level >= FINER in KRB5 Reviewed-by: mullan ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! test/sun/security/krb5/auto/SaslGSS.java From paul.sandoz at oracle.com Wed Jul 10 00:53:00 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 10 Jul 2013 07:53:00 +0000 Subject: hg: jdk8/tl/jdk: 8017447: Unmodifiable map entry becomes modifiable if taken from a stream of map entries Message-ID: <20130710075325.715E148935@hg.openjdk.java.net> Changeset: ff5df05222d1 Author: psandoz Date: 2013-07-10 09:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff5df05222d1 8017447: Unmodifiable map entry becomes modifiable if taken from a stream of map entries Reviewed-by: briangoetz ! src/share/classes/java/util/Collections.java + test/java/util/Collections/UnmodifiableMapEntrySet.java From dmitry.samersoff at oracle.com Wed Jul 10 00:57:39 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 10 Jul 2013 11:57:39 +0400 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DCE97D.7020908@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DBF851.9090401@oracle.com> <017701ce7ca1$07ff16e0$17fd44a0$@oracle.com> <51DCE97D.7020908@oracle.com> Message-ID: <51DD13F3.5050507@oracle.com> David, Yes, UNIX_PATH_MAX is a historic constant that limit size of sun_path in sockaddr_un. But I would support Peter - on my opinion it's better to always use the same constant. And (being paranoid) it's better to check return value of snprintf to make sure we are getting correct file name to unlink. -Dmitry On 2013-07-10 08:56, David Holmes wrote: > On 9/07/2013 10:37 PM, Peter Allwin wrote: >> Hi David, >> >> I changed the is_init_trigger's max path to be consistent within the >> file. >> This was probably an oversight when is_init_trigger was introduced as all >> other paths in attachListener_(linux|bsd) use UNIX_PATH_MAX. I'm not sure >> which limit is correct. Should I revert those lines? > > Given the way the temp directory is hard-wired to /tmp it will not make > a practical difference here as we will be well within both limits - but > otherwise this change could have caused a failure if the full path was > > 108 characters. > > The two limits are for different things. We only need to use > UNIX_PATH_MAX when the path will be linked to a socket. For regular > filesystem paths it is PATH_MAX that counts. > > I'd prefer to see it reverted. > > Thanks, > David > >> >> Thanks! >> >> /peter >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Tuesday, July 9, 2013 1:47 PM >> To: Peter Allwin >> Cc: serviceability-dev at openjdk.java.net; >> hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file >> number during HotSpotVirtualMachine.executeCommand >> >> Hi Peter, >> >> Why did you change from using PATH_MAX+1 to UNIX_PATH_MAX in >> is_init_trigger? AFAICS the .attach_pid file is not linked to a socket >> and >> so not limited to UNIX_PATH_MAX. >> >> David >> >> On 8/07/2013 11:54 PM, Peter Allwin wrote: >>> Hello! >>> >>> Looking for reviews of this change: >>> >>> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ >>> >>> For CR: >>> >>> http://bugs.sun.com/view_bug.do?bug_id=7162400 >>> >>> https://jbs.oracle.com/bugs/browse/JDK-7162400 >>> >>> Summary: >>> >>> This change addresses an issue in the Attach API on Solaris, Linux and >>> BSD where an attaching application can receive IOExceptions such as >>> "Bad file number" (Solaris), "Connection refused" (Linux/BSD), or >>> "well-known file is not secure". >>> >>> The attach process uses a file in the temporary directory as a door >>> (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In >>> certain circumstances stale files can be left in the file system which >>> can cause the attaching application to believe that the VM is ready to >>> receive a connection when it's not. With this change the stale file >>> will be removed during VM startup. >>> >>> Note that there is still an issue if we don't have permission to >>> remove the stale file, the attaching process will fail to connect. >>> >>> Testing: >>> >>> JPRT, reproducing script on Solaris, Linux. >>> >>> Credits: >>> >>> Thanks to Staffan Larsen who worked on this issue with me. >>> >>> Regards, >>> >>> Peter >>> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From paul.sandoz at oracle.com Wed Jul 10 01:25:56 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 10 Jul 2013 08:25:56 +0000 Subject: hg: jdk8/tl/jdk: 8020040: Improve and generalize the F/J tasks to handle right or left-balanced trees Message-ID: <20130710082620.9896A4893A@hg.openjdk.java.net> Changeset: 882baa1e0a38 Author: psandoz Date: 2013-07-10 10:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/882baa1e0a38 8020040: Improve and generalize the F/J tasks to handle right or left-balanced trees Reviewed-by: briangoetz Contributed-by: doug lea
, paul sandoz ! src/share/classes/java/util/stream/AbstractShortCircuitTask.java ! src/share/classes/java/util/stream/AbstractTask.java ! src/share/classes/java/util/stream/ForEachOps.java ! src/share/classes/java/util/stream/Nodes.java From jaroslav.bachorik at oracle.com Wed Jul 10 01:33:17 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 10 Jul 2013 10:33:17 +0200 Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management Interfaces being public In-Reply-To: <51DC67B3.8060103@oracle.com> References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com> <51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com> <51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com> <51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com> <51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com> <51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com> <51AF9A56.4090709@oracle.com> <51B0A937.90607@oracle.com> <51B0AAB7.7070802@oracle.com> <51B0B39C.1050305@oracle.com> <51B18803.7060406@oracle.com> <51B1A2E2.5030001@oracle.com> <51C03013.2020700@oracle.com> <51C0359F.8090201@oracle.com> <51C036AF.1030206@oracle.com> <51C0440B.9030601@oracle.com> <51DBDFC8.4090800@oracle.com> <51DC67B3.8060103@oracle.com> Message-ID: <51DD1C4D.2060601@oracle.com> On 07/09/2013 09:42 PM, Mandy Chung wrote: > On 7/9/13 3:02 AM, Jaroslav Bachorik wrote: >> Please, review the final version of the changes: >> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.07 >> > > The change looks reasonable. In the class spec for MXBean, suggest to > rename > > interface ThisIsNotMXBean{} > > to something more explicit > > interface NonPublicInterfaceNotMXBean{} Since this was a part of the CCC review which was approved I am not sure if I am allowed to change the class spec. If it is allowed I have no objections against the proposal and will change the interface name. > > You removed JMX.checkProxyInterface. I believe the checkPackageAccess > method on the given mbean > interface is called somewhere as part of the MBean validation - where is > that check being done? com.sun.jmx.mbeanserver.MBeanIntrospector.getMethods() performs this check. It is not possible to construct an M(X)Bean proxy without consulting com.sun.jmx.mbeanserver.MBeanIntrospector.getMethods() first. This functionality is enforced by a closed vulnerability test. -JB- > > Other than that, it's fine with me. > > Mandy > >> It addresses all the concerns raised during the CCC process. >> >> I will need at least one official OpenJDK reviewer for the integration. >> >> Thanks, >> >> -JB- > From jaroslav.bachorik at oracle.com Wed Jul 10 02:10:52 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 10 Jul 2013 11:10:52 +0200 Subject: RFR: 8019826 Test com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java fails with NPE Message-ID: <51DD251C.5050009@oracle.com> Please, review this simple fix. http://cr.openjdk.java.net/~jbachorik/8019826/webrev.00 Firstly, the patch removes a conditional early exit which checks for a build 52 of an unspecified major JVM version - it is not needed any more. Basically, the condition just made the test a noop till the latest hotspot version. The second fix is correctly setting the "mbean" attribute - it was not properly initialized and because of this the test was going to fail with NPE. Thanks, -JB- From sean.coffey at oracle.com Wed Jul 10 02:15:36 2013 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 10 Jul 2013 10:15:36 +0100 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51DC0B8C.9010804@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> <51D64D15.2090105@oracle.com> <51D6A59A.1060703@oracle.com> <51D6B1ED.9090709@oracle.com> <51DAEF13.8010000@oracle.com> <51DAF69C.3000404@oracle.com> <51DC0B8C.9010804@oracle.com> Message-ID: <51DD2638.9070801@oracle.com> Ivan, I'll assume this is the latest webrev : http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ One comment - should the test be excluded for all linux variants (i.e. linux-all) ? regards, Sean. On 09/07/2013 14:09, Ivan Gerasimov wrote: > Please have a chance to review an updated webrev. > It now includes a change to ProblemList.txt, so both modified tests > are ignored for linux-x64. > > Sincerely yours, > Ivan Gersimov > > On 08.07.2013 21:27, Se?n Coffey wrote: >> >> On 08/07/13 17:55, Ivan Gerasimov wrote: >>> Thanks, Se?n! >>> >>> I located the build in which the memleak was first introduced -- it >>> is jdk8-b69 (hs25-b13). >>> I've updated the bug http://bugs.sun.com/view_bug.do?bug_id=8019845 >>> with this. >>> >>> So what is the correct procedure to go forward now? >>> Should I update the webrev to include changes to the problem list? >>> I believe I shouldn't -- this list seems to be a sensitive stuff. >> I'd suggest updating the webrev with the ProblemList >> modification/addition. It's best not to add a test to testruns if >> it's knowingly failing. The test can be removed from ProblemList when >> the jdk8 regression is fixed. >> >> regards, >> Sean. >> >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 05.07.2013 15:45, Se?n Coffey wrote: >>>> Nice work indeed Ivan. Good to have a reliable testcase to catch >>>> leaks in this area. >>>> >>>> I'd also suggest that this test goes on the ProblemList until the >>>> new leak is sorted out for jdk8. The goal of JPRT runs is to have >>>> clean runs. If it's on the problemList, then it's a known issue >>>> and is normally tagged with the relevant bug ID so that the >>>> responsible engineer knows the current state. >>>> >>>> regards, >>>> Sean. >>>> >>>> On 05/07/2013 11:53, Ivan Gerasimov wrote: >>>>> >>>>> On 05.07.2013 8:35, Daniel D. Daugherty wrote: >>>>>> Ivan, >>>>>> >>>>>> The changes look fine, I can sponsor your commit, looks like your >>>>>> OpenJDK user name is 'igerasim', but I need to know a little bit >>>>>> more about your testing of these fixes. Did you do a test JPRT >>>>>> job to run the JLI tests (or just the two tests themselves)? >>>>>> >>>>> I've only run test from java/lang/instrument when checked the >>>>> change with JDK6u60 (all passed) and with JDK6u51 (the test failed >>>>> as expected, since the leak had still been there.) >>>>> >>>>>> Based on e-mail about this bug fix, I believe you've found a new >>>>>> leak in JDK8/HSX-25 with test >>>>>> java/lang/instrument/RedefineBigClass.sh. >>>>> Right. The test shown a memleak with the the latest jdk8. >>>>> I filed a bug 8019845 about this leak. >>>>> Stefan Karlsson guessed that this may be related to 8003419 (NPG: >>>>> Clean up metadata created during class loading if failure) >>>>> Then I've checked the builds b57 (test failed) and b58 (test >>>>> passed), so I confirmed that it may be the reason of the leak >>>>> being observed now. >>>>> But now I think that the reason may be different. >>>>> It just turns out that the test shows failures for (at least) >>>>> three different leaks - the one you, Daniel, solved (7121600), the >>>>> one Stefan wrote about (8003419) and the one currently observed >>>>> (8019845). >>>>> >>>>>> That's a good thing, but I think Alan and company would be a bit >>>>>> grumpy with me if I pushed a test that failed as soon as someone >>>>>> ran it. :-) Do you know if the revised RetransformBigClass.sh also >>>>>> finds a new memory leak in JDK8/HSX-25? >>>>>> >>>>>> The way to deal with that is to put the test on the Problem.list >>>>>> as part of the same changeset. However, the T&L folks might not like >>>>>> that either... >>>>> >>>>> Well, the leak is there, and why not have a failing test as a >>>>> reminder to have it fixed? >>>>> >>>>> Sincerely yours, >>>>> Ivan Gerasimov >>>>> >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 7/4/13 6:59 PM, Ivan Gerasimov wrote: >>>>>>> Thank you, Daniel! >>>>>>> >>>>>>> Please find an updated webrev at >>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. >>>>>>> It now includes the RetransformBigClass test modified in the >>>>>>> same way as RedefineBigClass >>>>>>> If the changes look fine, may I ask you to sponsor the commit, >>>>>>> as I'm not a committer? >>>>>>> Here's a link to hg export: >>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch >>>>>>> >>>>>>> >>>>>>> Thanks in advance, >>>>>>> Ivan >>>>>>> >>>>>>> On 04.07.2013 21:45, Daniel D. Daugherty wrote: >>>>>>>> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>>>>>>>> Daniel, thank you for review! >>>>>>>>> >>>>>>>>> Here's the updated with all all your suggestions adopted. >>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >>>>>>>> >>>>>>>> Looks good. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I haven't yet considered applying the approach to >>>>>>>>> RetransformBigClass. >>>>>>>>> Do you want me to include this into this same change set or >>>>>>>>> should I make it separately? >>>>>>>> >>>>>>>> I would include it in the same changeset. >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>>>>>>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>>>>>>>> Hello everybody! >>>>>>>>>>> >>>>>>>>>>> We have a request to improve jtreg test. >>>>>>>>>>> The test had been written to verify fix for memory leak >>>>>>>>>>> during class redefinition. >>>>>>>>>>> The problem is that it always is reported as PASSED even in >>>>>>>>>>> the presence of the leak. >>>>>>>>>>> >>>>>>>>>>> The proposed change is platform specific. >>>>>>>>>>> It allows memory leak detection only on Linux. >>>>>>>>>>> This is because the memory leak was in native code, so >>>>>>>>>>> there's no easy way to detect it from within Java code. >>>>>>>>>>> >>>>>>>>>>> Here's the webrev for JDK8 repository: >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>>>>>>>> >>>>>>>>>> Very nicely done! The logic in RedefineBigClass.sh only >>>>>>>>>> catches a >>>>>>>>>> leak big enough to cause an Exception to be thrown. >>>>>>>>>> >>>>>>>>>> When I originally wrote this test and its companion: >>>>>>>>>> >>>>>>>>>> test/java/lang/instrument/RetransformBigClass* >>>>>>>>>> >>>>>>>>>> I could not come up with a platform independent way to put a >>>>>>>>>> small >>>>>>>>>> upper limit on memory growth. It never dawned on me that >>>>>>>>>> putting in >>>>>>>>>> something on one platform (Linux) was better than nothing. >>>>>>>>>> >>>>>>>>>> Are you planning to add this same logic to RetransformBigClass*? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> test/java/lang/instrument/RedefineBigClass.sh >>>>>>>>>> No comments. >>>>>>>>>> >>>>>>>>>> test/java/lang/instrument/RedefineBigClassApp.java >>>>>>>>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb >>>>>>>>>> Would be better at the top of RedefineBigClassApp >>>>>>>>>> rather than >>>>>>>>>> "buried" down here. >>>>>>>>>> >>>>>>>>>> line 51: Long.valueOf(vmMemDelta) >>>>>>>>>> There are several places where a long is passed to >>>>>>>>>> Long.valueOf(). >>>>>>>>>> Is there some reason you're not passing them directly >>>>>>>>>> to println()? >>>>>>>>>> >>>>>>>>>> line 54: } else { >>>>>>>>>> The "else" is redundant due to the "System.exit(1)" >>>>>>>>>> call above it. >>>>>>>>>> You can drop the "else {" and "}" and shift that last >>>>>>>>>> println() to >>>>>>>>>> the left. >>>>>>>>>> >>>>>>>>>> line 71: return Long.parseLong(line.split(" ")[22]) / 1024; >>>>>>>>>> How about at least a comment referring to the Linux >>>>>>>>>> proc(5) >>>>>>>>>> man page... and the fact that the 23rd field is: >>>>>>>>>> >>>>>>>>>> vsize %lu Virtual memory size in bytes. >>>>>>>>>> >>>>>>>>>> Again, very nicely done! >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The surprising thing is that modified test detected the leak >>>>>>>>>>> with the latest JDK8! >>>>>>>>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>>>>>>>> >>>>>>>>>>> I've filled a bug >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019845 "Memory leak >>>>>>>>>>> during class redefenition" (not yet available.) >>>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan Gerasimov >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > From ivan.gerasimov at oracle.com Wed Jul 10 03:38:22 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 10 Jul 2013 14:38:22 +0400 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51DD2638.9070801@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> <51D64D15.2090105@oracle.com> <51D6A59A.1060703@oracle.com> <51D6B1ED.9090709@oracle.com> <51DAEF13.8010000@oracle.com> <51DAF69C.3000404@oracle.com> <51DC0B8C.9010804@oracle.com> <51DD2638.9070801@oracle.com> Message-ID: <51DD399E.4030105@oracle.com> Yes, I forgot to include the most important thing - a link to webrev! Your link is correct. http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ The tests fail on linux-x64 only, linux-i586 is fine. Here's the link to the logs of the tests run by Daniel Daugherty: http://prt-web.us.oracle.com//archive/2013/07/2013-07-05-045326.ddaugher.8016838_exp/logs/ Thus the memory leak seems to be specific to 64-bit Linux. Sincerely yours, Ivan On 10.07.2013 13:15, Se?n Coffey wrote: > Ivan, > > I'll assume this is the latest webrev : > http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ > > > One comment - should the test be excluded for all linux variants (i.e. > linux-all) ? > > regards, > Sean. > > On 09/07/2013 14:09, Ivan Gerasimov wrote: >> Please have a chance to review an updated webrev. >> It now includes a change to ProblemList.txt, so both modified tests >> are ignored for linux-x64. >> >> Sincerely yours, >> Ivan Gersimov >> >> On 08.07.2013 21:27, Se?n Coffey wrote: >>> >>> On 08/07/13 17:55, Ivan Gerasimov wrote: >>>> Thanks, Se?n! >>>> >>>> I located the build in which the memleak was first introduced -- it >>>> is jdk8-b69 (hs25-b13). >>>> I've updated the bug http://bugs.sun.com/view_bug.do?bug_id=8019845 >>>> with this. >>>> >>>> So what is the correct procedure to go forward now? >>>> Should I update the webrev to include changes to the problem list? >>>> I believe I shouldn't -- this list seems to be a sensitive stuff. >>> I'd suggest updating the webrev with the ProblemList >>> modification/addition. It's best not to add a test to testruns if >>> it's knowingly failing. The test can be removed from ProblemList >>> when the jdk8 regression is fixed. >>> >>> regards, >>> Sean. >>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 05.07.2013 15:45, Se?n Coffey wrote: >>>>> Nice work indeed Ivan. Good to have a reliable testcase to catch >>>>> leaks in this area. >>>>> >>>>> I'd also suggest that this test goes on the ProblemList until the >>>>> new leak is sorted out for jdk8. The goal of JPRT runs is to have >>>>> clean runs. If it's on the problemList, then it's a known issue >>>>> and is normally tagged with the relevant bug ID so that the >>>>> responsible engineer knows the current state. >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>> On 05/07/2013 11:53, Ivan Gerasimov wrote: >>>>>> >>>>>> On 05.07.2013 8:35, Daniel D. Daugherty wrote: >>>>>>> Ivan, >>>>>>> >>>>>>> The changes look fine, I can sponsor your commit, looks like your >>>>>>> OpenJDK user name is 'igerasim', but I need to know a little bit >>>>>>> more about your testing of these fixes. Did you do a test JPRT >>>>>>> job to run the JLI tests (or just the two tests themselves)? >>>>>>> >>>>>> I've only run test from java/lang/instrument when checked the >>>>>> change with JDK6u60 (all passed) and with JDK6u51 (the test >>>>>> failed as expected, since the leak had still been there.) >>>>>> >>>>>>> Based on e-mail about this bug fix, I believe you've found a new >>>>>>> leak in JDK8/HSX-25 with test >>>>>>> java/lang/instrument/RedefineBigClass.sh. >>>>>> Right. The test shown a memleak with the the latest jdk8. >>>>>> I filed a bug 8019845 about this leak. >>>>>> Stefan Karlsson guessed that this may be related to 8003419 (NPG: >>>>>> Clean up metadata created during class loading if failure) >>>>>> Then I've checked the builds b57 (test failed) and b58 (test >>>>>> passed), so I confirmed that it may be the reason of the leak >>>>>> being observed now. >>>>>> But now I think that the reason may be different. >>>>>> It just turns out that the test shows failures for (at least) >>>>>> three different leaks - the one you, Daniel, solved (7121600), >>>>>> the one Stefan wrote about (8003419) and the one currently >>>>>> observed (8019845). >>>>>> >>>>>>> That's a good thing, but I think Alan and company would be a bit >>>>>>> grumpy with me if I pushed a test that failed as soon as someone >>>>>>> ran it. :-) Do you know if the revised RetransformBigClass.sh also >>>>>>> finds a new memory leak in JDK8/HSX-25? >>>>>>> >>>>>>> The way to deal with that is to put the test on the Problem.list >>>>>>> as part of the same changeset. However, the T&L folks might not >>>>>>> like >>>>>>> that either... >>>>>> >>>>>> Well, the leak is there, and why not have a failing test as a >>>>>> reminder to have it fixed? >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan Gerasimov >>>>>> >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 7/4/13 6:59 PM, Ivan Gerasimov wrote: >>>>>>>> Thank you, Daniel! >>>>>>>> >>>>>>>> Please find an updated webrev at >>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. >>>>>>>> It now includes the RetransformBigClass test modified in the >>>>>>>> same way as RedefineBigClass >>>>>>>> If the changes look fine, may I ask you to sponsor the commit, >>>>>>>> as I'm not a committer? >>>>>>>> Here's a link to hg export: >>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch >>>>>>>> >>>>>>>> >>>>>>>> Thanks in advance, >>>>>>>> Ivan >>>>>>>> >>>>>>>> On 04.07.2013 21:45, Daniel D. Daugherty wrote: >>>>>>>>> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>>>>>>>>> Daniel, thank you for review! >>>>>>>>>> >>>>>>>>>> Here's the updated with all all your suggestions adopted. >>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >>>>>>>>> >>>>>>>>> Looks good. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I haven't yet considered applying the approach to >>>>>>>>>> RetransformBigClass. >>>>>>>>>> Do you want me to include this into this same change set or >>>>>>>>>> should I make it separately? >>>>>>>>> >>>>>>>>> I would include it in the same changeset. >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>>>>>>>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>>>>>>>>> Hello everybody! >>>>>>>>>>>> >>>>>>>>>>>> We have a request to improve jtreg test. >>>>>>>>>>>> The test had been written to verify fix for memory leak >>>>>>>>>>>> during class redefinition. >>>>>>>>>>>> The problem is that it always is reported as PASSED even in >>>>>>>>>>>> the presence of the leak. >>>>>>>>>>>> >>>>>>>>>>>> The proposed change is platform specific. >>>>>>>>>>>> It allows memory leak detection only on Linux. >>>>>>>>>>>> This is because the memory leak was in native code, so >>>>>>>>>>>> there's no easy way to detect it from within Java code. >>>>>>>>>>>> >>>>>>>>>>>> Here's the webrev for JDK8 repository: >>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>>>>>>>>> >>>>>>>>>>> Very nicely done! The logic in RedefineBigClass.sh only >>>>>>>>>>> catches a >>>>>>>>>>> leak big enough to cause an Exception to be thrown. >>>>>>>>>>> >>>>>>>>>>> When I originally wrote this test and its companion: >>>>>>>>>>> >>>>>>>>>>> test/java/lang/instrument/RetransformBigClass* >>>>>>>>>>> >>>>>>>>>>> I could not come up with a platform independent way to put a >>>>>>>>>>> small >>>>>>>>>>> upper limit on memory growth. It never dawned on me that >>>>>>>>>>> putting in >>>>>>>>>>> something on one platform (Linux) was better than nothing. >>>>>>>>>>> >>>>>>>>>>> Are you planning to add this same logic to >>>>>>>>>>> RetransformBigClass*? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> test/java/lang/instrument/RedefineBigClass.sh >>>>>>>>>>> No comments. >>>>>>>>>>> >>>>>>>>>>> test/java/lang/instrument/RedefineBigClassApp.java >>>>>>>>>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb >>>>>>>>>>> Would be better at the top of RedefineBigClassApp >>>>>>>>>>> rather than >>>>>>>>>>> "buried" down here. >>>>>>>>>>> >>>>>>>>>>> line 51: Long.valueOf(vmMemDelta) >>>>>>>>>>> There are several places where a long is passed to >>>>>>>>>>> Long.valueOf(). >>>>>>>>>>> Is there some reason you're not passing them >>>>>>>>>>> directly to println()? >>>>>>>>>>> >>>>>>>>>>> line 54: } else { >>>>>>>>>>> The "else" is redundant due to the "System.exit(1)" >>>>>>>>>>> call above it. >>>>>>>>>>> You can drop the "else {" and "}" and shift that >>>>>>>>>>> last println() to >>>>>>>>>>> the left. >>>>>>>>>>> >>>>>>>>>>> line 71: return Long.parseLong(line.split(" ")[22]) / 1024; >>>>>>>>>>> How about at least a comment referring to the Linux >>>>>>>>>>> proc(5) >>>>>>>>>>> man page... and the fact that the 23rd field is: >>>>>>>>>>> >>>>>>>>>>> vsize %lu Virtual memory size in bytes. >>>>>>>>>>> >>>>>>>>>>> Again, very nicely done! >>>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The surprising thing is that modified test detected the >>>>>>>>>>>> leak with the latest JDK8! >>>>>>>>>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>>>>>>>>> >>>>>>>>>>>> I've filled a bug >>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019845 "Memory leak >>>>>>>>>>>> during class redefenition" (not yet available.) >>>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan Gerasimov >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > From sean.coffey at oracle.com Wed Jul 10 04:39:57 2013 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 10 Jul 2013 12:39:57 +0100 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51DD399E.4030105@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> <51D64D15.2090105@oracle.com> <51D6A59A.1060703@oracle.com> <51D6B1ED.9090709@oracle.com> <51DAEF13.8010000@oracle.com> <51DAF69C.3000404@oracle.com> <51DC0B8C.9010804@oracle.com> <51DD2638.9070801@oracle.com> <51DD399E.4030105@oracle.com> Message-ID: <51DD480D.8000005@oracle.com> On 10/07/13 11:38, Ivan Gerasimov wrote: > Yes, I forgot to include the most important thing - a link to webrev! > Your link is correct. > http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ > > The tests fail on linux-x64 only, linux-i586 is fine. > Here's the link to the logs of the tests run by Daniel Daugherty: > http://prt-web.us.oracle.com//archive/2013/07/2013-07-05-045326.ddaugher.8016838_exp/logs/ > > > Thus the memory leak seems to be specific to 64-bit Linux. Ok - didn't know that. Thanks. looks fine to me then, but use Dan or someone else as reviewer since I'm not one. regards, Sean. > > Sincerely yours, > Ivan > > On 10.07.2013 13:15, Se?n Coffey wrote: >> Ivan, >> >> I'll assume this is the latest webrev : >> http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ >> >> >> One comment - should the test be excluded for all linux variants >> (i.e. linux-all) ? >> >> regards, >> Sean. >> >> On 09/07/2013 14:09, Ivan Gerasimov wrote: >>> Please have a chance to review an updated webrev. >>> It now includes a change to ProblemList.txt, so both modified tests >>> are ignored for linux-x64. >>> >>> Sincerely yours, >>> Ivan Gersimov >>> >>> On 08.07.2013 21:27, Se?n Coffey wrote: >>>> >>>> On 08/07/13 17:55, Ivan Gerasimov wrote: >>>>> Thanks, Se?n! >>>>> >>>>> I located the build in which the memleak was first introduced -- >>>>> it is jdk8-b69 (hs25-b13). >>>>> I've updated the bug >>>>> http://bugs.sun.com/view_bug.do?bug_id=8019845 with this. >>>>> >>>>> So what is the correct procedure to go forward now? >>>>> Should I update the webrev to include changes to the problem list? >>>>> I believe I shouldn't -- this list seems to be a sensitive stuff. >>>> I'd suggest updating the webrev with the ProblemList >>>> modification/addition. It's best not to add a test to testruns if >>>> it's knowingly failing. The test can be removed from ProblemList >>>> when the jdk8 regression is fixed. >>>> >>>> regards, >>>> Sean. >>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>> On 05.07.2013 15:45, Se?n Coffey wrote: >>>>>> Nice work indeed Ivan. Good to have a reliable testcase to catch >>>>>> leaks in this area. >>>>>> >>>>>> I'd also suggest that this test goes on the ProblemList until the >>>>>> new leak is sorted out for jdk8. The goal of JPRT runs is to have >>>>>> clean runs. If it's on the problemList, then it's a known issue >>>>>> and is normally tagged with the relevant bug ID so that the >>>>>> responsible engineer knows the current state. >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>> On 05/07/2013 11:53, Ivan Gerasimov wrote: >>>>>>> >>>>>>> On 05.07.2013 8:35, Daniel D. Daugherty wrote: >>>>>>>> Ivan, >>>>>>>> >>>>>>>> The changes look fine, I can sponsor your commit, looks like your >>>>>>>> OpenJDK user name is 'igerasim', but I need to know a little bit >>>>>>>> more about your testing of these fixes. Did you do a test JPRT >>>>>>>> job to run the JLI tests (or just the two tests themselves)? >>>>>>>> >>>>>>> I've only run test from java/lang/instrument when checked the >>>>>>> change with JDK6u60 (all passed) and with JDK6u51 (the test >>>>>>> failed as expected, since the leak had still been there.) >>>>>>> >>>>>>>> Based on e-mail about this bug fix, I believe you've found a new >>>>>>>> leak in JDK8/HSX-25 with test >>>>>>>> java/lang/instrument/RedefineBigClass.sh. >>>>>>> Right. The test shown a memleak with the the latest jdk8. >>>>>>> I filed a bug 8019845 about this leak. >>>>>>> Stefan Karlsson guessed that this may be related to 8003419 >>>>>>> (NPG: Clean up metadata created during class loading if failure) >>>>>>> Then I've checked the builds b57 (test failed) and b58 (test >>>>>>> passed), so I confirmed that it may be the reason of the leak >>>>>>> being observed now. >>>>>>> But now I think that the reason may be different. >>>>>>> It just turns out that the test shows failures for (at least) >>>>>>> three different leaks - the one you, Daniel, solved (7121600), >>>>>>> the one Stefan wrote about (8003419) and the one currently >>>>>>> observed (8019845). >>>>>>> >>>>>>>> That's a good thing, but I think Alan and company would be a bit >>>>>>>> grumpy with me if I pushed a test that failed as soon as someone >>>>>>>> ran it. :-) Do you know if the revised RetransformBigClass.sh also >>>>>>>> finds a new memory leak in JDK8/HSX-25? >>>>>>>> >>>>>>>> The way to deal with that is to put the test on the Problem.list >>>>>>>> as part of the same changeset. However, the T&L folks might not >>>>>>>> like >>>>>>>> that either... >>>>>>> >>>>>>> Well, the leak is there, and why not have a failing test as a >>>>>>> reminder to have it fixed? >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan Gerasimov >>>>>>> >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> On 7/4/13 6:59 PM, Ivan Gerasimov wrote: >>>>>>>>> Thank you, Daniel! >>>>>>>>> >>>>>>>>> Please find an updated webrev at >>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. >>>>>>>>> It now includes the RetransformBigClass test modified in the >>>>>>>>> same way as RedefineBigClass >>>>>>>>> If the changes look fine, may I ask you to sponsor the commit, >>>>>>>>> as I'm not a committer? >>>>>>>>> Here's a link to hg export: >>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks in advance, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> On 04.07.2013 21:45, Daniel D. Daugherty wrote: >>>>>>>>>> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>>>>>>>>>> Daniel, thank you for review! >>>>>>>>>>> >>>>>>>>>>> Here's the updated with all all your suggestions adopted. >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >>>>>>>>>> >>>>>>>>>> Looks good. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I haven't yet considered applying the approach to >>>>>>>>>>> RetransformBigClass. >>>>>>>>>>> Do you want me to include this into this same change set or >>>>>>>>>>> should I make it separately? >>>>>>>>>> >>>>>>>>>> I would include it in the same changeset. >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>>>>>>>>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>> >>>>>>>>>>>>> We have a request to improve jtreg test. >>>>>>>>>>>>> The test had been written to verify fix for memory leak >>>>>>>>>>>>> during class redefinition. >>>>>>>>>>>>> The problem is that it always is reported as PASSED even >>>>>>>>>>>>> in the presence of the leak. >>>>>>>>>>>>> >>>>>>>>>>>>> The proposed change is platform specific. >>>>>>>>>>>>> It allows memory leak detection only on Linux. >>>>>>>>>>>>> This is because the memory leak was in native code, so >>>>>>>>>>>>> there's no easy way to detect it from within Java code. >>>>>>>>>>>>> >>>>>>>>>>>>> Here's the webrev for JDK8 repository: >>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Very nicely done! The logic in RedefineBigClass.sh only >>>>>>>>>>>> catches a >>>>>>>>>>>> leak big enough to cause an Exception to be thrown. >>>>>>>>>>>> >>>>>>>>>>>> When I originally wrote this test and its companion: >>>>>>>>>>>> >>>>>>>>>>>> test/java/lang/instrument/RetransformBigClass* >>>>>>>>>>>> >>>>>>>>>>>> I could not come up with a platform independent way to put >>>>>>>>>>>> a small >>>>>>>>>>>> upper limit on memory growth. It never dawned on me that >>>>>>>>>>>> putting in >>>>>>>>>>>> something on one platform (Linux) was better than nothing. >>>>>>>>>>>> >>>>>>>>>>>> Are you planning to add this same logic to >>>>>>>>>>>> RetransformBigClass*? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> test/java/lang/instrument/RedefineBigClass.sh >>>>>>>>>>>> No comments. >>>>>>>>>>>> >>>>>>>>>>>> test/java/lang/instrument/RedefineBigClassApp.java >>>>>>>>>>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // >>>>>>>>>>>> 32Mb >>>>>>>>>>>> Would be better at the top of RedefineBigClassApp >>>>>>>>>>>> rather than >>>>>>>>>>>> "buried" down here. >>>>>>>>>>>> >>>>>>>>>>>> line 51: Long.valueOf(vmMemDelta) >>>>>>>>>>>> There are several places where a long is passed to >>>>>>>>>>>> Long.valueOf(). >>>>>>>>>>>> Is there some reason you're not passing them >>>>>>>>>>>> directly to println()? >>>>>>>>>>>> >>>>>>>>>>>> line 54: } else { >>>>>>>>>>>> The "else" is redundant due to the "System.exit(1)" >>>>>>>>>>>> call above it. >>>>>>>>>>>> You can drop the "else {" and "}" and shift that >>>>>>>>>>>> last println() to >>>>>>>>>>>> the left. >>>>>>>>>>>> >>>>>>>>>>>> line 71: return Long.parseLong(line.split(" ")[22]) / >>>>>>>>>>>> 1024; >>>>>>>>>>>> How about at least a comment referring to the Linux >>>>>>>>>>>> proc(5) >>>>>>>>>>>> man page... and the fact that the 23rd field is: >>>>>>>>>>>> >>>>>>>>>>>> vsize %lu Virtual memory size in bytes. >>>>>>>>>>>> >>>>>>>>>>>> Again, very nicely done! >>>>>>>>>>>> >>>>>>>>>>>> Dan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The surprising thing is that modified test detected the >>>>>>>>>>>>> leak with the latest JDK8! >>>>>>>>>>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>>>>>>>>>> >>>>>>>>>>>>> I've filled a bug >>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019845 "Memory >>>>>>>>>>>>> leak during class redefenition" (not yet available.) >>>>>>>>>>>>> >>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>> Ivan Gerasimov >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > From rickard.backman at oracle.com Wed Jul 10 04:59:54 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 10 Jul 2013 13:59:54 +0200 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: <0D743CDF-C8AB-421C-8D20-C29F08104642@oracle.com> References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> <0D743CDF-C8AB-421C-8D20-C29F08104642@oracle.com> Message-ID: <9DA4C2B3-4923-4C02-AED8-62E3AE0CB502@oracle.com> Still looking for a Reviewer. Thanks /R On Jul 8, 2013, at 5:49 PM, Rickard B?ckman wrote: > Thanks Markus! > > /R > > On Jul 8, 2013, at 5:45 PM, Markus Gr?nlund wrote: > >> Rickard, >> >> I think it looks good (not a Reviewer). >> >> Cheers >> Markus >> >> -----Original Message----- >> From: Rickard B?ckman >> Sent: den 4 juli 2013 11:30 >> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >> Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' >> >> Hi, >> >> can I please have a couple of reviews for this change? >> >> The problem in this crash was that we were given an incorrect fp (in this case 0x0) and had a pc that matched the C -> Java entry frame. The code then dereferenced fp +- offset. >> >> This change verifies that the fp +- offset is actually on the stack of the thread before doing the derefencing. >> >> Webrev: http://cr.openjdk.java.net/~rbackman/8016131/ >> >> Thanks >> /R > From shanliang.jiang at oracle.com Wed Jul 10 09:48:34 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 10 Jul 2013 18:48:34 +0200 Subject: RFR: 8019826 Test com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java fails with NPE In-Reply-To: <51DD251C.5050009@oracle.com> References: <51DD251C.5050009@oracle.com> Message-ID: <51DD9062.8020602@oracle.com> It looks fine to me. Shanliang Jaroslav Bachorik wrote: > Please, review this simple fix. > > http://cr.openjdk.java.net/~jbachorik/8019826/webrev.00 > > Firstly, the patch removes a conditional early exit which checks for a > build 52 of an unspecified major JVM version - it is not needed any > more. Basically, the condition just made the test a noop till the latest > hotspot version. > > The second fix is correctly setting the "mbean" attribute - it was not > properly initialized and because of this the test was going to fail with > NPE. > > Thanks, > > -JB- > From frederic.parain at oracle.com Wed Jul 10 10:51:14 2013 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 10 Jul 2013 17:51:14 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7143807: ResourceMark nesting problem in stringStream Message-ID: <20130710175118.D8BCD48963@hg.openjdk.java.net> Changeset: dbc0b5dc08f5 Author: fparain Date: 2013-07-10 15:49 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dbc0b5dc08f5 7143807: ResourceMark nesting problem in stringStream Reviewed-by: kvn, dcubed ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp From joe.darcy at oracle.com Wed Jul 10 11:05:56 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 10 Jul 2013 18:05:56 +0000 Subject: hg: jdk8/tl/jdk: 8020294: Fix doclint issues in java.util.Spliterator Message-ID: <20130710180609.DF00048965@hg.openjdk.java.net> Changeset: 7c44ea602cc8 Author: darcy Date: 2013-07-10 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c44ea602cc8 8020294: Fix doclint issues in java.util.Spliterator Reviewed-by: psandoz ! src/share/classes/java/util/Spliterator.java From rob.mckenna at oracle.com Wed Jul 10 11:54:22 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Wed, 10 Jul 2013 18:54:22 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130710185506.7F13C4896A@hg.openjdk.java.net> Changeset: 607fa1ff3de2 Author: bpb Date: 2013-07-09 11:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/607fa1ff3de2 6178739: (fmt) Formatter.format("%0.4f\n", 56789.456789) generates MissingFormatWidthException Summary: Change the field width specification to require a positive value. The exception is still thrown but that is now explicitly consistent with the specification. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/Formatter.java Changeset: 2ee772cda1d6 Author: bpb Date: 2013-07-09 12:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ee772cda1d6 6480539: BigDecimal.stripTrailingZeros() has no effect on zero itself ("0.0") Summary: Make stripTrailingZeros() return BigDecimal.ZERO if the BigDecimal is numerically equal to zero. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/math/BigDecimal.java ! test/java/math/BigDecimal/StrippingZerosTest.java From bill.pittore at oracle.com Wed Jul 10 12:29:54 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 10 Jul 2013 15:29:54 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: References: <51D494E9.2020200@oracle.com> Message-ID: <51DDB632.4050805@oracle.com> On 7/3/2013 6:32 PM, Jeremy Manson wrote: > I know that this is mentioned in the JEP, but does it really make > sense to have -agentpath work here, rather than just -agentlib? I > would think that specifying a full pathname and getting the library > loaded out of the launcher would be a little surprising to people who > are basically saying "please load this agent from the given path". > > Also, in practice, we do something very similar at Google, and, when > testing, I find it occasionally useful to be able to say "please load > this agent on the command line via the agentpath I gave you, rather > than loading the one with the same name I baked into the launcher". > > (FWIW, when we did this internally at Google, we added a special -XX > flag for when the agent is in the launcher. I know that you don't > want to go that way, though.) > Thanks for the comments. I would say the thinking here is that we want this to be as transparent as possible to the end user. In our view of the end user is someone perhaps using an IDE and the actual execution of the VM with agent arguments is hidden. In your case it sounds like you are actually developing agents which is a whole different ball game. I could certainly see adding a -XX argument that forces agentpath to load the external library which would be good for agent development and debugging. No need to relink the entire VM with the new agent. Our tech lead is out on vacation this week so I'll bring this up when he's back. bill > > On Wed, Jul 3, 2013 at 2:17 PM, BILL PITTORE > wrote: > > These changes address bug 8014135 which adds support for > statically linked agents in the VM. This is a followup to the > recent JNI spec changes that addressed statically linked JNI > libraries( 8005716). > The JEP for this change is the same JEP as the JNI changes: > http://openjdk.java.net/jeps/178 > > Webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ > > > The changes to jvmti.xml can also be seen in the output file that > I placed here: > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html > > > Thanks, > bill > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130710/fa24867e/attachment.html From joe.darcy at oracle.com Wed Jul 10 14:20:34 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 10 Jul 2013 21:20:34 +0000 Subject: hg: jdk8/tl/jdk: 8020308: Fix doclint issues in java.lang.management Message-ID: <20130710212057.488B34897A@hg.openjdk.java.net> Changeset: 69d9fe8175a0 Author: sspitsyn Date: 2013-07-10 14:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/69d9fe8175a0 8020308: Fix doclint issues in java.lang.management Reviewed-by: darcy Contributed-by: serguei.spitsyn at oracle.com ! src/share/classes/java/lang/management/LockInfo.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/MemoryMXBean.java ! src/share/classes/java/lang/management/MemoryNotificationInfo.java ! src/share/classes/java/lang/management/MemoryPoolMXBean.java ! src/share/classes/java/lang/management/MemoryUsage.java ! src/share/classes/java/lang/management/MonitorInfo.java ! src/share/classes/java/lang/management/RuntimeMXBean.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/ThreadMXBean.java From mandy.chung at oracle.com Wed Jul 10 17:52:28 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 11 Jul 2013 08:52:28 +0800 Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management Interfaces being public In-Reply-To: <51DD1C4D.2060601@oracle.com> References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com> <51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com> <51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com> <51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com> <51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com> <51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com> <51AF9A56.4090709@oracle.com> <51B0A937.90607@oracle.com> <51B0AAB7.7070802@oracle.com> <51B0B39C.1050305@oracle.com> <51B18803.7060406@oracle.com> <51B1A2E2.5030001@oracle.com> <51C03013.2020700@oracle.com> <51C0359F.8090201@oracle.com> <51C036AF.1030206@oracle.com> <51C0440B.9030601@oracle.com> <51DBDFC8.4090800@oracle.com> <51DC67B3.8060103@oracle.com> <51DD1C4D.2060601@oracle.com> Message-ID: <51DE01CC.7060402@oracle.com> On 7/10/2013 4:33 PM, Jaroslav Bachorik wrote: >> >The change looks reasonable. In the class spec for MXBean, suggest to >> >rename >> > >> > interface ThisIsNotMXBean{} >> > >> >to something more explicit >> > >> > interface NonPublicInterfaceNotMXBean{} > Since this was a part of the CCC review which was approved I am not sure > if I am allowed to change the class spec. If it is allowed I have no > objections against the proposal and will change the interface name. That is an example interface name and is non-normative (unless you see it differently). This can be revised. thanks Mandy From jason.uh at oracle.com Wed Jul 10 18:01:55 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Thu, 11 Jul 2013 01:01:55 +0000 Subject: hg: jdk8/tl/jdk: 8020318: Fix doclint issues in java.net Message-ID: <20130711010218.031D448981@hg.openjdk.java.net> Changeset: 702556f7977e Author: juh Date: 2013-07-10 18:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/702556f7977e 8020318: Fix doclint issues in java.net Reviewed-by: darcy, khazra ! src/share/classes/java/net/CookieStore.java ! src/share/classes/java/net/HttpURLPermission.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/ProtocolFamily.java ! src/share/classes/java/net/SocketOption.java ! src/share/classes/java/net/URI.java From david.holmes at oracle.com Wed Jul 10 22:23:36 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jul 2013 15:23:36 +1000 Subject: RFR: 8019826 Test com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java fails with NPE In-Reply-To: <51DD251C.5050009@oracle.com> References: <51DD251C.5050009@oracle.com> Message-ID: <51DE4158.7080503@oracle.com> On 10/07/2013 7:10 PM, Jaroslav Bachorik wrote: > Please, review this simple fix. > > http://cr.openjdk.java.net/~jbachorik/8019826/webrev.00 > > Firstly, the patch removes a conditional early exit which checks for a > build 52 of an unspecified major JVM version - it is not needed any > more. Basically, the condition just made the test a noop till the latest > hotspot version. > > The second fix is correctly setting the "mbean" attribute - it was not > properly initialized and because of this the test was going to fail with > NPE. Looks fine to me. David ----- > Thanks, > > -JB- > From mandy.chung at oracle.com Wed Jul 10 22:49:32 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 11 Jul 2013 13:49:32 +0800 Subject: RFR: 8019826 Test com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java fails with NPE In-Reply-To: <51DD251C.5050009@oracle.com> References: <51DD251C.5050009@oracle.com> Message-ID: <0B1D8082-0D31-4C40-80DB-2D9D2453F0B3@oracle.com> Looks good. Mandy On Jul 10, 2013, at 5:10 PM, Jaroslav Bachorik wrote: > Please, review this simple fix. > > http://cr.openjdk.java.net/~jbachorik/8019826/webrev.00 > > Firstly, the patch removes a conditional early exit which checks for a > build 52 of an unspecified major JVM version - it is not needed any > more. Basically, the condition just made the test a noop till the latest > hotspot version. > > The second fix is correctly setting the "mbean" attribute - it was not > properly initialized and because of this the test was going to fail with > NPE. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Thu Jul 11 01:31:18 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Thu, 11 Jul 2013 08:31:18 +0000 Subject: hg: jdk8/tl/jdk: 8019826: Test com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java fails with NPE Message-ID: <20130711083140.7F3214898B@hg.openjdk.java.net> Changeset: a46982a212e0 Author: jbachorik Date: 2013-07-11 09:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a46982a212e0 8019826: Test com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java fails with NPE Reviewed-by: sjiang, dholmes, mchung ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java From paul.sandoz at oracle.com Thu Jul 11 04:20:31 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 11 Jul 2013 11:20:31 +0000 Subject: hg: jdk8/tl/jdk: 8019484: Sync j.u.c.ConcurrentHashMap from 166 to tl Message-ID: <20130711112056.05A2248993@hg.openjdk.java.net> Changeset: 05b164788aab Author: psandoz Date: 2013-07-11 13:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/05b164788aab 8019484: Sync j.u.c.ConcurrentHashMap from 166 to tl Reviewed-by: martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java From jaroslav.bachorik at oracle.com Thu Jul 11 04:48:02 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 11 Jul 2013 13:48:02 +0200 Subject: RFR: 8019584 javax/management/remote/mandatory/loading/MissingClassTest.java failed in nightly against jdk7u45: java.io.InvalidObjectException: Invalid notification: null Message-ID: <51DE9B72.5030308@oracle.com> Please, review the change. http://cr.openjdk.java.net/~jbachorik/8019584/webrev.00/ The combination of the fix for JDK-8014085 and ObjectInputStream.readFields() not throwing CNFE when trying to deserialize an object graph containing references to non-available classes makes an InvalidObjectException being thrown instead of the CNFE when processing JMX notifications. The patch makes the ClientNotificationForwarder ready for InvalidObjectException - it will correctly report lost notifications but will not cause the notification processing loop to fail with unhandled exception. Thanks, -JB- From sundararajan.athijegannathan at oracle.com Thu Jul 11 06:21:13 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 11 Jul 2013 13:21:13 +0000 Subject: hg: jdk8/tl/jdk: 7187144: JavaDoc for ScriptEngineFactory.getProgram() contains an error Message-ID: <20130711132141.246B8489A8@hg.openjdk.java.net> Changeset: dadcfd84d33f Author: sundar Date: 2013-07-11 18:50 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dadcfd84d33f 7187144: JavaDoc for ScriptEngineFactory.getProgram() contains an error Reviewed-by: mcimadamore, jlaskey, hannesw, attila ! src/share/classes/javax/script/ScriptEngineFactory.java From peter.allwin at oracle.com Thu Jul 11 07:14:04 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Thu, 11 Jul 2013 16:14:04 +0200 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DC4481.3000700@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> <51DB4950.7080504@oracle.com> <51DB4A8A.7010205@oracle.com> <013d01ce7c9f$6d1f86b0$475e9410$@oracle.com> <51DC06A2.7040107@oracle.com> <01cf01ce7cb8$98058b90$c810a2b0$@oracle.com> <51DC4481.3000700@oracle.com> Message-ID: <036901ce7e40$e79436a0$b6bca3e0$@oracle.com> Hello, Thank you everyone for the feedback, I've incorporated the recommendations into a new revision: http://cr.openjdk.java.net/~allwin/7162400/webrev.02/ Changes: - Fixed speling misteaks - Added jtreg regression test using Mikael's excellent suggestion of -XX:+PauseAtStartup, tested locally on linux and solaris. - Reverted use of MAX_PATH+1 vs. UNIX_MAX_PATH Also thanks to Christian T?rnqvist for helping out with the jtreg test! /peter > -----Original Message----- > From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > Sent: Tuesday, July 9, 2013 7:13 PM > To: Peter Allwin > Cc: serviceability-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file number > during HotSpotVirtualMachine.executeCommand > > On 07/09/2013 05:25 PM, Peter Allwin wrote: > > Mikael, > > > > That's a good point, unfortunately attach uses os::get_temp_directory > > which is hardcoded to use /tmp. We could add a whitebox API to allow > > us to override this but now we're on the border to noreg-hard land again > IMO. > > > > Any other opinions on this? > > Can you use the "-XX:+PauseAtStartup" vm flag it will create a > vm.paused. file in the current work directory. You could extract the pid, > touch the correct attach file in /tmp and then remove the vm.paused to let > the VM resume. > > I didn't check if PauseAtStartup stops the VM early enough though. > > An alternate, even more hacky approach is to do something like (in bash): > (bash -c 'echo $$; touch /tmp/.java_pid$$; exec java -version') Where you > can extract the pid of the subshell process with $$ and then exec into the > java launcher and keep the same pid (at least on Linux, unsure about the > Solaris launcher). > > /Mikael > > > > > > > Thanks! > > > > /peter > > > >> -----Original Message----- > >> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > >> Sent: Tuesday, July 9, 2013 2:49 PM > >> To: Peter Allwin > >> Cc: serguei.spitsyn at oracle.com; daniel.daugherty at oracle.com; > >> serviceability-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file > > number > >> during HotSpotVirtualMachine.executeCommand > >> > >> Peter, > >> > >> On 2013-07-09 14:25, Peter Allwin wrote: > >>> Hello! > >>> > >>> It is reproducible by letting the test create .java_pid* files for > >>> all possible process id's on the system, setting correct access > >>> flags, launching the target VM and attempting to connect. There are > >>> some caveats though but it should be doable. > >>> > >>> I'll convert the repro script to JTREG and add it to the webrev. > >> > >> It's probably not a good idea to have a test which taints the system > >> with > > stale > >> .java_pid* files. > >> If the test execution times out and the script isn't allowed to clean > >> up I imagine that other subsequent executions could fail. > >> Is there a way to tell the attach api to use a specific directory so > >> you > > won't > >> need to taint /tmp? > >> > >> /Mikael > >> > >>> > >>> Thanks for the reviews! > >>> > >>> /peter > >>> > >>> *From:*serguei.spitsyn at oracle.com > >>> [mailto:serguei.spitsyn at oracle.com] > >>> *Sent:* Tuesday, July 9, 2013 1:26 AM > >>> *To:* daniel.daugherty at oracle.com > >>> *Cc:* Peter Allwin; serviceability-dev at openjdk.java.net; > >>> hotspot-runtime-dev at openjdk.java.net > >>> *Subject:* Re: RFR 7162400: Intermittent java.io.IOException: Bad > >>> file number during HotSpotVirtualMachine.executeCommand > >>> > >>> Ok, thanks! > >>> > >>> Peter, did you manage to reproduce this issue with your script? > >>> If so, then, please, include it into the bug report and remove the > >>> "noreg-sqe" label. > >>> > >>> It is Ok if you did not reproduce it, though. > >>> > >>> Thanks, > >>> Serguei > >>> > >>> > >>> On 7/8/13 4:20 PM, Daniel D. Daugherty wrote: > >>> > >>> I definitely don't insist... :-) > >>> > >>> BTW, I noticed this in Peter's e-mail: > >>> > >>> > Testing: > >>> > JPRT, reproducing script on Solaris, Linux. > >>> > >>> so maybe Peter already has this covered with "reproducing script"... > >>> > >>> Dan > >>> > >>> On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com > >>> wrote: > >>> > >>> Dan, > >>> > >>> Dan, thank you for the recommendation. > >>> But I'm still not sure it is a right thing to do. > >>> Even though, there are multiple test cases associated with this > >>> bug they > >>> can not be used to verify that fix because an additional > > condition > >>> must be present as well. > >>> This condition is a presence of stale door file which is not > >>> that easy to reproduce. > >>> > >>> However, if you insist then I can change the lable to the > >>> "noreg-sqe" > >>> with the corresponding comment. > >>> > >>> Thanks, > >>> Serguei > >>> > >>> > >>> On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: > >>> > >>> Serguei, > >>> > >>> There are a number of existing tests associated with this > >>> bug. I don't > >>> think that 'noreg-hard' is the right label. I think > >>> 'noreg-sqe' is > >>> the right one: > >>> > >>> noreg-sqe > >>> Change can be verified by running an existing SQE test > >>> suite; the bug > >>> should identify the suite and the specific test > > case(s). > >>> > >>> Dan > >>> > >>> On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com > >>> wrote: > >>> > >>> Peter, > >>> > >>> I've added the label "noreg-hard" with the comment to > >>> the report. > >>> It is not easy to reproduce the issue and demonstrate > >>> the fix in a regression test. > >>> > >>> Thanks, > >>> Serguei > >>> > >>> > >>> On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com > >>> wrote: > >>> > >>> Hi Peter, > >>> > >>> The fix looks good. > >>> > >>> Thanks, > >>> Serguei > >>> > >>> On 7/8/13 6:54 AM, Peter Allwin wrote: > >>> > >>> Hello! > >>> > >>> Looking for reviews of this change: > >>> > >>> > > http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ > >>> > >>> > >>> > >>> For CR: > >>> > >>> > >>> http://bugs.sun.com/view_bug.do?bug_id=7162400 > >>> > >>> > >>> https://jbs.oracle.com/bugs/browse/JDK-7162400 > >>> > >>> Summary: > >>> > >>> This change addresses an issue in the Attach API > >>> on Solaris, Linux and BSD where an attaching > >>> application can receive IOExceptions such as > >>> "Bad file number" (Solaris), "Connection > >>> refused" (Linux/BSD), or "well-known file is not > >>> secure". > >>> > >>> The attach process uses a file in the temporary > >>> directory as a door (Solaris) or domain socket > >>> (Linux,BSD) to communicate with the VM. In > >>> certain circumstances stale files can be left in > >>> the file system which can cause the attaching > >>> application to believe that the VM is ready to > >>> receive a connection when it's not. With this > >>> change the stale file will be removed during VM > >>> startup. > >>> > >>> Note that there is still an issue if we don't > >>> have permission to remove the stale file, the > >>> attaching process will fail to connect. > >>> > >>> Testing: > >>> > >>> JPRT, reproducing script on Solaris, Linux. > >>> > >>> Credits: > >>> > >>> Thanks to Staffan Larsen who worked on this > >>> issue with me. > >>> > >>> Regards, > >>> > >>> > >>> Peter > >>> > > From maurizio.cimadamore at oracle.com Thu Jul 11 07:37:38 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 11 Jul 2013 14:37:38 +0000 Subject: hg: jdk8/tl/langtools: 8013404: Unclear spec for target typing with conditional operator (?:) Message-ID: <20130711143747.6555B489AC@hg.openjdk.java.net> Changeset: 87a951c88a33 Author: mcimadamore Date: 2013-07-11 15:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/87a951c88a33 8013404: Unclear spec for target typing with conditional operator (?:) Summary: Fix previously ignored test Reviewed-by: jjg, vromero ! test/tools/javac/lambda/TargetType36.java + test/tools/javac/lambda/TargetType36.out From christian.tornqvist at oracle.com Thu Jul 11 08:15:40 2013 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 11 Jul 2013 11:15:40 -0400 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <036901ce7e40$e79436a0$b6bca3e0$@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> <51DB4950.7080504@oracle.com> <51DB4A8A.7010205@oracle.com> <013d01ce7c9f$6d1f86b0$475e9410$@oracle.com> <51DC06A2.7040107@oracle.com> <01cf01ce7cb8$98058b90$c810a2b0$@oracle.com> <51DC4481.3000700@oracle.com> <036901ce7e40$e79436a0$b6bca3e0$@oracle.com> Message-ID: <004c01ce7e49$81bb6f20$85324d60$@oracle.com> Looks good, thanks for taking the time to write a test for this! Thanks, Christian -----Original Message----- From: hotspot-runtime-dev-bounces at openjdk.java.net [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Peter Allwin Sent: den 11 juli 2013 10:14 To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RE: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Hello, Thank you everyone for the feedback, I've incorporated the recommendations into a new revision: http://cr.openjdk.java.net/~allwin/7162400/webrev.02/ Changes: - Fixed speling misteaks - Added jtreg regression test using Mikael's excellent suggestion of -XX:+PauseAtStartup, tested locally on linux and solaris. - Reverted use of MAX_PATH+1 vs. UNIX_MAX_PATH Also thanks to Christian T?rnqvist for helping out with the jtreg test! /peter > -----Original Message----- > From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > Sent: Tuesday, July 9, 2013 7:13 PM > To: Peter Allwin > Cc: serviceability-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file number > during HotSpotVirtualMachine.executeCommand > > On 07/09/2013 05:25 PM, Peter Allwin wrote: > > Mikael, > > > > That's a good point, unfortunately attach uses > > os::get_temp_directory which is hardcoded to use /tmp. We could add > > a whitebox API to allow us to override this but now we're on the > > border to noreg-hard land again > IMO. > > > > Any other opinions on this? > > Can you use the "-XX:+PauseAtStartup" vm flag it will create a > vm.paused. file in the current work directory. You could extract > the pid, > touch the correct attach file in /tmp and then remove the vm.paused to > let the VM resume. > > I didn't check if PauseAtStartup stops the VM early enough though. > > An alternate, even more hacky approach is to do something like (in bash): > (bash -c 'echo $$; touch /tmp/.java_pid$$; exec java -version') Where > you can extract the pid of the subshell process with $$ and then exec > into the java launcher and keep the same pid (at least on Linux, > unsure about the Solaris launcher). > > /Mikael > > > > > > > Thanks! > > > > /peter > > > >> -----Original Message----- > >> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > >> Sent: Tuesday, July 9, 2013 2:49 PM > >> To: Peter Allwin > >> Cc: serguei.spitsyn at oracle.com; daniel.daugherty at oracle.com; > >> serviceability-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad > >> file > > number > >> during HotSpotVirtualMachine.executeCommand > >> > >> Peter, > >> > >> On 2013-07-09 14:25, Peter Allwin wrote: > >>> Hello! > >>> > >>> It is reproducible by letting the test create .java_pid* files for > >>> all possible process id's on the system, setting correct access > >>> flags, launching the target VM and attempting to connect. There > >>> are some caveats though but it should be doable. > >>> > >>> I'll convert the repro script to JTREG and add it to the webrev. > >> > >> It's probably not a good idea to have a test which taints the > >> system with > > stale > >> .java_pid* files. > >> If the test execution times out and the script isn't allowed to > >> clean up I imagine that other subsequent executions could fail. > >> Is there a way to tell the attach api to use a specific directory > >> so you > > won't > >> need to taint /tmp? > >> > >> /Mikael > >> > >>> > >>> Thanks for the reviews! > >>> > >>> /peter > >>> > >>> *From:*serguei.spitsyn at oracle.com > >>> [mailto:serguei.spitsyn at oracle.com] > >>> *Sent:* Tuesday, July 9, 2013 1:26 AM > >>> *To:* daniel.daugherty at oracle.com > >>> *Cc:* Peter Allwin; serviceability-dev at openjdk.java.net; > >>> hotspot-runtime-dev at openjdk.java.net > >>> *Subject:* Re: RFR 7162400: Intermittent java.io.IOException: Bad > >>> file number during HotSpotVirtualMachine.executeCommand > >>> > >>> Ok, thanks! > >>> > >>> Peter, did you manage to reproduce this issue with your script? > >>> If so, then, please, include it into the bug report and remove the > >>> "noreg-sqe" label. > >>> > >>> It is Ok if you did not reproduce it, though. > >>> > >>> Thanks, > >>> Serguei > >>> > >>> > >>> On 7/8/13 4:20 PM, Daniel D. Daugherty wrote: > >>> > >>> I definitely don't insist... :-) > >>> > >>> BTW, I noticed this in Peter's e-mail: > >>> > >>> > Testing: > >>> > JPRT, reproducing script on Solaris, Linux. > >>> > >>> so maybe Peter already has this covered with "reproducing script"... > >>> > >>> Dan > >>> > >>> On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com > >>> wrote: > >>> > >>> Dan, > >>> > >>> Dan, thank you for the recommendation. > >>> But I'm still not sure it is a right thing to do. > >>> Even though, there are multiple test cases associated > >>> with this > >>> bug they > >>> can not be used to verify that fix because an additional > > condition > >>> must be present as well. > >>> This condition is a presence of stale door file which is not > >>> that easy to reproduce. > >>> > >>> However, if you insist then I can change the lable to the > >>> "noreg-sqe" > >>> with the corresponding comment. > >>> > >>> Thanks, > >>> Serguei > >>> > >>> > >>> On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: > >>> > >>> Serguei, > >>> > >>> There are a number of existing tests associated with this > >>> bug. I don't > >>> think that 'noreg-hard' is the right label. I think > >>> 'noreg-sqe' is > >>> the right one: > >>> > >>> noreg-sqe > >>> Change can be verified by running an existing > >>> SQE test > >>> suite; the bug > >>> should identify the suite and the specific test > > case(s). > >>> > >>> Dan > >>> > >>> On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com > >>> wrote: > >>> > >>> Peter, > >>> > >>> I've added the label "noreg-hard" with the comment to > >>> the report. > >>> It is not easy to reproduce the issue and demonstrate > >>> the fix in a regression test. > >>> > >>> Thanks, > >>> Serguei > >>> > >>> > >>> On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com > >>> wrote: > >>> > >>> Hi Peter, > >>> > >>> The fix looks good. > >>> > >>> Thanks, > >>> Serguei > >>> > >>> On 7/8/13 6:54 AM, Peter Allwin wrote: > >>> > >>> Hello! > >>> > >>> Looking for reviews of this change: > >>> > >>> > > http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ > >>> > >>> > >>> > >>> For CR: > >>> > >>> > >>> http://bugs.sun.com/view_bug.do?bug_id=7162400 > >>> > >>> > >>> https://jbs.oracle.com/bugs/browse/JDK-7162400 > >>> > >>> Summary: > >>> > >>> This change addresses an issue in the > >>> Attach API > >>> on Solaris, Linux and BSD where an attaching > >>> application can receive IOExceptions such as > >>> "Bad file number" (Solaris), "Connection > >>> refused" (Linux/BSD), or "well-known file > >>> is not > >>> secure". > >>> > >>> The attach process uses a file in the temporary > >>> directory as a door (Solaris) or domain socket > >>> (Linux,BSD) to communicate with the VM. In > >>> certain circumstances stale files can be > >>> left in > >>> the file system which can cause the attaching > >>> application to believe that the VM is > >>> ready to > >>> receive a connection when it's not. With this > >>> change the stale file will be removed > >>> during VM > >>> startup. > >>> > >>> Note that there is still an issue if we don't > >>> have permission to remove the stale file, the > >>> attaching process will fail to connect. > >>> > >>> Testing: > >>> > >>> JPRT, reproducing script on Solaris, Linux. > >>> > >>> Credits: > >>> > >>> Thanks to Staffan Larsen who worked on this > >>> issue with me. > >>> > >>> Regards, > >>> > >>> > >>> Peter > >>> > > From dmitry.samersoff at oracle.com Thu Jul 11 08:17:05 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 11 Jul 2013 19:17:05 +0400 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <036901ce7e40$e79436a0$b6bca3e0$@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> <51DB4950.7080504@oracle.com> <51DB4A8A.7010205@oracle.com> <013d01ce7c9f$6d1f86b0$475e9410$@oracle.com> <51DC06A2.7040107@oracle.com> <01cf01ce7cb8$98058b90$c810a2b0$@oracle.com> <51DC4481.3000700@oracle.com> <036901ce7e40$e79436a0$b6bca3e0$@oracle.com> Message-ID: <51DECC71.2000803@oracle.com> Peter, As UNIX_PATH_MAX is sort (108 bytes) we *must* check return value of snprintf (e.g. ll.446 of attachListener_linux.cpp) and make sure it's less or equal UNIX_PATH_MAX, otherwise we unlink wrong file in case of UNIX_PATH_MAX overflow. -Dmitry On 2013-07-11 18:14, Peter Allwin wrote: > Hello, > > Thank you everyone for the feedback, I've incorporated the recommendations > into a new revision: > > http://cr.openjdk.java.net/~allwin/7162400/webrev.02/ > > Changes: > - Fixed speling misteaks > - Added jtreg regression test using Mikael's excellent suggestion of > -XX:+PauseAtStartup, tested locally on linux and solaris. > - Reverted use of MAX_PATH+1 vs. UNIX_MAX_PATH > > > Also thanks to Christian T?rnqvist for helping out with the jtreg test! > > /peter > >> -----Original Message----- >> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >> Sent: Tuesday, July 9, 2013 7:13 PM >> To: Peter Allwin >> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file > number >> during HotSpotVirtualMachine.executeCommand >> >> On 07/09/2013 05:25 PM, Peter Allwin wrote: >>> Mikael, >>> >>> That's a good point, unfortunately attach uses os::get_temp_directory >>> which is hardcoded to use /tmp. We could add a whitebox API to allow >>> us to override this but now we're on the border to noreg-hard land again >> IMO. >>> >>> Any other opinions on this? >> >> Can you use the "-XX:+PauseAtStartup" vm flag it will create a >> vm.paused. file in the current work directory. You could extract the > pid, >> touch the correct attach file in /tmp and then remove the vm.paused to let >> the VM resume. >> >> I didn't check if PauseAtStartup stops the VM early enough though. >> >> An alternate, even more hacky approach is to do something like (in bash): >> (bash -c 'echo $$; touch /tmp/.java_pid$$; exec java -version') Where you >> can extract the pid of the subshell process with $$ and then exec into the >> java launcher and keep the same pid (at least on Linux, unsure about the >> Solaris launcher). >> >> /Mikael >> >>> >>> >>> Thanks! >>> >>> /peter >>> >>>> -----Original Message----- >>>> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >>>> Sent: Tuesday, July 9, 2013 2:49 PM >>>> To: Peter Allwin >>>> Cc: serguei.spitsyn at oracle.com; daniel.daugherty at oracle.com; >>>> serviceability-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file >>> number >>>> during HotSpotVirtualMachine.executeCommand >>>> >>>> Peter, >>>> >>>> On 2013-07-09 14:25, Peter Allwin wrote: >>>>> Hello! >>>>> >>>>> It is reproducible by letting the test create .java_pid* files for >>>>> all possible process id's on the system, setting correct access >>>>> flags, launching the target VM and attempting to connect. There are >>>>> some caveats though but it should be doable. >>>>> >>>>> I'll convert the repro script to JTREG and add it to the webrev. >>>> >>>> It's probably not a good idea to have a test which taints the system >>>> with >>> stale >>>> .java_pid* files. >>>> If the test execution times out and the script isn't allowed to clean >>>> up I imagine that other subsequent executions could fail. >>>> Is there a way to tell the attach api to use a specific directory so >>>> you >>> won't >>>> need to taint /tmp? >>>> >>>> /Mikael >>>> >>>>> >>>>> Thanks for the reviews! >>>>> >>>>> /peter >>>>> >>>>> *From:*serguei.spitsyn at oracle.com >>>>> [mailto:serguei.spitsyn at oracle.com] >>>>> *Sent:* Tuesday, July 9, 2013 1:26 AM >>>>> *To:* daniel.daugherty at oracle.com >>>>> *Cc:* Peter Allwin; serviceability-dev at openjdk.java.net; >>>>> hotspot-runtime-dev at openjdk.java.net >>>>> *Subject:* Re: RFR 7162400: Intermittent java.io.IOException: Bad >>>>> file number during HotSpotVirtualMachine.executeCommand >>>>> >>>>> Ok, thanks! >>>>> >>>>> Peter, did you manage to reproduce this issue with your script? >>>>> If so, then, please, include it into the bug report and remove the >>>>> "noreg-sqe" label. >>>>> >>>>> It is Ok if you did not reproduce it, though. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 7/8/13 4:20 PM, Daniel D. Daugherty wrote: >>>>> >>>>> I definitely don't insist... :-) >>>>> >>>>> BTW, I noticed this in Peter's e-mail: >>>>> >>>>> > Testing: >>>>> > JPRT, reproducing script on Solaris, Linux. >>>>> >>>>> so maybe Peter already has this covered with "reproducing > script"... >>>>> >>>>> Dan >>>>> >>>>> On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com >>>>> wrote: >>>>> >>>>> Dan, >>>>> >>>>> Dan, thank you for the recommendation. >>>>> But I'm still not sure it is a right thing to do. >>>>> Even though, there are multiple test cases associated with > this >>>>> bug they >>>>> can not be used to verify that fix because an additional >>> condition >>>>> must be present as well. >>>>> This condition is a presence of stale door file which is not >>>>> that easy to reproduce. >>>>> >>>>> However, if you insist then I can change the lable to the >>>>> "noreg-sqe" >>>>> with the corresponding comment. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: >>>>> >>>>> Serguei, >>>>> >>>>> There are a number of existing tests associated with this >>>>> bug. I don't >>>>> think that 'noreg-hard' is the right label. I think >>>>> 'noreg-sqe' is >>>>> the right one: >>>>> >>>>> noreg-sqe >>>>> Change can be verified by running an existing SQE > test >>>>> suite; the bug >>>>> should identify the suite and the specific test >>> case(s). >>>>> >>>>> Dan >>>>> >>>>> On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com >>>>> wrote: >>>>> >>>>> Peter, >>>>> >>>>> I've added the label "noreg-hard" with the comment to >>>>> the report. >>>>> It is not easy to reproduce the issue and demonstrate >>>>> the fix in a regression test. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com >>>>> wrote: >>>>> >>>>> Hi Peter, >>>>> >>>>> The fix looks good. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 7/8/13 6:54 AM, Peter Allwin wrote: >>>>> >>>>> Hello! >>>>> >>>>> Looking for reviews of this change: >>>>> >>>>> >>> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ >>>>> >>>>> >>>>> >>>>> For CR: >>>>> >>>>> >>>>> http://bugs.sun.com/view_bug.do?bug_id=7162400 >>>>> >>>>> >>>>> https://jbs.oracle.com/bugs/browse/JDK-7162400 >>>>> >>>>> Summary: >>>>> >>>>> This change addresses an issue in the Attach > API >>>>> on Solaris, Linux and BSD where an attaching >>>>> application can receive IOExceptions such as >>>>> "Bad file number" (Solaris), "Connection >>>>> refused" (Linux/BSD), or "well-known file is > not >>>>> secure". >>>>> >>>>> The attach process uses a file in the > temporary >>>>> directory as a door (Solaris) or domain > socket >>>>> (Linux,BSD) to communicate with the VM. In >>>>> certain circumstances stale files can be left > in >>>>> the file system which can cause the attaching >>>>> application to believe that the VM is ready > to >>>>> receive a connection when it's not. With this >>>>> change the stale file will be removed during > VM >>>>> startup. >>>>> >>>>> Note that there is still an issue if we don't >>>>> have permission to remove the stale file, the >>>>> attaching process will fail to connect. >>>>> >>>>> Testing: >>>>> >>>>> JPRT, reproducing script on Solaris, Linux. >>>>> >>>>> Credits: >>>>> >>>>> Thanks to Staffan Larsen who worked on this >>>>> issue with me. >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Peter >>>>> >>> > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From valerie.peng at oracle.com Thu Jul 11 11:44:10 2013 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Thu, 11 Jul 2013 18:44:10 +0000 Subject: hg: jdk8/tl/jdk: 8020321: Problem in PKCS11 regression test TestRSAKeyLength Message-ID: <20130711184439.929B2489D1@hg.openjdk.java.net> Changeset: 162c015c434a Author: valeriep Date: 2013-07-11 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/162c015c434a 8020321: Problem in PKCS11 regression test TestRSAKeyLength Summary: Corrected the "isValidKeyLength" array Reviewed-by: xuelei ! test/sun/security/pkcs11/Signature/TestRSAKeyLength.java From jaroslav.bachorik at oracle.com Thu Jul 11 13:02:00 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Thu, 11 Jul 2013 20:02:00 +0000 Subject: hg: jdk8/tl/jdk: 8010285: Enforce the requirement of Management Interfaces being public Message-ID: <20130711200242.7F884489E6@hg.openjdk.java.net> Changeset: f3211af79339 Author: jbachorik Date: 2013-07-11 21:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3211af79339 8010285: Enforce the requirement of Management Interfaces being public Reviewed-by: sjiang, dfuchs, mchung ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanServerInvocationHandler.java ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/package.html ! src/share/classes/sun/management/ManagementFactoryHelper.java + test/javax/management/MBeanServer/MBeanFallbackTest.java + test/javax/management/MBeanServer/MBeanTest.java + test/javax/management/mxbean/MXBeanFallbackTest.java ! test/javax/management/mxbean/MXBeanTest.java + test/javax/management/proxy/JMXProxyFallbackTest.java + test/javax/management/proxy/JMXProxyTest.java From kumar.x.srinivasan at oracle.com Thu Jul 11 13:05:09 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 11 Jul 2013 20:05:09 +0000 Subject: hg: jdk8/tl/jdk: 8019799: api/java_util/jar/Pack200 test failed with compactX profiles. Message-ID: <20130711200529.BA5C5489E7@hg.openjdk.java.net> Changeset: 0bd48087e2dc Author: ksrini Date: 2013-07-11 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0bd48087e2dc 8019799: api/java_util/jar/Pack200 test failed with compactX profiles. Reviewed-by: dholmes ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java From john.coomes at oracle.com Thu Jul 11 13:29:31 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 20:29:31 +0000 Subject: hg: hsx/hotspot-rt: 2 new changesets Message-ID: <20130711202931.4D7E5489ED@hg.openjdk.java.net> Changeset: 0d0c983a817b Author: tbell Date: 2013-07-09 08:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/0d0c983a817b 8009315: F# on PATH breaks Cygwin tools (mkdir, echo, mktemp ...) Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 59dc9da81379 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/59dc9da81379 Added tag jdk8-b98 for changeset 0d0c983a817b ! .hgtags From john.coomes at oracle.com Thu Jul 11 13:29:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 20:29:34 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b98 for changeset 3370fb6146e4 Message-ID: <20130711202937.F09F1489EE@hg.openjdk.java.net> Changeset: 3f67804ab613 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/3f67804ab613 Added tag jdk8-b98 for changeset 3370fb6146e4 ! .hgtags From john.coomes at oracle.com Thu Jul 11 13:29:42 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 20:29:42 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b98 for changeset 15e5bb51bc0c Message-ID: <20130711202951.8DCAA489EF@hg.openjdk.java.net> Changeset: adf49c3ef83c Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/adf49c3ef83c Added tag jdk8-b98 for changeset 15e5bb51bc0c ! .hgtags From john.coomes at oracle.com Thu Jul 11 13:29:56 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 20:29:56 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b98 for changeset b1fb4612a2ca Message-ID: <20130711203003.7F5E8489F0@hg.openjdk.java.net> Changeset: 8ef83d4b23c9 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/8ef83d4b23c9 Added tag jdk8-b98 for changeset b1fb4612a2ca ! .hgtags From dan.xu at oracle.com Thu Jul 11 13:41:02 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Thu, 11 Jul 2013 20:41:02 +0000 Subject: hg: jdk8/tl/jdk: 8017212: File.createTempFile requires unnecessary "read" permission Message-ID: <20130711204146.D9245489F1@hg.openjdk.java.net> Changeset: 10d2a4b1e576 Author: dxu Date: 2013-07-11 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10d2a4b1e576 8017212: File.createTempFile requires unnecessary "read" permission Summary: Directly call FileSystem method to check a file existence. Also reviewed by tom.hawtin at oracle.com Reviewed-by: alanb ! src/share/classes/java/io/File.java + test/java/io/File/CheckPermission.java ! test/java/io/File/NulFile.java ! test/java/io/File/createTempFile/SpecialTempFile.java From john.coomes at oracle.com Thu Jul 11 13:33:17 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 20:33:17 +0000 Subject: hg: hsx/hotspot-rt/jdk: 86 new changesets Message-ID: <20130711205213.75E40489F2@hg.openjdk.java.net> Changeset: 5cfcd545ce4a Author: vadim Date: 2013-06-26 13:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5cfcd545ce4a 8016254: several sun/java2d/OpenGL tests failed with SIGFPE Reviewed-by: prr, bae ! src/share/native/sun/java2d/opengl/OGLContext.c Changeset: 3ffa38871143 Author: lana Date: 2013-06-28 19:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3ffa38871143 Merge - make/sun/xawt/ToBin.java - makefiles/sun/awt/X11/ToBin.java - src/share/classes/sun/misc/FDBigInt.java - src/share/classes/sun/misc/Hashing.java - src/solaris/classes/sun/awt/X11/XIconInfo.java - src/solaris/classes/sun/awt/X11/security-icon-bw16.png - src/solaris/classes/sun/awt/X11/security-icon-bw24.png - src/solaris/classes/sun/awt/X11/security-icon-bw32.png - src/solaris/classes/sun/awt/X11/security-icon-bw48.png - src/solaris/classes/sun/awt/X11/security-icon-interim16.png - src/solaris/classes/sun/awt/X11/security-icon-interim24.png - src/solaris/classes/sun/awt/X11/security-icon-interim32.png - src/solaris/classes/sun/awt/X11/security-icon-interim48.png - src/solaris/classes/sun/awt/X11/security-icon-yellow16.png - src/solaris/classes/sun/awt/X11/security-icon-yellow24.png - src/solaris/classes/sun/awt/X11/security-icon-yellow32.png - src/solaris/classes/sun/awt/X11/security-icon-yellow48.png - test/java/lang/invoke/7196190/MHProxyTest.java - test/sun/misc/Hashing.java Changeset: 6dda4a069a83 Author: prr Date: 2013-07-01 12:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6dda4a069a83 8015144: Performance regression in ICU OpenType Layout library Reviewed-by: srl, jgodinez ! make/sun/font/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/LETableReference.h ! src/share/native/sun/font/layout/OpenTypeUtilities.cpp Changeset: 6d2b5ec2ec79 Author: prr Date: 2013-07-02 14:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6d2b5ec2ec79 8019692: JDK build CC_OPT_HIGHEST setting isn't valid for Sun C++ compiler Reviewed-by: jgodinez ! make/sun/font/Makefile ! makefiles/CompileNativeLibraries.gmk Changeset: 1c607ebfc180 Author: leonidr Date: 2013-06-20 18:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1c607ebfc180 8014264: The applet pathguy_TimeDead throws java.lang.NullPointerException in java console once click drop-down check box. Reviewed-by: art, anthony, serb ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XListPeer.java Changeset: b7b95b7ab2cb Author: malenkov Date: 2013-06-21 17:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b7b95b7ab2cb 8016545: java.beans.XMLEncoder.writeObject output is wrong Reviewed-by: alexsch ! src/share/classes/java/beans/XMLEncoder.java + test/java/beans/XMLEncoder/Test8016545.java Changeset: eed321190272 Author: alitvinov Date: 2013-06-21 21:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eed321190272 8007642: Media Names on Java Print Do Not Match the Printer???s and Confuse Users Reviewed-by: prr, jgodinez ! src/windows/classes/sun/print/Win32PrintService.java Changeset: e5bac76282f7 Author: pchelko Date: 2013-06-27 13:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e5bac76282f7 8019236: [macosx] Add javadoc to the handleWindowFocusEvent in CEmbeddedFrame Reviewed-by: serb, ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: 72f167edf630 Author: dmarkov Date: 2013-06-28 18:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/72f167edf630 8016534: javax/swing/text/View/8014863/bug8014863.java failed Reviewed-by: alexp, alexsch ! test/javax/swing/text/View/8014863/bug8014863.java Changeset: 228ec4b9111a Author: lana Date: 2013-06-28 18:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/228ec4b9111a Merge - make/sun/xawt/ToBin.java - makefiles/sun/awt/X11/ToBin.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java - src/share/classes/sun/misc/FDBigInt.java - src/share/classes/sun/misc/Hashing.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java - src/solaris/classes/sun/awt/X11/XIconInfo.java ! src/solaris/classes/sun/awt/X11/XListPeer.java - src/solaris/classes/sun/awt/X11/security-icon-bw16.png - src/solaris/classes/sun/awt/X11/security-icon-bw24.png - src/solaris/classes/sun/awt/X11/security-icon-bw32.png - src/solaris/classes/sun/awt/X11/security-icon-bw48.png - src/solaris/classes/sun/awt/X11/security-icon-interim16.png - src/solaris/classes/sun/awt/X11/security-icon-interim24.png - src/solaris/classes/sun/awt/X11/security-icon-interim32.png - src/solaris/classes/sun/awt/X11/security-icon-interim48.png - src/solaris/classes/sun/awt/X11/security-icon-yellow16.png - src/solaris/classes/sun/awt/X11/security-icon-yellow24.png - src/solaris/classes/sun/awt/X11/security-icon-yellow32.png - src/solaris/classes/sun/awt/X11/security-icon-yellow48.png ! src/windows/classes/sun/print/Win32PrintService.java - test/java/lang/invoke/7196190/MHProxyTest.java - test/sun/misc/Hashing.java Changeset: 6fc558b41d8e Author: lana Date: 2013-07-02 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6fc558b41d8e Merge Changeset: 656ea2349aa5 Author: psandoz Date: 2013-06-20 10:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/656ea2349aa5 8016308: Updates to j.u.stream.Node/Nodes Reviewed-by: mduigou Contributed-by: Brian Goetz , Paul Sandoz ! src/share/classes/java/util/stream/Node.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/SliceOps.java ! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java ! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java ! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java Changeset: 85524d9839dc Author: psandoz Date: 2013-06-20 11:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/85524d9839dc 8016324: filter/flatMap pipeline sinks should pass size information to downstream sink Reviewed-by: chegar, mduigou Contributed-by: Brian Goetz ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/ReferencePipeline.java Changeset: f758d7c24396 Author: psandoz Date: 2013-06-20 11:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f758d7c24396 8016455: Sync stream tests from lambda to tl Reviewed-by: mduigou Contributed-by: Brian Goetz , Paul Sandoz ! test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java ! test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java + test/java/util/stream/bootlib/java/util/stream/LoggingTestCase.java ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java ! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java ! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java ! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java ! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java ! test/java/util/stream/boottest/java/util/stream/NodeTest.java ! test/java/util/stream/boottest/java/util/stream/UnorderedTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntUniqOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ReduceByOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamLinkTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java Changeset: 562f5cf13a9c Author: psandoz Date: 2013-06-20 11:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/562f5cf13a9c 8016139: PrimitiveIterator.forEachRemaining Reviewed-by: alanb ! src/share/classes/java/util/PrimitiveIterator.java Changeset: a44bd993ce93 Author: xuelei Date: 2013-06-20 07:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a44bd993ce93 8017157: catch more exception in test RejectClientRenego Reviewed-by: vinnie ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java Changeset: 49b78ec058fb Author: mduigou Date: 2013-06-20 07:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/49b78ec058fb 8017088: Map/HashMap.compute() incorrect with key mapping to null value Reviewed-by: dl, dholmes, plevart ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java ! test/java/util/Map/Defaults.java Changeset: 9fa37bd38d4b Author: mduigou Date: 2013-06-20 08:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9fa37bd38d4b Merge Changeset: bf2bacf934d1 Author: chegar Date: 2013-06-20 18:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bf2bacf934d1 8014499: MulticastSocket should enable IP_MULTICAST_ALL (lnx) Reviewed-by: alanb, chegar Contributed-by: John Zavgren , Chris Hegarty ! src/solaris/native/java/net/PlainDatagramSocketImpl.c + test/java/net/MulticastSocket/Promiscuous.java Changeset: cd06fc069152 Author: alanb Date: 2013-06-20 19:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cd06fc069152 8014377: (dc) DatagramChannel should set IP_MULTICAST_ALL=0 (lnx) Reviewed-by: chegar, jzavgren ! src/solaris/native/sun/nio/ch/Net.c + test/java/nio/channels/DatagramChannel/Promiscuous.java Changeset: 4503e04141f7 Author: weijun Date: 2013-06-21 18:26 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4503e04141f7 8001326: Improve Kerberos caching Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/KrbApRep.java ! src/share/classes/sun/security/krb5/KrbApReq.java + src/share/classes/sun/security/krb5/internal/ReplayCache.java + src/share/classes/sun/security/krb5/internal/rcache/AuthList.java ! src/share/classes/sun/security/krb5/internal/rcache/AuthTime.java + src/share/classes/sun/security/krb5/internal/rcache/AuthTimeWithHash.java - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java + src/share/classes/sun/security/krb5/internal/rcache/DflCache.java + src/share/classes/sun/security/krb5/internal/rcache/MemoryCache.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java + test/java/security/testlibrary/Proc.java ! test/sun/security/krb5/auto/AcceptorSubKey.java + test/sun/security/krb5/auto/BasicProc.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/NoneReplayCacheTest.java - test/sun/security/krb5/auto/ReplayCache.java + test/sun/security/krb5/auto/ReplayCacheExpunge.java + test/sun/security/krb5/auto/ReplayCachePrecise.java + test/sun/security/krb5/auto/ReplayCacheTest.java + test/sun/security/krb5/auto/ReplayCacheTestProc.java ! test/sun/security/krb5/ccache/EmptyCC.java Changeset: a88f6f4d279f Author: bpb Date: 2013-06-21 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a88f6f4d279f 7192954: Fix Float.parseFloat to round correctly and preserve monotonicity. 4396272: Parsing doubles fails to follow IEEE for largest decimal that should yield 0 7039391: Use Math.ulp in FloatingDecimal Summary: Correct rounding and monotonicity problems in floats and doubles Reviewed-by: bpb, martin Contributed-by: Dmitry Nadezhin , Louis Wasserman ! src/share/classes/sun/misc/FDBigInteger.java ! src/share/classes/sun/misc/FloatingDecimal.java ! test/java/lang/Double/ParseDouble.java ! test/java/lang/Float/ParseFloat.java ! test/sun/misc/FloatingDecimal/TestFDBigInteger.java Changeset: 814759462705 Author: bpb Date: 2013-06-21 11:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/814759462705 7131192: BigInteger.doubleValue() is depressingly slow Summary: In doubleValue() and floatValue() replace converting to String and parsing to Double or Float with direct conversion into IEEE 754 bits. Reviewed-by: bpb, drchase, martin Contributed-by: Louis Wasserman ! src/share/classes/java/math/BigInteger.java + test/java/math/BigInteger/PrimitiveConversionTests.java Changeset: 8b84d557570c Author: naoto Date: 2013-06-21 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8b84d557570c 6863624: java/util/Currency/PropertiesTest.sh writable check is incorrect Reviewed-by: alanb ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: cb3f3a05eee3 Author: chegar Date: 2013-06-22 08:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cb3f3a05eee3 8017271: Crash may occur in java.net.DualStackPlainSocketImpl::initIDs due to unchecked values returned from JNI functions Reviewed-by: alanb, khazra ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/windows/native/java/net/DualStackPlainSocketImpl.c Changeset: fd050ba1cf72 Author: arieber Date: 2013-06-22 08:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fd050ba1cf72 7157360: HttpURLConnection: HTTP method DELETE doesn't support output Reviewed-by: chegar ! src/share/classes/sun/net/www/http/PosterOutputStream.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/http/HttpURLConnection/PostOnDelete.java Changeset: 1bf060029a5d Author: weijun Date: 2013-06-24 16:25 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1bf060029a5d 8017453: ReplayCache tests fail on multiple platforms Reviewed-by: xuelei ! test/sun/security/krb5/auto/ReplayCacheExpunge.java ! test/sun/security/krb5/auto/ReplayCacheTestProc.java Changeset: 5f80b8cee601 Author: alanb Date: 2013-06-24 11:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5f80b8cee601 8017477: Remove TimeZone.DisplayNames, no longer used Reviewed-by: okutsu ! src/share/classes/java/util/TimeZone.java Changeset: bb2e67628dc0 Author: naoto Date: 2013-06-24 16:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bb2e67628dc0 8017468: typo in javadoc: " ResourceBunlde " Reviewed-by: okutsu ! src/share/classes/java/util/spi/LocaleServiceProvider.java Changeset: eabcb85fcabc Author: bpb Date: 2013-06-24 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eabcb85fcabc 6469160: (fmt) general (%g) formatting of zero (0.0) with precision 0 or 1 throws ArrayOutOfBoundsException Summary: For zero value ensure than an unpadded zero character is passed to Formatter.addZeros() Reviewed-by: iris, darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/Formatter.java ! src/share/classes/sun/misc/FloatingDecimal.java ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java Changeset: 82e7682c17e2 Author: darcy Date: 2013-06-24 23:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/82e7682c17e2 8017550: Fix doclint issues in java.lang and subpackages Reviewed-by: alanb, chegar ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Class.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 ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/lang/SuppressWarnings.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/annotation/Annotation.java ! src/share/classes/java/lang/annotation/Repeatable.java ! src/share/classes/java/lang/annotation/Retention.java ! src/share/classes/java/lang/annotation/Target.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/java/lang/reflect/TypeVariable.java Changeset: 4a4d910e1504 Author: alanb Date: 2013-06-25 13:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4a4d910e1504 8017570: jfr.jar should not be in compact3 (for now) Reviewed-by: erikj ! makefiles/profile-includes.txt Changeset: 01fcca3d2b8c Author: bpb Date: 2013-06-20 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/01fcca3d2b8c 4641897: Faster string conversion of large integers Summary: Accelerate conversion to string by means of Schoenhage recursive base conversion. Reviewed-by: bpb, alanb Contributed-by: Alan Eliasen ! src/share/classes/java/math/BigInteger.java ! test/java/math/BigInteger/BigIntegerTest.java Changeset: 89631a384ee6 Author: weijun Date: 2013-06-25 21:51 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/89631a384ee6 8016051: Possible ClassCastException in KdcComm Reviewed-by: weijun Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/krb5/KdcComm.java Changeset: ac61efd8c593 Author: shade Date: 2013-06-25 20:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ac61efd8c593 8014233: java.lang.Thread should have @Contended on TLR fields Summary: add the @Contended over three TLR fields. Reviewed-by: psandoz, chegar, dholmes, dl ! src/share/classes/java/lang/Thread.java Changeset: 757290440a2f Author: juh Date: 2013-06-25 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/757290440a2f 8017325: Cleanup of the javadoc tag in java.security.cert Summary: Convert javadoc ... and ... tags to {@code ...} Reviewed-by: darcy ! src/share/classes/java/security/cert/CRLException.java ! src/share/classes/java/security/cert/CRLSelector.java ! src/share/classes/java/security/cert/CertPath.java ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathBuilderException.java ! src/share/classes/java/security/cert/CertPathBuilderResult.java ! src/share/classes/java/security/cert/CertPathBuilderSpi.java ! src/share/classes/java/security/cert/CertPathParameters.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertPathValidatorException.java ! src/share/classes/java/security/cert/CertPathValidatorResult.java ! src/share/classes/java/security/cert/CertPathValidatorSpi.java ! src/share/classes/java/security/cert/CertSelector.java ! src/share/classes/java/security/cert/CertStore.java ! src/share/classes/java/security/cert/CertStoreException.java ! src/share/classes/java/security/cert/CertStoreParameters.java ! src/share/classes/java/security/cert/CertStoreSpi.java ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/CertificateEncodingException.java ! src/share/classes/java/security/cert/CertificateException.java ! src/share/classes/java/security/cert/CertificateExpiredException.java ! src/share/classes/java/security/cert/CertificateFactory.java ! src/share/classes/java/security/cert/CertificateFactorySpi.java ! src/share/classes/java/security/cert/CertificateNotYetValidException.java ! src/share/classes/java/security/cert/CertificateParsingException.java ! src/share/classes/java/security/cert/CertificateRevokedException.java ! src/share/classes/java/security/cert/CollectionCertStoreParameters.java ! src/share/classes/java/security/cert/Extension.java ! src/share/classes/java/security/cert/LDAPCertStoreParameters.java ! src/share/classes/java/security/cert/PKIXBuilderParameters.java ! src/share/classes/java/security/cert/PKIXCertPathBuilderResult.java ! src/share/classes/java/security/cert/PKIXCertPathChecker.java ! src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java ! src/share/classes/java/security/cert/PKIXParameters.java ! src/share/classes/java/security/cert/PKIXReason.java ! src/share/classes/java/security/cert/PolicyNode.java ! src/share/classes/java/security/cert/PolicyQualifierInfo.java ! src/share/classes/java/security/cert/TrustAnchor.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509CRLEntry.java ! src/share/classes/java/security/cert/X509CRLSelector.java ! src/share/classes/java/security/cert/X509CertSelector.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/java/security/cert/X509Extension.java Changeset: 3700bb58c9a2 Author: juh Date: 2013-06-25 14:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3700bb58c9a2 8017326: Cleanup of the javadoc tag in java.security.spec Summary: Convert javadoc and tags to {@code ...} Reviewed-by: darcy ! src/share/classes/java/security/spec/DSAGenParameterSpec.java ! src/share/classes/java/security/spec/DSAParameterSpec.java ! src/share/classes/java/security/spec/DSAPrivateKeySpec.java ! src/share/classes/java/security/spec/DSAPublicKeySpec.java ! src/share/classes/java/security/spec/ECFieldF2m.java ! src/share/classes/java/security/spec/ECFieldFp.java ! src/share/classes/java/security/spec/ECGenParameterSpec.java ! src/share/classes/java/security/spec/ECParameterSpec.java ! src/share/classes/java/security/spec/ECPoint.java ! src/share/classes/java/security/spec/ECPrivateKeySpec.java ! src/share/classes/java/security/spec/ECPublicKeySpec.java ! src/share/classes/java/security/spec/EllipticCurve.java ! src/share/classes/java/security/spec/EncodedKeySpec.java ! src/share/classes/java/security/spec/InvalidKeySpecException.java ! src/share/classes/java/security/spec/KeySpec.java ! src/share/classes/java/security/spec/MGF1ParameterSpec.java ! src/share/classes/java/security/spec/PKCS8EncodedKeySpec.java ! src/share/classes/java/security/spec/PSSParameterSpec.java ! src/share/classes/java/security/spec/RSAKeyGenParameterSpec.java ! src/share/classes/java/security/spec/RSAMultiPrimePrivateCrtKeySpec.java ! src/share/classes/java/security/spec/RSAOtherPrimeInfo.java ! src/share/classes/java/security/spec/RSAPrivateCrtKeySpec.java ! src/share/classes/java/security/spec/X509EncodedKeySpec.java Changeset: 510035b7bbbb Author: yhuang Date: 2013-06-25 21:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/510035b7bbbb 8013836: getFirstDayOfWeek reports wrong day for pt-BR locale Reviewed-by: naoto + src/share/classes/sun/util/resources/pt/CalendarData_pt_BR.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 0822bcddbd4f Author: xuelei Date: 2013-06-26 06:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0822bcddbd4f 8017049: rename property jdk.tls.rejectClientInitializedRenego Reviewed-by: vinnie, wetmore, mullan ! src/share/classes/sun/security/ssl/Handshaker.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NoImpactServerRenego.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java Changeset: e83cdd58f1cf Author: chegar Date: 2013-06-26 15:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e83cdd58f1cf 8012647: Add Arrays.parallelPrefix (prefix sum, scan, cumulative sum) Reviewed-by: chegar, alanb, psandoz Contributed-by: Doug Lea
, Tristan Yan , Chris Hegarty + src/share/classes/java/util/ArrayPrefixHelpers.java ! src/share/classes/java/util/Arrays.java + test/java/util/Arrays/ParallelPrefix.java Changeset: 71059bca036a Author: rfield Date: 2013-06-26 07:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/71059bca036a 8016761: Lambda metafactory - incorrect type conversion of constructor method handle Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + test/java/lang/invoke/lambda/LambdaConstructorMethodHandleUnbox.java Changeset: 336e5a862013 Author: naoto Date: 2013-06-26 11:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/336e5a862013 8017322: java/util/Currency/PropertiesTest.sh should run exclusively Reviewed-by: alanb ! test/TEST.ROOT Changeset: 1fda8fa7ae97 Author: darcy Date: 2013-06-26 13:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1fda8fa7ae97 7018139: Fix HTML accessibility and doclint issues in java.math Reviewed-by: lancea, bpb ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/RoundingMode.java Changeset: a5aa57eb85b6 Author: darcy Date: 2013-06-26 19:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a5aa57eb85b6 8019223: Fix doclint warnings in java.rmi.server Reviewed-by: smarks ! src/share/classes/java/rmi/server/RMIClassLoader.java Changeset: ac65905883a7 Author: darcy Date: 2013-06-26 22:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ac65905883a7 8019228: Fix doclint issues in java.util.zip Reviewed-by: sherman, mchung ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java Changeset: 370e7beff8a0 Author: wetmore Date: 2013-06-27 10:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/370e7beff8a0 8019227: JDK-8010325 broke the old build Reviewed-by: alanb, chegar ! make/java/java/FILES_java.gmk Changeset: 4e69a7dfbeac Author: chegar Date: 2013-06-27 10:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4e69a7dfbeac Merge Changeset: 1c31082f0a51 Author: darcy Date: 2013-06-27 11:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1c31082f0a51 8019304: Fix doclint issues in java.util.prefs Reviewed-by: lancea ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/prefs/PreferencesFactory.java Changeset: b9ba04dc210f Author: lancea Date: 2013-06-27 15:07 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b9ba04dc210f 8017471: Fix JDBC -Xdoclint public errors Reviewed-by: darcy ! src/share/classes/java/sql/Blob.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Clob.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/Driver.java ! src/share/classes/java/sql/DriverAction.java ! src/share/classes/java/sql/NClob.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLInput.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/sql/SQLXML.java ! src/share/classes/java/sql/Wrapper.java ! src/share/classes/javax/sql/CommonDataSource.java ! src/share/classes/javax/sql/ConnectionPoolDataSource.java ! src/share/classes/javax/sql/DataSource.java ! src/share/classes/javax/sql/RowSet.java ! src/share/classes/javax/sql/XADataSource.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/CachedRowSet.java ! src/share/classes/javax/sql/rowset/FilteredRowSet.java ! src/share/classes/javax/sql/rowset/JdbcRowSet.java ! src/share/classes/javax/sql/rowset/Joinable.java ! src/share/classes/javax/sql/rowset/Predicate.java ! src/share/classes/javax/sql/rowset/RowSetProvider.java ! src/share/classes/javax/sql/rowset/RowSetWarning.java ! src/share/classes/javax/sql/rowset/WebRowSet.java ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/sql/rowset/spi/SyncResolver.java Changeset: b8f16cb2d95b Author: darcy Date: 2013-06-27 12:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b8f16cb2d95b 8019315: Fix doclint issues in java.util.logging Reviewed-by: lancea ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java Changeset: 6729f7ef94cd Author: smarks Date: 2013-06-27 13:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6729f7ef94cd 8019224: add exception chaining to RMI CGIHandler Reviewed-by: darcy ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Changeset: 1099fe14fb65 Author: darcy Date: 2013-06-27 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1099fe14fb65 8019320: Fix doclint issues in javax.script Reviewed-by: lancea ! src/share/classes/javax/script/Invocable.java ! src/share/classes/javax/script/ScriptContext.java ! src/share/classes/javax/script/ScriptEngineFactory.java ! src/share/classes/javax/script/SimpleScriptContext.java Changeset: e34e3ddb3cd8 Author: naoto Date: 2013-06-27 14:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e34e3ddb3cd8 6609431: (rb) ResourceBundle.getString() returns incorrect value Reviewed-by: okutsu, sherman ! src/share/classes/java/util/Properties.java + test/java/util/Properties/Bug6609431.java + test/java/util/Properties/Bug6609431.properties Changeset: 29bbbb136bc5 Author: darcy Date: 2013-06-27 19:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/29bbbb136bc5 8019357: Fix doclint warnings in java.lang.invoke Reviewed-by: jrose ! src/share/classes/java/lang/invoke/LambdaConversionException.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/SerializedLambda.java ! src/share/classes/java/lang/invoke/package-info.java Changeset: 60d1994f63f7 Author: xuelei Date: 2013-06-27 19:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/60d1994f63f7 8019359: To comment why not use no_renegotiation to reject client initiated renegotiation Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/ServerHandshaker.java Changeset: c1df54fd19b2 Author: henryjen Date: 2013-06-11 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c1df54fd19b2 8009736: Comparator API cleanup Reviewed-by: psandoz, briangoetz, mduigou, plevart ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Comparator.java ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/SortedOps.java ! test/java/nio/file/Files/StreamTest.java ! test/java/util/Collection/ListDefaults.java + test/java/util/Comparator/BasicTest.java + test/java/util/Comparator/TypeTest.java - test/java/util/Comparators/BasicTest.java + test/java/util/Map/EntryComparators.java + test/java/util/function/BinaryOperator/BasicTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java ! test/sun/misc/JavaLangAccess/NewUnsafeString.java Changeset: 28b71c97a72d Author: psandoz Date: 2013-06-28 10:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/28b71c97a72d 8012987: Optimizations for Stream.limit/substream Reviewed-by: mduigou Contributed-by: Brian Goetz , Paul Sandoz ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/AbstractTask.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/ForEachOps.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/SliceOps.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/StreamSpliterators.java ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java ! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java + test/java/util/stream/boottest/java/util/stream/SliceSpliteratorTest.java ! test/java/util/stream/boottest/java/util/stream/StreamFlagsTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java Changeset: 19a6d2d701d9 Author: sla Date: 2013-06-26 19:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/19a6d2d701d9 8019155: Update makefiles with correct jfr packages Reviewed-by: mgronlun, erikj ! make/common/Release.gmk ! makefiles/CreateJars.gmk Changeset: 04378a645944 Author: alanb Date: 2013-06-28 16:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/04378a645944 8019380: doclint warnings in java.nio, java.nio.file.**, java.nio.channels.** Reviewed-by: chegar ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/MappedByteBuffer.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousByteChannel.java ! src/share/classes/java/nio/channels/AsynchronousChannel.java ! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/MulticastChannel.java ! src/share/classes/java/nio/channels/NetworkChannel.java ! src/share/classes/java/nio/channels/Pipe.java ! src/share/classes/java/nio/channels/SelectableChannel.java ! src/share/classes/java/nio/channels/SelectionKey.java ! src/share/classes/java/nio/channels/Selector.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelector.java ! src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java ! src/share/classes/java/nio/channels/spi/SelectorProvider.java ! src/share/classes/java/nio/charset/Charset-X-Coder.java.template ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/charset/CoderResult.java ! src/share/classes/java/nio/charset/spi/CharsetProvider.java ! src/share/classes/java/nio/file/FileStore.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/FileSystems.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/share/classes/java/nio/file/WatchEvent.java ! src/share/classes/java/nio/file/WatchService.java ! src/share/classes/java/nio/file/attribute/AclEntry.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/AttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java ! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileAttribute.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/spi/FileSystemProvider.java ! src/share/classes/java/sql/SQLInput.java Changeset: 1919c226b427 Author: dl Date: 2013-06-28 12:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1919c226b427 8017739: ReentrantReadWriteLock is confused by the Threads with reused IDs Reviewed-by: chegar ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java Changeset: 0e24065a75db Author: dl Date: 2013-06-28 12:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0e24065a75db 8019377: Sync j.u.c locks and atomic from 166 to tl Reviewed-by: chegar ! 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/AtomicMarkableReference.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 ! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java ! 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/Striped64.java ! src/share/classes/java/util/concurrent/atomic/package-info.java ! src/share/classes/java/util/concurrent/locks/AbstractOwnableSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! src/share/classes/java/util/concurrent/locks/Condition.java ! src/share/classes/java/util/concurrent/locks/Lock.java ! src/share/classes/java/util/concurrent/locks/LockSupport.java ! src/share/classes/java/util/concurrent/locks/ReadWriteLock.java ! src/share/classes/java/util/concurrent/locks/ReentrantLock.java ! src/share/classes/java/util/concurrent/locks/StampedLock.java Changeset: ff0242ed08db Author: jzavgren Date: 2013-06-28 16:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ff0242ed08db 8015799: HttpURLConnection.getHeaderFields() throws IllegalArgumentException Reviewed-by: chegar, dsamersoff, khazra ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/CookieHandler/EmptyCookieHeader.java Changeset: 52b4527d3fc7 Author: chegar Date: 2013-06-28 16:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/52b4527d3fc7 Merge Changeset: 389f59e6288f Author: juh Date: 2013-06-28 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/389f59e6288f 8019360: Cleanup of the javadoc tag in java.security.* Summary: Convert to {@code ...} tags. convert package.html to package-info.java. Reviewed-by: darcy ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/AccessControlException.java ! src/share/classes/java/security/AccessController.java ! src/share/classes/java/security/AlgorithmParameterGenerator.java ! src/share/classes/java/security/AlgorithmParameterGeneratorSpi.java ! src/share/classes/java/security/AlgorithmParameters.java ! src/share/classes/java/security/AlgorithmParametersSpi.java ! src/share/classes/java/security/AllPermission.java ! src/share/classes/java/security/AuthProvider.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/Certificate.java ! src/share/classes/java/security/CodeSigner.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/DigestException.java ! src/share/classes/java/security/DigestInputStream.java ! src/share/classes/java/security/DigestOutputStream.java ! src/share/classes/java/security/DomainCombiner.java ! src/share/classes/java/security/GeneralSecurityException.java ! src/share/classes/java/security/Guard.java ! src/share/classes/java/security/GuardedObject.java ! src/share/classes/java/security/Identity.java ! src/share/classes/java/security/IdentityScope.java ! src/share/classes/java/security/InvalidAlgorithmParameterException.java ! src/share/classes/java/security/InvalidKeyException.java ! src/share/classes/java/security/Key.java ! src/share/classes/java/security/KeyException.java ! src/share/classes/java/security/KeyFactory.java ! src/share/classes/java/security/KeyFactorySpi.java ! src/share/classes/java/security/KeyManagementException.java ! src/share/classes/java/security/KeyPair.java ! src/share/classes/java/security/KeyPairGenerator.java ! src/share/classes/java/security/KeyPairGeneratorSpi.java ! src/share/classes/java/security/KeyRep.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/KeyStoreException.java ! src/share/classes/java/security/KeyStoreSpi.java ! src/share/classes/java/security/MessageDigest.java ! src/share/classes/java/security/MessageDigestSpi.java ! src/share/classes/java/security/NoSuchAlgorithmException.java ! src/share/classes/java/security/Permission.java ! src/share/classes/java/security/PermissionCollection.java ! src/share/classes/java/security/Permissions.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/PolicySpi.java ! src/share/classes/java/security/PrivilegedAction.java ! src/share/classes/java/security/PrivilegedActionException.java ! src/share/classes/java/security/PrivilegedExceptionAction.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/ProviderException.java ! src/share/classes/java/security/PublicKey.java ! src/share/classes/java/security/SecureClassLoader.java ! src/share/classes/java/security/SecureRandom.java ! src/share/classes/java/security/SecureRandomSpi.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/SecurityPermission.java ! src/share/classes/java/security/Signature.java ! src/share/classes/java/security/SignatureException.java ! src/share/classes/java/security/SignatureSpi.java ! src/share/classes/java/security/SignedObject.java ! src/share/classes/java/security/Signer.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/acl/Acl.java ! src/share/classes/java/security/acl/AclEntry.java ! src/share/classes/java/security/acl/Group.java ! src/share/classes/java/security/acl/Owner.java + src/share/classes/java/security/acl/package-info.java - src/share/classes/java/security/acl/package.html + src/share/classes/java/security/cert/package-info.java - src/share/classes/java/security/cert/package.html ! src/share/classes/java/security/interfaces/DSAKeyPairGenerator.java ! src/share/classes/java/security/interfaces/DSAParams.java ! src/share/classes/java/security/interfaces/DSAPrivateKey.java ! src/share/classes/java/security/interfaces/DSAPublicKey.java + src/share/classes/java/security/interfaces/package-info.java - src/share/classes/java/security/interfaces/package.html + src/share/classes/java/security/package-info.java - src/share/classes/java/security/package.html + src/share/classes/java/security/spec/package-info.java - src/share/classes/java/security/spec/package.html Changeset: 9d175c6cb527 Author: darcy Date: 2013-06-28 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9d175c6cb527 8019407: Fix doclint issues in javax.naming.* Reviewed-by: lancea ! src/share/classes/javax/naming/CompositeName.java ! src/share/classes/javax/naming/CompoundName.java ! src/share/classes/javax/naming/Context.java ! src/share/classes/javax/naming/InitialContext.java ! src/share/classes/javax/naming/RefAddr.java ! src/share/classes/javax/naming/ReferralException.java ! src/share/classes/javax/naming/directory/DirContext.java ! src/share/classes/javax/naming/event/EventContext.java ! src/share/classes/javax/naming/ldap/ControlFactory.java ! src/share/classes/javax/naming/ldap/InitialLdapContext.java ! src/share/classes/javax/naming/ldap/LdapContext.java Changeset: 389b8739a74e Author: alanb Date: 2013-06-28 19:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/389b8739a74e 8019384: jps and jcmd tests fail when there is a process started with a .war file Reviewed-by: dcubed, sla, mchung ! test/sun/tools/jcmd/jcmd_Output1.awk ! test/sun/tools/jps/jps-l_Output1.awk ! test/sun/tools/jps/jps_Output1.awk Changeset: b4d36f3717b8 Author: lana Date: 2013-06-28 19:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b4d36f3717b8 Merge Changeset: a4eb59bffb60 Author: lancea Date: 2013-06-29 06:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a4eb59bffb60 8019286: Fix javadoc typo in ResultSet.next Reviewed-by: darcy, mchung ! src/share/classes/java/sql/ResultSet.java Changeset: bf650fee4983 Author: darcy Date: 2013-06-30 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bf650fee4983 8019466: Fix doclint issues in java.util.function Reviewed-by: briangoetz ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/UnaryOperator.java Changeset: 9eaeb1a0aa46 Author: darcy Date: 2013-06-30 17:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9eaeb1a0aa46 8019467: Fix doclint issues in java.util.jar.Pack200 Reviewed-by: lancea, ksrini ! src/share/classes/java/util/jar/Pack200.java Changeset: 3aa541b50a64 Author: dfuchs Date: 2013-07-01 11:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3aa541b50a64 8014045: test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently Summary: this test was failing because it didn't take into account the fact that Loggers could be garbage collected. Reviewed-by: mchung ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java Changeset: dfb37cc30a67 Author: vinnie Date: 2013-07-01 14:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dfb37cc30a67 8019259: Failover to CRL checking does not happen if wrong OCSP responder URL is set Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java Changeset: c8cf01de8fa8 Author: bpb Date: 2013-07-01 11:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c8cf01de8fa8 8017540: Improve multi-threaded contention behavior of radix conversion cache Summary: Replace array of ArrayList of BigIntegers with a volatile two-dimensional BigInteger array eliminate the synchronization of getRadixConversionCache() Reviewed-by: plevart, shade, bpb, alanb Contributed-by: Peter Levart , Dmitry Nadezhin , Aleksey Shipilev ! src/share/classes/java/math/BigInteger.java Changeset: 3736ad2636aa Author: darcy Date: 2013-07-01 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3736ad2636aa 8019527: Fix doclint issues in java.lang.instrument Reviewed-by: lancea, alanb ! src/share/classes/java/lang/instrument/Instrumentation.java Changeset: 8e5376324e4b Author: darcy Date: 2013-07-01 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8e5376324e4b 8019529: Fix doclint issues in java.util.spi Reviewed-by: lancea ! src/share/classes/java/util/spi/LocaleServiceProvider.java Changeset: 5427f7316633 Author: darcy Date: 2013-07-01 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5427f7316633 8019535: Fix doclint issues in java.time.format Reviewed-by: lancea, rriggs ! src/share/classes/java/time/format/DateTimeFormatter.java Changeset: 17f44b2dde41 Author: juh Date: 2013-07-01 17:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/17f44b2dde41 8019539: Fix doclint errors in java.security and its subpackages Reviewed-by: darcy ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509CRLEntry.java ! src/share/classes/java/security/cert/X509Certificate.java Changeset: 020f023f87d1 Author: dfuchs Date: 2013-07-02 11:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/020f023f87d1 8017174: NPE when using Logger.getAnonymousLogger or LogManager.getLogManager().getLogger Summary: This patch makes sure that LoggerContext instances created for applets have a root and global logger. Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java ! test/java/util/logging/LogManagerInstanceTest.java + test/java/util/logging/TestAppletLoggerContext.java Changeset: b1fffbbdf58c Author: ksrini Date: 2013-07-02 05:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b1fffbbdf58c 8017463: [TEST_BUG] 2 tests from tools/pack200/ remain about 1 GB of data in work directory after execution Reviewed-by: mchung ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/BandIntegrity.java ! test/tools/pack200/CommandLineTests.java ! test/tools/pack200/InstructionTests.java ! test/tools/pack200/Pack200Props.java ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/PackageVersionTest.java ! test/tools/pack200/RepackTest.java ! test/tools/pack200/T7007157.java ! test/tools/pack200/TestExceptions.java ! test/tools/pack200/TimeStamp.java ! test/tools/pack200/UnpackerMemoryTest.java ! test/tools/pack200/Utils.java ! test/tools/pack200/typeannos/TestTypeAnnotations.java Changeset: 70bff2d12af0 Author: dfuchs Date: 2013-07-02 19:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/70bff2d12af0 7184195: java.util.logging.Logger.getGlobal().info() doesn't log without configuration Summary: Due to subtle synchronization issues between LogManager & Logger class initialization the global logger doesn't have its 'manager' field initialized until the LogManager is initialized. This fix will ensure that the global logger has its 'manager' field set when getGlobal() is called. Reviewed-by: mchung, plevart ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/Logger/getGlobal/TestGetGlobal.java + test/java/util/logging/Logger/getGlobal/TestGetGlobalByName.java + test/java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java + test/java/util/logging/Logger/getGlobal/logging.properties + test/java/util/logging/Logger/getGlobal/policy + test/java/util/logging/Logger/getGlobal/testgetglobal/BadLogManagerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/DummyLogManagerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/HandlerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl1.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl2.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl3.java Changeset: 11c074904fce Author: lana Date: 2013-07-02 15:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/11c074904fce Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: 974b94f944ce Author: lana Date: 2013-07-03 19:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/974b94f944ce Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: f2342dedf04a Author: lana Date: 2013-07-05 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f2342dedf04a Merge Changeset: 2c26ccf0a85b Author: tbell Date: 2013-07-08 07:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2c26ccf0a85b 8012925: [parfait] Missing return value in jdk/src/macosx/native/sun/awt/AWTEvent.m Reviewed-by: katleman, leonidr Contributed-by: petr.pchelko at oracle.com ! src/macosx/native/sun/awt/AWTEvent.m Changeset: c4908732fef5 Author: katleman Date: 2013-07-08 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c4908732fef5 Merge Changeset: 758c21301545 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/758c21301545 Added tag jdk8-b98 for changeset c4908732fef5 ! .hgtags From john.coomes at oracle.com Thu Jul 11 13:57:22 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 20:57:22 +0000 Subject: hg: hsx/hotspot-rt/nashorn: 33 new changesets Message-ID: <20130711205749.995A0489F5@hg.openjdk.java.net> Changeset: 6a75a505301f Author: sundar Date: 2013-06-18 18:43 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/6a75a505301f 8012698: [nashorn] tests fail to run with agentvm or samevm Reviewed-by: hannesw, jlaskey ! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java ! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java Changeset: 7276d66b7118 Author: jlaskey Date: 2013-06-19 09:10 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/7276d66b7118 8010697: DeletedArrayFilter seems to leak memory Reviewed-by: hannesw, sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java + test/script/basic/JDK-8010697.js + test/script/basic/JDK-8010697.js.EXPECTED Changeset: c7c9222cfe69 Author: sundar Date: 2013-06-19 21:07 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/c7c9222cfe69 8015347: Parsing issue with decodeURIComponent Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/URIUtils.java + test/script/basic/JDK-8015347.js Changeset: ac404bf3f8c8 Author: sundar Date: 2013-06-20 13:45 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/ac404bf3f8c8 8017046: Cannot assign undefined to a function argument if the function uses arguments object Reviewed-by: hannesw ! src/jdk/nashorn/internal/objects/NativeArguments.java + test/script/basic/JDK-8017046.js Changeset: c7672e621b14 Author: sundar Date: 2013-06-20 17:34 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/c7672e621b14 Merge Changeset: 8e03121cc286 Author: sundar Date: 2013-06-21 16:55 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/8e03121cc286 8017260: adjust lookup code in objects.* classes Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java Changeset: b4e2bccf9598 Author: sundar Date: 2013-06-21 17:33 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/b4e2bccf9598 Merge Changeset: c30beaf3c42a Author: jlaskey Date: 2013-06-21 14:34 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/c30beaf3c42a 8010732: BigDecimal, BigInteger and Long handling in nashorn Reviewed-by: sundar Contributed-by: james.laskey at oracle.com + test/script/basic/JDK-8010732.js + test/script/basic/JDK-8010732.js.EXPECTED Changeset: 2ded2fc08c94 Author: jlaskey Date: 2013-06-22 10:12 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/2ded2fc08c94 8017448: JDK-8010732.js.EXPECTED truncated Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! test/script/basic/JDK-8010732.js.EXPECTED Changeset: 51a5ee93d6bc Author: sundar Date: 2013-06-24 19:06 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/51a5ee93d6bc 8015959: Can't call foreign constructor Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + test/script/basic/JDK-8015959.js + test/script/basic/JDK-8015959.js.EXPECTED Changeset: 26a345c26e62 Author: sundar Date: 2013-06-25 17:31 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/26a345c26e62 8015969: Needs to enforce and document that global "context" and "engine" can't be modified when running via jsr223 Reviewed-by: hannesw, jlaskey ! docs/JavaScriptingProgrammersGuide.html ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java + test/script/basic/JDK-8015969.js Changeset: 39e17373d8df Author: sundar Date: 2013-06-26 16:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/39e17373d8df 8017950: error.stack should be a string rather than an array Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! test/script/basic/JDK-8012164.js ! test/script/basic/JDK-8012164.js.EXPECTED + test/script/basic/JDK-8017950.js + test/script/basic/JDK-8017950.js.EXPECTED ! test/script/basic/NASHORN-109.js ! test/script/basic/NASHORN-296.js ! test/script/basic/errorstack.js Changeset: 682889823712 Author: jlaskey Date: 2013-06-26 08:36 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/682889823712 8008458: Strict functions dont share property map Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java Changeset: 80c66d3fd872 Author: hannesw Date: 2013-06-26 15:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/80c66d3fd872 8019157: Avoid calling ScriptObject.setProto() if possible Reviewed-by: jlaskey, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/FunctionScope.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/scripts/JO.java Changeset: 635098f9f45e Author: sundar Date: 2013-06-26 19:42 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/635098f9f45e 8014781: support Error.captureStackTrace Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/internal/objects/NativeError.java + test/script/basic/JDK-8014781.js + test/script/basic/JDK-8014781.js.EXPECTED Changeset: d1886ad46f0c Author: jlaskey Date: 2013-06-26 12:38 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/d1886ad46f0c 8019175: Simplify ScriptObject.modifyOwnProperty Reviewed-by: hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java Changeset: f9c855b828fe Author: sundar Date: 2013-06-27 13:24 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/f9c855b828fe 8019226: line number not generated for first statement if it is on the same function declaration line Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8019226.js + test/script/basic/JDK-8019226.js.EXPECTED Changeset: 5ec4762d9df0 Author: sundar Date: 2013-06-27 13:47 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/5ec4762d9df0 Merge Changeset: 90864d892593 Author: lana Date: 2013-06-28 19:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/90864d892593 Merge Changeset: 218c2833c344 Author: sundar Date: 2013-06-28 19:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/218c2833c344 8019365: Error stack format Reviewed-by: hannesw ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/internal/objects/NativeError.java ! test/script/basic/JDK-8014781.js.EXPECTED ! test/script/basic/JDK-8017950.js.EXPECTED ! test/script/basic/JDK-8019226.js ! test/script/basic/JDK-8019226.js.EXPECTED Changeset: 02588d68399d Author: sundar Date: 2013-07-01 12:38 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/02588d68399d 8019473: Parser issues related to functions and blocks Reviewed-by: lagergren ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8019473.js Changeset: 10c7a1e9e24f Author: sundar Date: 2013-07-01 14:15 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/10c7a1e9e24f 8019478: Object.prototype.toString.call(/a/.exec("a")) === "[object Array]" should be true Reviewed-by: hannesw ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java + test/script/basic/JDK-8019478.js Changeset: 47099609a48b Author: sundar Date: 2013-07-01 17:21 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/47099609a48b 8019482: Number("0x0.0p0") should evaluate to NaN Reviewed-by: lagergren ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/JSType.java + test/script/basic/JDK-8019482.js Changeset: ab3ea5b3e507 Author: sundar Date: 2013-07-01 19:52 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/ab3ea5b3e507 8019488: switch on literals result in NoSuchMethodError or VerifyError Reviewed-by: hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8019488.js Changeset: 9165138b427c Author: sundar Date: 2013-07-01 23:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/9165138b427c 8019508: Comma handling in object literal parsing is wrong Reviewed-by: hannesw ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8019508.js + test/script/basic/JDK-8019508.js.EXPECTED Changeset: 5f9abeb0bb50 Author: jlaskey Date: 2013-07-02 07:45 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/5f9abeb0bb50 8019580: Build Script Change for Nashorn promotion testing Reviewed-by: jlaskey Contributed-by: eugene.drobitko at oracle.com ! make/build.xml Changeset: a7b82e333c31 Author: lagergren Date: 2013-07-02 13:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/a7b82e333c31 8016667: Wrong bytecode when testing/setting due to null check shortcut checking against primitive too Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8016667.js Changeset: 74049fe3ba46 Author: sundar Date: 2013-07-02 18:00 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/74049fe3ba46 8019553: NPE on illegal l-value for increment and decrement Reviewed-by: jlaskey, attila, lagergren ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8019553.js + test/script/basic/JDK-8019553.js.EXPECTED ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-51.js.EXPECTED ! test/script/error/NASHORN-57.js.EXPECTED Changeset: 9396e42bae4f Author: lagergren Date: 2013-07-02 14:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/9396e42bae4f 8017082: Long array literals were slightly broken Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/LiteralNode.java + test/script/basic/JDK-8017082.js Changeset: 69ec02d12a31 Author: lagergren Date: 2013-07-02 15:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/69ec02d12a31 Merge Changeset: 16c4535abcf8 Author: sundar Date: 2013-07-02 18:39 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/16c4535abcf8 Merge Changeset: 542b7803f038 Author: lana Date: 2013-07-05 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/542b7803f038 Merge Changeset: 10a1ab9e20a4 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/10a1ab9e20a4 Added tag jdk8-b98 for changeset 542b7803f038 ! .hgtags From john.coomes at oracle.com Thu Jul 11 13:55:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 20:55:34 +0000 Subject: hg: hsx/hotspot-rt/langtools: 32 new changesets Message-ID: <20130711205713.75313489F3@hg.openjdk.java.net> Changeset: 6debfa63a4a1 Author: vromero Date: 2013-06-20 08:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6debfa63a4a1 8016613: javac should avoid source 8 only analysis when compiling for source 7 Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java Changeset: e9ebff1840e5 Author: emc Date: 2013-06-20 19:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/e9ebff1840e5 8007546: ClassCastException on JSR308 tests 8015993: jck-compiler tests are failed with java.lang.ClassCastException Summary: Fix ClassCastExceptions arising from addition of AnnotatedType. Reviewed-by: jjg, abuckley ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java Changeset: bf020de5a6db Author: emc Date: 2013-06-24 22:03 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/bf020de5a6db 8012722: Single comma in array initializer should parse Summary: Annotations of the form @Foo({,}) should parse Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/parser/SingleCommaAnnotationValue.java + test/tools/javac/parser/SingleCommaAnnotationValueFail.java + test/tools/javac/parser/SingleCommaAnnotationValueFail.out Changeset: 831467c4c6a7 Author: vromero Date: 2013-06-25 16:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/831467c4c6a7 8017104: javac should have a class for primitive types that inherits from Type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/share/classes/com/sun/tools/javac/code/Types.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/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java Changeset: aceae9ceebbe Author: kizune Date: 2013-06-25 20:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/aceae9ceebbe 8006973: jtreg test fails: test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java Reviewed-by: ksrini ! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java Changeset: c2d9303c3477 Author: ksrini Date: 2013-06-26 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/c2d9303c3477 8016908: TEST_BUG: removing non-ascii characters causes tests to fail Reviewed-by: jjg, vromero ! test/tools/javac/api/6437999/T6437999.java - test/tools/javac/api/6437999/Utf8.java ! test/tools/javac/api/T6306137.java Changeset: 3b2e10524627 Author: jjg Date: 2013-06-26 18:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/3b2e10524627 8014137: Update test/tools/javac/literals/UnderscoreLiterals to add testcases with min/max values Reviewed-by: jjg, darcy Contributed-by: matherey.nunez at oracle.com ! test/tools/javac/literals/UnderscoreLiterals.java Changeset: 4fe5aab73bb2 Author: bpatel Date: 2013-06-26 20:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4fe5aab73bb2 8007338: Method grouping tab line-folding Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java Changeset: 27bd6a2302f6 Author: bpatel Date: 2013-06-26 20:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/27bd6a2302f6 8014017: extra space in javadoc class heading Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java Changeset: 36e8bc1907a2 Author: bpatel Date: 2013-06-26 20:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/36e8bc1907a2 8013738: Two javadoc tests have bug 0000000 Reviewed-by: jjg ! test/com/sun/javadoc/testNestedInlineTag/TestNestedInlineTag.java ! test/com/sun/javadoc/testTagMisuse/TestTagMisuse.java Changeset: c674b396827c Author: emc Date: 2013-06-27 00:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/c674b396827c 8014230: Compilation incorrectly succeeds with inner class constructor with 254 parameters Summary: The compiler does not account fr extra parameters due to inner this parameters Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javac/limits/NestedClassConstructorArgs.java + test/tools/javac/limits/NestedClassMethodArgs.java - test/tools/javac/limits/NumArgs1.java - test/tools/javac/limits/NumArgs2.java - test/tools/javac/limits/NumArgs3.java - test/tools/javac/limits/NumArgs4.java + test/tools/javac/limits/NumArgsTest.java + test/tools/javac/limits/StaticNestedClassConstructorArgs.java + test/tools/javac/limits/TopLevelClassConstructorArgs.java + test/tools/javac/limits/TopLevelClassMethodArgs.java + test/tools/javac/limits/TopLevelClassStaticMethodArgs.java Changeset: dcc6a52bf363 Author: erikj Date: 2013-06-27 10:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/dcc6a52bf363 8014513: Sjavac doesn't detect 32-bit jvm properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java Changeset: a47e28759666 Author: vromero Date: 2013-06-27 09:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a47e28759666 7066788: javah again accepts -old option (ineffectively) which was removed in 1.5. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javah/JavahTask.java Changeset: 8e3d391c88c6 Author: vromero Date: 2013-06-27 09:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/8e3d391c88c6 8017609: javac, ClassFile.read(Path) should be ClassFile.read(Path, Attribute.Factory) Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/ClassFile.java Changeset: e42c27026290 Author: vromero Date: 2013-06-27 16:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/e42c27026290 8016099: Some @SuppressWarnings annotations ignored ( unchecked, rawtypes ) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T8016099/UncheckedWarningRegressionTest.java + test/tools/javac/T8016099/UncheckedWarningRegressionTest.out Changeset: d137ce373c4c Author: vromero Date: 2013-06-27 16:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/d137ce373c4c 7008643: inlined finally clauses confuse debuggers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T7008643/InlinedFinallyConfuseDebuggersTest.java Changeset: 26437287529d Author: janvalenta Date: 2013-06-27 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/26437287529d 8015720: since tag isn't copied while generating JavaFX documentation Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! test/com/sun/javadoc/testJavaFX/C.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java Changeset: 065f8cb7bd89 Author: darcy Date: 2013-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/065f8cb7bd89 8019308: Add descriptions of Java SE 7 and 8 language changes to SourceVersion Reviewed-by: jjg ! src/share/classes/javax/lang/model/SourceVersion.java Changeset: 97e798c06804 Author: ksrini Date: 2013-06-27 12:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/97e798c06804 7080001: Need to bump version numbers in build.properties for 8 Reviewed-by: jjg ! make/build.properties Changeset: 5c548a8542b8 Author: emc Date: 2013-06-27 17:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/5c548a8542b8 8013357: javac accepts erroneous binary comparison operations Summary: javac does not report type errors on illegal Object == primitive comparisons Reviewed-by: abuckley, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! test/tools/javac/lambda/LambdaConv01.java ! test/tools/javac/lambda/LambdaExpr15.java ! test/tools/javac/lambda/typeInference/InferenceTest2b.java + test/tools/javac/types/TestComparisons.java Changeset: 6101e52ce9e3 Author: emc Date: 2013-06-28 06:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6101e52ce9e3 8016760: Failure of regression test langtools/tools/javac/T6725036.java Summary: Marking the failing test @ignore; the proposed change for 8015666 addresses the underlying issue Reviewed-by: jjg ! test/tools/javac/T6725036.java Changeset: bb06c412d079 Author: vromero Date: 2013-06-28 13:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/bb06c412d079 6473148: TreePath.iterator() should document the iteration order Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/TreePath.java Changeset: bdd699d7378d Author: vromero Date: 2013-06-28 14:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/bdd699d7378d 8005552: c.s.t.javap.AttributeWriter.visitLocalVariableTable() uses incorrect format string Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: 66147d50d8d6 Author: lana Date: 2013-06-28 19:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/66147d50d8d6 Merge Changeset: 891c5ecb8306 Author: vromero Date: 2013-06-29 20:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/891c5ecb8306 6983646: javap should identify why a DefaultAttribute is being used Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/DefaultAttribute.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: f559ef7568ce Author: mcimadamore Date: 2013-07-01 14:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f559ef7568ce 7034798: Ambiguity error for abstract method call is too eager Summary: Javac should wait and see if ambiguous methods can be reconciled at the end of an overload resolution round Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/tests/AbstractMerge.java ! test/tools/javac/resolve/tests/InnerOverOuter.java Changeset: 1908e86ee49a Author: darcy Date: 2013-07-01 11:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1908e86ee49a 7162089: Add support for repeating annotations to javax.annotation.processing Reviewed-by: abuckley, jjg, jfranck ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/javax/annotation/processing/AbstractProcessor.java ! src/share/classes/javax/annotation/processing/Processor.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java + test/tools/javac/processing/environment/round/TpAnno.java + test/tools/javac/processing/environment/round/TypeParameterAnnotations.java Changeset: 27a2e8c78bd0 Author: vromero Date: 2013-07-02 10:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/27a2e8c78bd0 8019397: javap does not show SourceDebugExtension properly Reviewed-by: jjg Contributed-by: dmytro_sheyko at hotmail.com ! src/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: 565341d436e2 Author: ksrini Date: 2013-07-01 16:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/565341d436e2 8019460: tests in changeset do not have @bug tag Reviewed-by: darcy ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.out ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary1.out ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary2.out ! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java Changeset: 3b4f92a3797f Author: vromero Date: 2013-07-02 22:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/3b4f92a3797f 6326693: variable x might already have been assigned, when assignment is in catch block Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.java + test/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.out Changeset: ce5a90df517b Author: lana Date: 2013-07-05 11:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/ce5a90df517b Merge Changeset: bdeef606be8e Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/bdeef606be8e Added tag jdk8-b98 for changeset ce5a90df517b ! .hgtags From valerie.peng at oracle.com Thu Jul 11 17:54:15 2013 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Fri, 12 Jul 2013 00:54:15 +0000 Subject: hg: jdk8/tl/jdk: 7 new changesets Message-ID: <20130712005547.CEC3448A0B@hg.openjdk.java.net> Changeset: f225da733291 Author: valeriep Date: 2013-07-05 13:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f225da733291 8012637: Adjust CipherInputStream class to work in AEAD/GCM mode Summary: Ensure the Cipher.doFinal() is called only once Reviewed-by: xuelei ! src/share/classes/javax/crypto/CipherInputStream.java + test/com/sun/crypto/provider/Cipher/AES/TestCICOWithGCM.java Changeset: 6e2a5637b286 Author: valeriep Date: 2013-07-05 13:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6e2a5637b286 7196805: DH Key interoperability testing between SunJCE and JsafeJCE not successful Summary: Check equality based on component values instead of encoding which may vary due to optional components Reviewed-by: weijun ! src/share/classes/com/sun/crypto/provider/DHKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/com/sun/crypto/provider/DHPublicKey.java ! src/share/classes/sun/security/pkcs11/P11Key.java Changeset: f321b78c7009 Author: ascarpino Date: 2013-07-08 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f321b78c7009 6755701: SunJCE DES/DESede SecretKeyFactory.generateSecret throws InvalidKeySpecExc if passed SecretKeySpec Reviewed-by: valeriep, wetmore, xuelei ! src/share/classes/com/sun/crypto/provider/DESKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java + test/com/sun/crypto/provider/Cipher/DES/DESSecretKeySpec.java Changeset: 869bfa39d923 Author: valeriep Date: 2013-07-08 11:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/869bfa39d923 Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java Changeset: 4fcac826628c Author: valeriep Date: 2013-07-09 15:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fcac826628c Merge Changeset: 7bd2993e03fa Author: valeriep Date: 2013-07-10 18:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bd2993e03fa 8020310: JDK-6356530 broke the old build Summary: Add serialVersionUID to AuthProvider and P11Key class. Reviewed-by: xuelei ! src/share/classes/java/security/AuthProvider.java ! src/share/classes/sun/security/pkcs11/P11Key.java Changeset: 4c95c032c395 Author: valeriep Date: 2013-07-11 17:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c95c032c395 Merge From david.holmes at oracle.com Thu Jul 11 19:31:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Jul 2013 12:31:29 +1000 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DECC71.2000803@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> <51DB4950.7080504@oracle.com> <51DB4A8A.7010205@oracle.com> <013d01ce7c9f$6d1f86b0$475e9410$@oracle.com> <51DC06A2.7040107@oracle.com> <01cf01ce7cb8$98058b90$c810a2b0$@oracle.com> <51DC4481.3000700@oracle.com> <036901ce7e40$e79436a0$b6bca3e0$@oracle.com> <51DECC71.2000803@oracle.com> Message-ID: <51DF6A81.9090106@oracle.com> On 12/07/2013 1:17 AM, Dmitry Samersoff wrote: > Peter, > > As UNIX_PATH_MAX is sort (108 bytes) we *must* check return value of > snprintf (e.g. ll.446 of attachListener_linux.cpp) and make sure it's > less or equal UNIX_PATH_MAX, otherwise we unlink wrong file in case of > UNIX_PATH_MAX overflow. As all the parts of the path are fixed in length I think an assert would suffice. Also minor style nit: if(ret needs space after "if". Thanks, David > -Dmitry > > > On 2013-07-11 18:14, Peter Allwin wrote: >> Hello, >> >> Thank you everyone for the feedback, I've incorporated the recommendations >> into a new revision: >> >> http://cr.openjdk.java.net/~allwin/7162400/webrev.02/ >> >> Changes: >> - Fixed speling misteaks >> - Added jtreg regression test using Mikael's excellent suggestion of >> -XX:+PauseAtStartup, tested locally on linux and solaris. >> - Reverted use of MAX_PATH+1 vs. UNIX_MAX_PATH >> >> >> Also thanks to Christian T?rnqvist for helping out with the jtreg test! >> >> /peter >> >>> -----Original Message----- >>> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >>> Sent: Tuesday, July 9, 2013 7:13 PM >>> To: Peter Allwin >>> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime- >>> dev at openjdk.java.net >>> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file >> number >>> during HotSpotVirtualMachine.executeCommand >>> >>> On 07/09/2013 05:25 PM, Peter Allwin wrote: >>>> Mikael, >>>> >>>> That's a good point, unfortunately attach uses os::get_temp_directory >>>> which is hardcoded to use /tmp. We could add a whitebox API to allow >>>> us to override this but now we're on the border to noreg-hard land again >>> IMO. >>>> >>>> Any other opinions on this? >>> >>> Can you use the "-XX:+PauseAtStartup" vm flag it will create a >>> vm.paused. file in the current work directory. You could extract the >> pid, >>> touch the correct attach file in /tmp and then remove the vm.paused to let >>> the VM resume. >>> >>> I didn't check if PauseAtStartup stops the VM early enough though. >>> >>> An alternate, even more hacky approach is to do something like (in bash): >>> (bash -c 'echo $$; touch /tmp/.java_pid$$; exec java -version') Where you >>> can extract the pid of the subshell process with $$ and then exec into the >>> java launcher and keep the same pid (at least on Linux, unsure about the >>> Solaris launcher). >>> >>> /Mikael >>> >>>> >>>> >>>> Thanks! >>>> >>>> /peter >>>> >>>>> -----Original Message----- >>>>> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >>>>> Sent: Tuesday, July 9, 2013 2:49 PM >>>>> To: Peter Allwin >>>>> Cc: serguei.spitsyn at oracle.com; daniel.daugherty at oracle.com; >>>>> serviceability-dev at openjdk.java.net; hotspot-runtime- >>>>> dev at openjdk.java.net >>>>> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file >>>> number >>>>> during HotSpotVirtualMachine.executeCommand >>>>> >>>>> Peter, >>>>> >>>>> On 2013-07-09 14:25, Peter Allwin wrote: >>>>>> Hello! >>>>>> >>>>>> It is reproducible by letting the test create .java_pid* files for >>>>>> all possible process id's on the system, setting correct access >>>>>> flags, launching the target VM and attempting to connect. There are >>>>>> some caveats though but it should be doable. >>>>>> >>>>>> I'll convert the repro script to JTREG and add it to the webrev. >>>>> >>>>> It's probably not a good idea to have a test which taints the system >>>>> with >>>> stale >>>>> .java_pid* files. >>>>> If the test execution times out and the script isn't allowed to clean >>>>> up I imagine that other subsequent executions could fail. >>>>> Is there a way to tell the attach api to use a specific directory so >>>>> you >>>> won't >>>>> need to taint /tmp? >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> Thanks for the reviews! >>>>>> >>>>>> /peter >>>>>> >>>>>> *From:*serguei.spitsyn at oracle.com >>>>>> [mailto:serguei.spitsyn at oracle.com] >>>>>> *Sent:* Tuesday, July 9, 2013 1:26 AM >>>>>> *To:* daniel.daugherty at oracle.com >>>>>> *Cc:* Peter Allwin; serviceability-dev at openjdk.java.net; >>>>>> hotspot-runtime-dev at openjdk.java.net >>>>>> *Subject:* Re: RFR 7162400: Intermittent java.io.IOException: Bad >>>>>> file number during HotSpotVirtualMachine.executeCommand >>>>>> >>>>>> Ok, thanks! >>>>>> >>>>>> Peter, did you manage to reproduce this issue with your script? >>>>>> If so, then, please, include it into the bug report and remove the >>>>>> "noreg-sqe" label. >>>>>> >>>>>> It is Ok if you did not reproduce it, though. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 7/8/13 4:20 PM, Daniel D. Daugherty wrote: >>>>>> >>>>>> I definitely don't insist... :-) >>>>>> >>>>>> BTW, I noticed this in Peter's e-mail: >>>>>> >>>>>> > Testing: >>>>>> > JPRT, reproducing script on Solaris, Linux. >>>>>> >>>>>> so maybe Peter already has this covered with "reproducing >> script"... >>>>>> >>>>>> Dan >>>>>> >>>>>> On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com >>>>>> wrote: >>>>>> >>>>>> Dan, >>>>>> >>>>>> Dan, thank you for the recommendation. >>>>>> But I'm still not sure it is a right thing to do. >>>>>> Even though, there are multiple test cases associated with >> this >>>>>> bug they >>>>>> can not be used to verify that fix because an additional >>>> condition >>>>>> must be present as well. >>>>>> This condition is a presence of stale door file which is not >>>>>> that easy to reproduce. >>>>>> >>>>>> However, if you insist then I can change the lable to the >>>>>> "noreg-sqe" >>>>>> with the corresponding comment. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: >>>>>> >>>>>> Serguei, >>>>>> >>>>>> There are a number of existing tests associated with this >>>>>> bug. I don't >>>>>> think that 'noreg-hard' is the right label. I think >>>>>> 'noreg-sqe' is >>>>>> the right one: >>>>>> >>>>>> noreg-sqe >>>>>> Change can be verified by running an existing SQE >> test >>>>>> suite; the bug >>>>>> should identify the suite and the specific test >>>> case(s). >>>>>> >>>>>> Dan >>>>>> >>>>>> On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com >>>>>> wrote: >>>>>> >>>>>> Peter, >>>>>> >>>>>> I've added the label "noreg-hard" with the comment to >>>>>> the report. >>>>>> It is not easy to reproduce the issue and demonstrate >>>>>> the fix in a regression test. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com >>>>>> wrote: >>>>>> >>>>>> Hi Peter, >>>>>> >>>>>> The fix looks good. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 7/8/13 6:54 AM, Peter Allwin wrote: >>>>>> >>>>>> Hello! >>>>>> >>>>>> Looking for reviews of this change: >>>>>> >>>>>> >>>> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ >>>>>> >>>>>> >>>>>> >>>>>> For CR: >>>>>> >>>>>> >>>>>> http://bugs.sun.com/view_bug.do?bug_id=7162400 >>>>>> >>>>>> >>>>>> https://jbs.oracle.com/bugs/browse/JDK-7162400 >>>>>> >>>>>> Summary: >>>>>> >>>>>> This change addresses an issue in the Attach >> API >>>>>> on Solaris, Linux and BSD where an attaching >>>>>> application can receive IOExceptions such as >>>>>> "Bad file number" (Solaris), "Connection >>>>>> refused" (Linux/BSD), or "well-known file is >> not >>>>>> secure". >>>>>> >>>>>> The attach process uses a file in the >> temporary >>>>>> directory as a door (Solaris) or domain >> socket >>>>>> (Linux,BSD) to communicate with the VM. In >>>>>> certain circumstances stale files can be left >> in >>>>>> the file system which can cause the attaching >>>>>> application to believe that the VM is ready >> to >>>>>> receive a connection when it's not. With this >>>>>> change the stale file will be removed during >> VM >>>>>> startup. >>>>>> >>>>>> Note that there is still an issue if we don't >>>>>> have permission to remove the stale file, the >>>>>> attaching process will fail to connect. >>>>>> >>>>>> Testing: >>>>>> >>>>>> JPRT, reproducing script on Solaris, Linux. >>>>>> >>>>>> Credits: >>>>>> >>>>>> Thanks to Staffan Larsen who worked on this >>>>>> issue with me. >>>>>> >>>>>> Regards, >>>>>> >>>>>> >>>>>> Peter >>>>>> >>>> >> >> > > From mandy.chung at oracle.com Fri Jul 12 04:21:17 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 12 Jul 2013 11:21:17 +0000 Subject: hg: jdk8/tl/jdk: 8014890: (ref) Reference queues may return more entries than expected Message-ID: <20130712112200.49AF248A2E@hg.openjdk.java.net> Changeset: 858c75eb83b5 Author: mchung Date: 2013-07-08 14:05 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/858c75eb83b5 8014890: (ref) Reference queues may return more entries than expected Summary: When enqueuing references check whether the j.l.r.Reference has already been enqeued or removed in the lock. Do not enqueue them again. This occurs because multiple threads may try to enqueue the same j.l.r.Reference at the same time. Reviewed-by: mchung, dholmes, plevart, shade Contributed-by: thomas.schatzl at oracle.com ! src/share/classes/java/lang/ref/Reference.java ! src/share/classes/java/lang/ref/ReferenceQueue.java + test/java/lang/ref/EnqueuePollRace.java From peter.allwin at oracle.com Fri Jul 12 04:32:17 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Fri, 12 Jul 2013 13:32:17 +0200 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <51DF6A81.9090106@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> <51DB4950.7080504@oracle.com> <51DB4A8A.7010205@oracle.com> <013d01ce7c9f$6d1f86b0$475e9410$@oracle.com> <51DC06A2.7040107@oracle.com> <01cf01ce7cb8$98058b90$c810a2b0$@oracle.com> <51DC4481.3000700@oracle.com> <036901ce7e40$e79436a0$b6bca3e0$@oracle.com> <51DECC71.2000803@oracle.com> <51DF6A81.9090106@oracle.com> Message-ID: <048801ce7ef3$7864d5b0$692e8110$@oracle.com> I'll add an assert on the return value and fix the if-formatting before the push if that's OK. Thanks again for the reviews! /peter > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Friday, July 12, 2013 4:31 AM > To: Peter Allwin > Cc: Dmitry Samersoff; serviceability-dev at openjdk.java.net; hotspot- > runtime-dev at openjdk.java.net > Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file number > during HotSpotVirtualMachine.executeCommand > > On 12/07/2013 1:17 AM, Dmitry Samersoff wrote: > > Peter, > > > > As UNIX_PATH_MAX is sort (108 bytes) we *must* check return value of > > snprintf (e.g. ll.446 of attachListener_linux.cpp) and make sure it's > > less or equal UNIX_PATH_MAX, otherwise we unlink wrong file in case of > > UNIX_PATH_MAX overflow. > > As all the parts of the path are fixed in length I think an assert would suffice. > > Also minor style nit: > > if(ret > > needs space after "if". > > Thanks, > David > > > -Dmitry > > > > > > On 2013-07-11 18:14, Peter Allwin wrote: > >> Hello, > >> > >> Thank you everyone for the feedback, I've incorporated the > >> recommendations into a new revision: > >> > >> http://cr.openjdk.java.net/~allwin/7162400/webrev.02/ > >> > >> Changes: > >> - Fixed speling misteaks > >> - Added jtreg regression test using Mikael's excellent suggestion > >> of -XX:+PauseAtStartup, tested locally on linux and solaris. > >> - Reverted use of MAX_PATH+1 vs. UNIX_MAX_PATH > >> > >> > >> Also thanks to Christian T?rnqvist for helping out with the jtreg test! > >> > >> /peter > >> > >>> -----Original Message----- > >>> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > >>> Sent: Tuesday, July 9, 2013 7:13 PM > >>> To: Peter Allwin > >>> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime- > >>> dev at openjdk.java.net > >>> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file > >> number > >>> during HotSpotVirtualMachine.executeCommand > >>> > >>> On 07/09/2013 05:25 PM, Peter Allwin wrote: > >>>> Mikael, > >>>> > >>>> That's a good point, unfortunately attach uses > >>>> os::get_temp_directory which is hardcoded to use /tmp. We could add > >>>> a whitebox API to allow us to override this but now we're on the > >>>> border to noreg-hard land again > >>> IMO. > >>>> > >>>> Any other opinions on this? > >>> > >>> Can you use the "-XX:+PauseAtStartup" vm flag it will create a > >>> vm.paused. file in the current work directory. You could > >>> extract the > >> pid, > >>> touch the correct attach file in /tmp and then remove the vm.paused > >>> to let the VM resume. > >>> > >>> I didn't check if PauseAtStartup stops the VM early enough though. > >>> > >>> An alternate, even more hacky approach is to do something like (in > bash): > >>> (bash -c 'echo $$; touch /tmp/.java_pid$$; exec java -version') > >>> Where you can extract the pid of the subshell process with $$ and > >>> then exec into the java launcher and keep the same pid (at least on > >>> Linux, unsure about the Solaris launcher). > >>> > >>> /Mikael > >>> > >>>> > >>>> > >>>> Thanks! > >>>> > >>>> /peter > >>>> > >>>>> -----Original Message----- > >>>>> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > >>>>> Sent: Tuesday, July 9, 2013 2:49 PM > >>>>> To: Peter Allwin > >>>>> Cc: serguei.spitsyn at oracle.com; daniel.daugherty at oracle.com; > >>>>> serviceability-dev at openjdk.java.net; hotspot-runtime- > >>>>> dev at openjdk.java.net > >>>>> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad > >>>>> file > >>>> number > >>>>> during HotSpotVirtualMachine.executeCommand > >>>>> > >>>>> Peter, > >>>>> > >>>>> On 2013-07-09 14:25, Peter Allwin wrote: > >>>>>> Hello! > >>>>>> > >>>>>> It is reproducible by letting the test create .java_pid* files > >>>>>> for all possible process id's on the system, setting correct > >>>>>> access flags, launching the target VM and attempting to connect. > >>>>>> There are some caveats though but it should be doable. > >>>>>> > >>>>>> I'll convert the repro script to JTREG and add it to the webrev. > >>>>> > >>>>> It's probably not a good idea to have a test which taints the > >>>>> system with > >>>> stale > >>>>> .java_pid* files. > >>>>> If the test execution times out and the script isn't allowed to > >>>>> clean up I imagine that other subsequent executions could fail. > >>>>> Is there a way to tell the attach api to use a specific directory > >>>>> so you > >>>> won't > >>>>> need to taint /tmp? > >>>>> > >>>>> /Mikael > >>>>> > >>>>>> > >>>>>> Thanks for the reviews! > >>>>>> > >>>>>> /peter > >>>>>> > >>>>>> *From:*serguei.spitsyn at oracle.com > >>>>>> [mailto:serguei.spitsyn at oracle.com] > >>>>>> *Sent:* Tuesday, July 9, 2013 1:26 AM > >>>>>> *To:* daniel.daugherty at oracle.com > >>>>>> *Cc:* Peter Allwin; serviceability-dev at openjdk.java.net; > >>>>>> hotspot-runtime-dev at openjdk.java.net > >>>>>> *Subject:* Re: RFR 7162400: Intermittent java.io.IOException: Bad > >>>>>> file number during HotSpotVirtualMachine.executeCommand > >>>>>> > >>>>>> Ok, thanks! > >>>>>> > >>>>>> Peter, did you manage to reproduce this issue with your script? > >>>>>> If so, then, please, include it into the bug report and remove > >>>>>> the "noreg-sqe" label. > >>>>>> > >>>>>> It is Ok if you did not reproduce it, though. > >>>>>> > >>>>>> Thanks, > >>>>>> Serguei > >>>>>> > >>>>>> > >>>>>> On 7/8/13 4:20 PM, Daniel D. Daugherty wrote: > >>>>>> > >>>>>> I definitely don't insist... :-) > >>>>>> > >>>>>> BTW, I noticed this in Peter's e-mail: > >>>>>> > >>>>>> > Testing: > >>>>>> > JPRT, reproducing script on Solaris, Linux. > >>>>>> > >>>>>> so maybe Peter already has this covered with "reproducing > >> script"... > >>>>>> > >>>>>> Dan > >>>>>> > >>>>>> On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com > >>>>>> wrote: > >>>>>> > >>>>>> Dan, > >>>>>> > >>>>>> Dan, thank you for the recommendation. > >>>>>> But I'm still not sure it is a right thing to do. > >>>>>> Even though, there are multiple test cases associated > >>>>>> with > >> this > >>>>>> bug they > >>>>>> can not be used to verify that fix because an > >>>>>> additional > >>>> condition > >>>>>> must be present as well. > >>>>>> This condition is a presence of stale door file which is not > >>>>>> that easy to reproduce. > >>>>>> > >>>>>> However, if you insist then I can change the lable to the > >>>>>> "noreg-sqe" > >>>>>> with the corresponding comment. > >>>>>> > >>>>>> Thanks, > >>>>>> Serguei > >>>>>> > >>>>>> > >>>>>> On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: > >>>>>> > >>>>>> Serguei, > >>>>>> > >>>>>> There are a number of existing tests associated with this > >>>>>> bug. I don't > >>>>>> think that 'noreg-hard' is the right label. I think > >>>>>> 'noreg-sqe' is > >>>>>> the right one: > >>>>>> > >>>>>> noreg-sqe > >>>>>> Change can be verified by running an existing > >>>>>> SQE > >> test > >>>>>> suite; the bug > >>>>>> should identify the suite and the specific > >>>>>> test > >>>> case(s). > >>>>>> > >>>>>> Dan > >>>>>> > >>>>>> On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com > >>>>>> wrote: > >>>>>> > >>>>>> Peter, > >>>>>> > >>>>>> I've added the label "noreg-hard" with the comment to > >>>>>> the report. > >>>>>> It is not easy to reproduce the issue and demonstrate > >>>>>> the fix in a regression test. > >>>>>> > >>>>>> Thanks, > >>>>>> Serguei > >>>>>> > >>>>>> > >>>>>> On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com > >>>>>> wrote: > >>>>>> > >>>>>> Hi Peter, > >>>>>> > >>>>>> The fix looks good. > >>>>>> > >>>>>> Thanks, > >>>>>> Serguei > >>>>>> > >>>>>> On 7/8/13 6:54 AM, Peter Allwin wrote: > >>>>>> > >>>>>> Hello! > >>>>>> > >>>>>> Looking for reviews of this change: > >>>>>> > >>>>>> > >>>> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ > >>>>>> > >>>>>> > >>>>>> > >>>>>> For CR: > >>>>>> > >>>>>> > >>>>>> http://bugs.sun.com/view_bug.do?bug_id=7162400 > >>>>>> > >>>>>> > >>>>>> https://jbs.oracle.com/bugs/browse/JDK-7162400 > >>>>>> > >>>>>> Summary: > >>>>>> > >>>>>> This change addresses an issue in the > >>>>>> Attach > >> API > >>>>>> on Solaris, Linux and BSD where an attaching > >>>>>> application can receive IOExceptions such as > >>>>>> "Bad file number" (Solaris), "Connection > >>>>>> refused" (Linux/BSD), or "well-known > >>>>>> file is > >> not > >>>>>> secure". > >>>>>> > >>>>>> The attach process uses a file in the > >> temporary > >>>>>> directory as a door (Solaris) or domain > >> socket > >>>>>> (Linux,BSD) to communicate with the VM. In > >>>>>> certain circumstances stale files can > >>>>>> be left > >> in > >>>>>> the file system which can cause the attaching > >>>>>> application to believe that the VM is > >>>>>> ready > >> to > >>>>>> receive a connection when it's not. With this > >>>>>> change the stale file will be removed > >>>>>> during > >> VM > >>>>>> startup. > >>>>>> > >>>>>> Note that there is still an issue if we don't > >>>>>> have permission to remove the stale file, the > >>>>>> attaching process will fail to connect. > >>>>>> > >>>>>> Testing: > >>>>>> > >>>>>> JPRT, reproducing script on Solaris, Linux. > >>>>>> > >>>>>> Credits: > >>>>>> > >>>>>> Thanks to Staffan Larsen who worked on this > >>>>>> issue with me. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> > >>>>>> Peter > >>>>>> > >>>> > >> > >> > > > > From olivier.lagneau at oracle.com Fri Jul 12 06:16:46 2013 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Fri, 12 Jul 2013 15:16:46 +0200 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <036901ce7e40$e79436a0$b6bca3e0$@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> <51DB4950.7080504@oracle.com> <51DB4A8A.7010205@oracle.com> <013d01ce7c9f$6d1f86b0$475e9410$@oracle.com> <51DC06A2.7040107@oracle.com> <01cf01ce7cb8$98058b90$c810a2b0$@oracle.com> <51DC4481.3000700@oracle.com> <036901ce7e40$e79436a0$b6bca3e0$@oracle.com> Message-ID: <51E001BE.30009@oracle.com> Hi Peter, Don't have time to review it, but just noticed that Copyright headers are not updated (2013). My 0.005 cents help, Olivier. Peter Allwin said on date 7/11/2013 4:14 PM: > Hello, > > Thank you everyone for the feedback, I've incorporated the recommendations > into a new revision: > > http://cr.openjdk.java.net/~allwin/7162400/webrev.02/ > > Changes: > - Fixed speling misteaks > - Added jtreg regression test using Mikael's excellent suggestion of > -XX:+PauseAtStartup, tested locally on linux and solaris. > - Reverted use of MAX_PATH+1 vs. UNIX_MAX_PATH > > > Also thanks to Christian T?rnqvist for helping out with the jtreg test! > > /peter > >> -----Original Message----- >> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >> Sent: Tuesday, July 9, 2013 7:13 PM >> To: Peter Allwin >> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file > number >> during HotSpotVirtualMachine.executeCommand >> >> On 07/09/2013 05:25 PM, Peter Allwin wrote: >>> Mikael, >>> >>> That's a good point, unfortunately attach uses os::get_temp_directory >>> which is hardcoded to use /tmp. We could add a whitebox API to allow >>> us to override this but now we're on the border to noreg-hard land again >> IMO. >>> Any other opinions on this? >> Can you use the "-XX:+PauseAtStartup" vm flag it will create a >> vm.paused. file in the current work directory. You could extract the > pid, >> touch the correct attach file in /tmp and then remove the vm.paused to let >> the VM resume. >> >> I didn't check if PauseAtStartup stops the VM early enough though. >> >> An alternate, even more hacky approach is to do something like (in bash): >> (bash -c 'echo $$; touch /tmp/.java_pid$$; exec java -version') Where you >> can extract the pid of the subshell process with $$ and then exec into the >> java launcher and keep the same pid (at least on Linux, unsure about the >> Solaris launcher). >> >> /Mikael >> >>> >>> Thanks! >>> >>> /peter >>> >>>> -----Original Message----- >>>> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >>>> Sent: Tuesday, July 9, 2013 2:49 PM >>>> To: Peter Allwin >>>> Cc: serguei.spitsyn at oracle.com; daniel.daugherty at oracle.com; >>>> serviceability-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file >>> number >>>> during HotSpotVirtualMachine.executeCommand >>>> >>>> Peter, >>>> >>>> On 2013-07-09 14:25, Peter Allwin wrote: >>>>> Hello! >>>>> >>>>> It is reproducible by letting the test create .java_pid* files for >>>>> all possible process id's on the system, setting correct access >>>>> flags, launching the target VM and attempting to connect. There are >>>>> some caveats though but it should be doable. >>>>> >>>>> I'll convert the repro script to JTREG and add it to the webrev. >>>> It's probably not a good idea to have a test which taints the system >>>> with >>> stale >>>> .java_pid* files. >>>> If the test execution times out and the script isn't allowed to clean >>>> up I imagine that other subsequent executions could fail. >>>> Is there a way to tell the attach api to use a specific directory so >>>> you >>> won't >>>> need to taint /tmp? >>>> >>>> /Mikael >>>> >>>>> Thanks for the reviews! >>>>> >>>>> /peter >>>>> >>>>> *From:*serguei.spitsyn at oracle.com >>>>> [mailto:serguei.spitsyn at oracle.com] >>>>> *Sent:* Tuesday, July 9, 2013 1:26 AM >>>>> *To:* daniel.daugherty at oracle.com >>>>> *Cc:* Peter Allwin; serviceability-dev at openjdk.java.net; >>>>> hotspot-runtime-dev at openjdk.java.net >>>>> *Subject:* Re: RFR 7162400: Intermittent java.io.IOException: Bad >>>>> file number during HotSpotVirtualMachine.executeCommand >>>>> >>>>> Ok, thanks! >>>>> >>>>> Peter, did you manage to reproduce this issue with your script? >>>>> If so, then, please, include it into the bug report and remove the >>>>> "noreg-sqe" label. >>>>> >>>>> It is Ok if you did not reproduce it, though. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 7/8/13 4:20 PM, Daniel D. Daugherty wrote: >>>>> >>>>> I definitely don't insist... :-) >>>>> >>>>> BTW, I noticed this in Peter's e-mail: >>>>> >>>>> > Testing: >>>>> > JPRT, reproducing script on Solaris, Linux. >>>>> >>>>> so maybe Peter already has this covered with "reproducing > script"... >>>>> Dan >>>>> >>>>> On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com >>>>> wrote: >>>>> >>>>> Dan, >>>>> >>>>> Dan, thank you for the recommendation. >>>>> But I'm still not sure it is a right thing to do. >>>>> Even though, there are multiple test cases associated with > this >>>>> bug they >>>>> can not be used to verify that fix because an additional >>> condition >>>>> must be present as well. >>>>> This condition is a presence of stale door file which is not >>>>> that easy to reproduce. >>>>> >>>>> However, if you insist then I can change the lable to the >>>>> "noreg-sqe" >>>>> with the corresponding comment. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: >>>>> >>>>> Serguei, >>>>> >>>>> There are a number of existing tests associated with this >>>>> bug. I don't >>>>> think that 'noreg-hard' is the right label. I think >>>>> 'noreg-sqe' is >>>>> the right one: >>>>> >>>>> noreg-sqe >>>>> Change can be verified by running an existing SQE > test >>>>> suite; the bug >>>>> should identify the suite and the specific test >>> case(s). >>>>> Dan >>>>> >>>>> On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com >>>>> wrote: >>>>> >>>>> Peter, >>>>> >>>>> I've added the label "noreg-hard" with the comment to >>>>> the report. >>>>> It is not easy to reproduce the issue and demonstrate >>>>> the fix in a regression test. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com >>>>> wrote: >>>>> >>>>> Hi Peter, >>>>> >>>>> The fix looks good. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 7/8/13 6:54 AM, Peter Allwin wrote: >>>>> >>>>> Hello! >>>>> >>>>> Looking for reviews of this change: >>>>> >>>>> >>> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ >>>>> >>>>> >>>>> For CR: >>>>> >>>>> >>>>> http://bugs.sun.com/view_bug.do?bug_id=7162400 >>>>> >>>>> >>>>> https://jbs.oracle.com/bugs/browse/JDK-7162400 >>>>> >>>>> Summary: >>>>> >>>>> This change addresses an issue in the Attach > API >>>>> on Solaris, Linux and BSD where an attaching >>>>> application can receive IOExceptions such as >>>>> "Bad file number" (Solaris), "Connection >>>>> refused" (Linux/BSD), or "well-known file is > not >>>>> secure". >>>>> >>>>> The attach process uses a file in the > temporary >>>>> directory as a door (Solaris) or domain > socket >>>>> (Linux,BSD) to communicate with the VM. In >>>>> certain circumstances stale files can be left > in >>>>> the file system which can cause the attaching >>>>> application to believe that the VM is ready > to >>>>> receive a connection when it's not. With this >>>>> change the stale file will be removed during > VM >>>>> startup. >>>>> >>>>> Note that there is still an issue if we don't >>>>> have permission to remove the stale file, the >>>>> attaching process will fail to connect. >>>>> >>>>> Testing: >>>>> >>>>> JPRT, reproducing script on Solaris, Linux. >>>>> >>>>> Credits: >>>>> >>>>> Thanks to Staffan Larsen who worked on this >>>>> issue with me. >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Peter >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130712/90dac273/attachment.html From dmitry.samersoff at oracle.com Fri Jul 12 06:31:16 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Fri, 12 Jul 2013 17:31:16 +0400 Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <048801ce7ef3$7864d5b0$692e8110$@oracle.com> References: <004101ce7be2$bd046410$370d2c30$@oracle.com> <51DB06B9.10509@oracle.com> <51DB0BFD.6040508@oracle.com> <51DB4139.6010106@oracle.com> <51DB462D.5010300@oracle.com> <51DB4950.7080504@oracle.com> <51DB4A8A.7010205@oracle.com> <013d01ce7c9f$6d1f86b0$475e9410$@oracle.com> <51DC06A2.7040107@oracle.com> <01cf01ce7cb8$98058b90$c810a2b0$@oracle.com> <51DC4481.3000700@oracle.com> <036901ce7e40$e79436a0$b6bca3e0$@oracle.com> <51DECC71.2000803@oracle.com> <51DF6A81.9090106@oracle.com> <048801ce7ef3$7864d5b0$692e8110$@oracle.com> Message-ID: Peter, thank you! I'm Ok with push. --Dmitry -----Original Message----- From: Peter Allwin To: 'David Holmes' Cc: serviceability-dev at openjdk.java.net, hotspot-runtime-dev at openjdk.java.net Sent: Fri, 12 Jul 2013 15:34 Subject: RE: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand I'll add an assert on the return value and fix the if-formatting before the push if that's OK. Thanks again for the reviews! /peter > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Friday, July 12, 2013 4:31 AM > To: Peter Allwin > Cc: Dmitry Samersoff; serviceability-dev at openjdk.java.net; hotspot- > runtime-dev at openjdk.java.net > Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file number > during HotSpotVirtualMachine.executeCommand > > On 12/07/2013 1:17 AM, Dmitry Samersoff wrote: > > Peter, > > > > As UNIX_PATH_MAX is sort (108 bytes) we *must* check return value of > > snprintf (e.g. ll.446 of attachListener_linux.cpp) and make sure it's > > less or equal UNIX_PATH_MAX, otherwise we unlink wrong file in case of > > UNIX_PATH_MAX overflow. > > As all the parts of the path are fixed in length I think an assert would suffice. > > Also minor style nit: > > if(ret > > needs space after "if". > > Thanks, > David > > > -Dmitry > > > > > > On 2013-07-11 18:14, Peter Allwin wrote: > >> Hello, > >> > >> Thank you everyone for the feedback, I've incorporated the > >> recommendations into a new revision: > >> > >> http://cr.openjdk.java.net/~allwin/7162400/webrev.02/ > >> > >> Changes: > >> - Fixed speling misteaks > >> - Added jtreg regression test using Mikael's excellent suggestion > >> of -XX:+PauseAtStartup, tested locally on linux and solaris. > >> - Reverted use of MAX_PATH+1 vs. UNIX_MAX_PATH > >> > >> > >> Also thanks to Christian T?rnqvist for helping out with the jtreg test! > >> > >> /peter > >> > >>> -----Original Message----- > >>> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > >>> Sent: Tuesday, July 9, 2013 7:13 PM > >>> To: Peter Allwin > >>> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime- > >>> dev at openjdk.java.net > >>> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file > >> number > >>> during HotSpotVirtualMachine.executeCommand > >>> > >>> On 07/09/2013 05:25 PM, Peter Allwin wrote: > >>>> Mikael, > >>>> > >>>> That's a good point, unfortunately attach uses > >>>> os::get_temp_directory which is hardcoded to use /tmp. We could add > >>>> a whitebox API to allow us to override this but now we're on the > >>>> border to noreg-hard land again > >>> IMO. > >>>> > >>>> Any other opinions on this? > >>> > >>> Can you use the "-XX:+PauseAtStartup" vm flag it will create a > >>> vm.paused. file in the current work directory. You could > >>> extract the > >> pid, > >>> touch the correct attach file in /tmp and then remove the vm.paused > >>> to let the VM resume. > >>> > >>> I didn't check if PauseAtStartup stops the VM early enough though. > >>> > >>> An alternate, even more hacky approach is to do something like (in > bash): > >>> (bash -c 'echo $$; touch /tmp/.java_pid$$; exec java -version') > >>> Where you can extract the pid of the subshell process with $$ and > >>> then exec into the java launcher and keep the same pid (at least on > >>> Linux, unsure about the Solaris launcher). > >>> > >>> /Mikael > >>> > >>>> > >>>> > >>>> Thanks! > >>>> > >>>> /peter > >>>> > >>>>> -----Original Message----- > >>>>> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > >>>>> Sent: Tuesday, July 9, 2013 2:49 PM > >>>>> To: Peter Allwin > >>>>> Cc: serguei.spitsyn at oracle.com; daniel.daugherty at oracle.com; > >>>>> serviceability-dev at openjdk.java.net; hotspot-runtime- > >>>>> dev at openjdk.java.net > >>>>> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad > >>>>> file > >>>> number > >>>>> during HotSpotVirtualMachine.executeCommand > >>>>> > >>>>> Peter, > >>>>> > >>>>> On 2013-07-09 14:25, Peter Allwin wrote: > >>>>>> Hello! > >>>>>> > >>>>>> It is reproducible by letting the test create .java_pid* files > >>>>>> for all possible process id's on the system, setting correct > >>>>>> access flags, launching the target VM and attempting to connect. > >>>>>> There are some caveats though but it should be doable. > >>>>>> > >>>>>> I'll convert the repro script to JTREG and add it to the webrev. > >>>>> > >>>>> It's probably not a good idea to have a test which taints the > >>>>> system with > >>>> stale > >>>>> .java_pid* files. > >>>>> If the test execution times out and the script isn't allowed to > >>>>> clean up I imagine that other subsequent executions could fail. > >>>>> Is there a way to tell the attach api to use a specific directory > >>>>> so you > >>>> won't > >>>>> need to taint /tmp? > >>>>> > >>>>> /Mikael > >>>>> > >>>>>> > >>>>>> Thanks for the reviews! > >>>>>> > >>>>>> /peter > >>>>>> > >>>>>> *From:*serguei.spitsyn at oracle.com > >>>>>> [mailto:serguei.spitsyn at oracle.com] > >>>>>> *Sent:* Tuesday, July 9, 2013 1:26 AM > >>>>>> *To:* daniel.daugherty at oracle.com > >>>>>> *Cc:* Peter Allwin; serviceability-dev at openjdk.java.net; > >>>>>> hotspot-runtime-dev at openjdk.java.net > >>>>>> *Subject:* Re: RFR 7162400: Intermittent java.io.IOException: Bad > >>>>>> file number during HotSpotVirtualMachine.executeCommand > >>>>>> > >>>>>> Ok, thanks! > >>>>>> > >>>>>> Peter, did you manage to reproduce this issue with your script? > >>>>>> If so, then, please, include it into the bug report and remove > >>>>>> the "noreg-sqe" label. > >>>>>> > >>>>>> It is Ok if you did not reproduce it, though. > >>>>>> > >>>>>> Thanks, > >>>>>> Serguei > >>>>>> > >>>>>> > >>>>>> On 7/8/13 4:20 PM, Daniel D. Daugherty wrote: > >>>>>> > >>>>>> I definitely don't insist... :-) > >>>>>> > >>>>>> BTW, I noticed this in Peter's e-mail: > >>>>>> > >>>>>> > Testing: > >>>>>> > JPRT, reproducing script on Solaris, Linux. > >>>>>> > >>>>>> so maybe Peter already has this covered with "reproducing > >> script"... > >>>>>> > >>>>>> Dan > >>>>>> > >>>>>> On 7/8/13 5:07 PM, serguei.spitsyn at oracle.com > >>>>>> wrote: > >>>>>> > >>>>>> Dan, > >>>>>> > >>>>>> Dan, thank you for the recommendation. > >>>>>> But I'm still not sure it is a right thing to do. > >>>>>> Even though, there are multiple test cases associated > >>>>>> with > >> this > >>>>>> bug they > >>>>>> can not be used to verify that fix because an > >>>>>> additional > >>>> condition > >>>>>> must be present as well. > >>>>>> This condition is a presence of stale door file which is not > >>>>>> that easy to reproduce. > >>>>>> > >>>>>> However, if you insist then I can change the lable to the > >>>>>> "noreg-sqe" > >>>>>> with the corresponding comment. > >>>>>> > >>>>>> Thanks, > >>>>>> Serguei > >>>>>> > >>>>>> > >>>>>> On 7/8/13 3:46 PM, Daniel D. Daugherty wrote: > >>>>>> > >>>>>> Serguei, > >>>>>> > >>>>>> There are a number of existing tests associated with this > >>>>>> bug. I don't > >>>>>> think that 'noreg-hard' is the right label. I think > >>>>>> 'noreg-sqe' is > >>>>>> the right one: > >>>>>> > >>>>>> noreg-sqe > >>>>>> Change can be verified by running an existing > >>>>>> SQE > >> test > >>>>>> suite; the bug > >>>>>> should identify the suite and the specific > >>>>>> test > >>>> case(s). > >>>>>> > >>>>>> Dan > >>>>>> > >>>>>> On 7/8/13 12:59 PM, serguei.spitsyn at oracle.com > >>>>>> wrote: > >>>>>> > >>>>>> Peter, > >>>>>> > >>>>>> I've added the label "noreg-hard" with the comment to > >>>>>> the report. > >>>>>> It is not easy to reproduce the issue and demonstrate > >>>>>> the fix in a regression test. > >>>>>> > >>>>>> Thanks, > >>>>>> Serguei > >>>>>> > >>>>>> > >>>>>> On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com > >>>>>> wrote: > >>>>>> > >>>>>> Hi Peter, > >>>>>> > >>>>>> The fix looks good. > >>>>>> > >>>>>> Thanks, > >>>>>> Serguei > >>>>>> > >>>>>> On 7/8/13 6:54 AM, Peter Allwin wrote: > >>>>>> > >>>>>> Hello! > >>>>>> > >>>>>> Looking for reviews of this change: > >>>>>> > >>>>>> > >>>> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ > >>>>>> > >>>>>> > >>>>>> > >>>>>> For CR: > >>>>>> > >>>>>> > >>>>>> http://bugs.sun.com/view_bug.do?bug_id=7162400 > >>>>>> > >>>>>> > >>>>>> https://jbs.oracle.com/bugs/browse/JDK-7162400 > >>>>>> > >>>>>> Summary: > >>>>>> > >>>>>> This change addresses an issue in the > >>>>>> Attach > >> API > >>>>>> on Solaris, Linux and BSD where an attaching > >>>>>> application can receive IOExceptions such as > >>>>>> "Bad file number" (Solaris), "Connection > >>>>>> refused" (Linux/BSD), or "well-known > >>>>>> file is > >> not > >>>>>> secure". > >>>>>> > >>>>>> The attach process uses a file in the > >> temporary > >>>>>> directory as a door (Solaris) or domain > >> socket > >>>>>> (Linux,BSD) to communicate with the VM. In > >>>>>> certain circumstances stale files can > >>>>>> be left > >> in > >>>>>> the file system which can cause the attaching > >>>>>> application to believe that the VM is > >>>>>> ready > >> to > >>>>>> receive a connection when it's not. With this > >>>>>> change the stale file will be removed > >>>>>> during > >> VM > >>>>>> startup. > >>>>>> > >>>>>> Note that there is still an issue if we don't > >>>>>> have permission to remove the stale file, the > >>>>>> attaching process will fail to connect. > >>>>>> > >>>>>> Testing: > >>>>>> > >>>>>> JPRT, reproducing script on Solaris, Linux. > >>>>>> > >>>>>> Credits: > >>>>>> > >>>>>> Thanks to Staffan Larsen who worked on this > >>>>>> issue with me. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> > >>>>>> Peter > >>>>>> > >>>> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130712/1e2d0aa0/attachment-0001.html From zhengyu.gu at oracle.com Fri Jul 12 07:25:57 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Fri, 12 Jul 2013 14:25:57 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130712142605.0926548A35@hg.openjdk.java.net> Changeset: c9a5fab39234 Author: zgu Date: 2013-07-11 13:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c9a5fab39234 8012241: NMT huge memory footprint, it usually leads to OOME Summary: Enforce memory limitation on NMT to prevent JVM OOM Reviewed-by: acorn, dcubed, minqi ! src/share/vm/services/memTracker.cpp Changeset: 5f056abe17c6 Author: zgu Date: 2013-07-12 04:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5f056abe17c6 Merge From sundararajan.athijegannathan at oracle.com Fri Jul 12 08:22:59 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 12 Jul 2013 15:22:59 +0000 Subject: hg: jdk8/tl/nashorn: 18 new changesets Message-ID: <20130712152315.667E148A38@hg.openjdk.java.net> Changeset: 5106d43feed7 Author: hannesw Date: 2013-07-08 19:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5106d43feed7 8019963: empty char range in regex Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java + test/script/basic/JDK-8019963.js + test/script/basic/JDK-8019963.js.EXPECTED Changeset: d3f4e5dea634 Author: attila Date: 2013-07-09 13:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d3f4e5dea634 8009758: reactivate the 8006529 test. Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/FunctionScope.java - test/script/currently-failing/JDK-8006529.js + test/script/trusted/JDK-8006529.js Changeset: 7538a59ca241 Author: sundar Date: 2013-07-09 17:37 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7538a59ca241 8014785: Ability to extend global instance by binding properties of another object Reviewed-by: attila, hannesw, jlaskey, lagergren ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/linker/InvokeByName.java + test/script/basic/JDK-8014785.js + test/script/basic/JDK-8014785.js.EXPECTED Changeset: d480015ab732 Author: lagergren Date: 2013-07-09 15:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d480015ab732 8020124: In the case of an eval switch, we might need explicit conversions of the tag store, as it was not known in the surrounding environment. Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8020124.js Changeset: 997a3215744a Author: sundar Date: 2013-07-10 13:25 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/997a3215744a 8020224: LinkageError: attempted duplicate class definition when --loader-per-compiler=false Reviewed-by: hannesw ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java Changeset: a9b74daed4f9 Author: hannesw Date: 2013-07-10 10:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a9b74daed4f9 8016681: regex capture behaves differently than on V8 Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8016681.js + test/script/basic/JDK-8016681.js.EXPECTED Changeset: c501b1666bda Author: sundar Date: 2013-07-10 19:08 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c501b1666bda 8020276: interface checks in Invocable.getInterface implementation Reviewed-by: jlaskey, hannesw, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 798e3aa19718 Author: sundar Date: 2013-07-11 16:34 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/798e3aa19718 8020325: static property does not work on accessible, public classes Reviewed-by: attila, hannesw, lagergren ! make/build.xml ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/lookup/Lookup.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java + test/script/basic/JDK-8020325.js + test/script/basic/JDK-8020325.js.EXPECTED ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 58614b556a0d Author: sundar Date: 2013-07-11 18:23 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/58614b556a0d 8020380: __noSuchProperty__ defined in mozilla_compat.js script should be non-enumerable Reviewed-by: jlaskey, hannesw, attila ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8020380.js Changeset: 2c007a8bb0e7 Author: attila Date: 2013-07-11 18:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2c007a8bb0e7 8013925: Remove symbol fields from nodes that don't need them Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/RangeAnalyzer.java ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java + src/jdk/nashorn/internal/ir/BlockStatement.java ! src/jdk/nashorn/internal/ir/BreakableNode.java + src/jdk/nashorn/internal/ir/BreakableStatement.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java - src/jdk/nashorn/internal/ir/ExecuteNode.java + src/jdk/nashorn/internal/ir/Expression.java + src/jdk/nashorn/internal/ir/ExpressionStatement.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java + src/jdk/nashorn/internal/ir/LexicalContextExpression.java ! src/jdk/nashorn/internal/ir/LexicalContextNode.java + src/jdk/nashorn/internal/ir/LexicalContextStatement.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/LoopNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/PropertyNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/TemporarySymbols.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! test/script/trusted/JDK-8006529.js Changeset: 9083af56bbcb Author: sundar Date: 2013-07-11 22:58 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9083af56bbcb 8012191: noSuchProperty can't cope with vararg functions Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/runtime/ScriptFunction.java + test/script/basic/JDK-8012191.js + test/script/basic/JDK-8012191.js.EXPECTED Changeset: 289923785ada Author: attila Date: 2013-07-11 22:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/289923785ada 8020125: PrintVisitor wasn't printing bodies of FunctionNode within UnaryNode Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java Changeset: d763da247244 Author: sundar Date: 2013-07-12 15:01 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d763da247244 8020437: Wrong handling of line numbers with multiline string literals Reviewed-by: attila, lagergren ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8020437.js + test/script/basic/JDK-8020437.js.EXPECTED + test/script/error/JDK-8020437-2.js + test/script/error/JDK-8020437-2.js.EXPECTED + test/script/error/JDK-8020437.js + test/script/error/JDK-8020437.js.EXPECTED Changeset: 1a6b1799f533 Author: sundar Date: 2013-07-12 15:27 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1a6b1799f533 8020223: ClassCastException: String can not be casted to ScriptFunction Reviewed-by: attila, lagergren ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8020223.js Changeset: e27ebcfed6fa Author: attila Date: 2013-07-12 11:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e27ebcfed6fa 8019822: Duplicate name and signature in finally block Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8019822.js Changeset: 8108ba8366fd Author: sundar Date: 2013-07-12 20:12 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8108ba8366fd Merge - src/jdk/nashorn/internal/ir/ExecuteNode.java - test/script/currently-failing/JDK-8006529.js Changeset: 5cdf4352ee0b Author: sundar Date: 2013-07-12 20:06 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5cdf4352ee0b 8020463: Input argument array wrapping in loadWithNewGlobal is wrong Reviewed-by: attila, jlaskey ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8020463.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: cbfeffbcd3f2 Author: sundar Date: 2013-07-12 20:13 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/cbfeffbcd3f2 Merge From huizhe.wang at oracle.com Fri Jul 12 11:13:44 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Fri, 12 Jul 2013 18:13:44 +0000 Subject: hg: jdk8/tl/jaxp: 8020430: NullPointerException in xml sqe nightly result on 2013-07-12 Message-ID: <20130712181348.5E00248A3F@hg.openjdk.java.net> Changeset: aabe15fc346f Author: joehw Date: 2013-07-12 11:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/aabe15fc346f 8020430: NullPointerException in xml sqe nightly result on 2013-07-12 Reviewed-by: chegar, lancea ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java From huizhe.wang at oracle.com Fri Jul 12 11:20:30 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Fri, 12 Jul 2013 18:20:30 +0000 Subject: hg: jdk8/tl/jdk: 8020430: NullPointerException in xml sqe nightly result on 2013-07-12 Message-ID: <20130712182052.C7B9648A40@hg.openjdk.java.net> Changeset: 2504f01bc83f Author: joehw Date: 2013-07-12 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2504f01bc83f 8020430: NullPointerException in xml sqe nightly result on 2013-07-12 Reviewed-by: chegar, lancea + test/javax/xml/jaxp/common/8020430/JAXP15RegTest.java + test/javax/xml/jaxp/common/8020430/TestBase.java From joe.darcy at oracle.com Fri Jul 12 11:48:40 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 12 Jul 2013 18:48:40 +0000 Subject: hg: jdk8/tl/jdk: 8010679: Clarify "present" and annotation ordering in Core Reflection for Annotations Message-ID: <20130712184852.8A73348A41@hg.openjdk.java.net> Changeset: af62c6175f92 Author: darcy Date: 2013-07-12 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af62c6175f92 8010679: Clarify "present" and annotation ordering in Core Reflection for Annotations Reviewed-by: abuckley, jfranck ! src/share/classes/java/lang/reflect/AnnotatedElement.java From paul.sandoz at oracle.com Fri Jul 12 12:32:38 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 12 Jul 2013 19:32:38 +0000 Subject: hg: jdk8/tl/jdk: 8019395: Consolidate StreamSupport.{stream, parallelStream} into a single method Message-ID: <20130712193250.978A848A46@hg.openjdk.java.net> Changeset: be096613bfb5 Author: psandoz Date: 2013-07-03 21:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be096613bfb5 8019395: Consolidate StreamSupport.{stream,parallelStream} into a single method Reviewed-by: henryjen, briangoetz ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/StreamSupport.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/zip/ZipFile.java ! test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/TestData.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java From vincent.x.ryan at oracle.com Fri Jul 12 12:45:49 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 12 Jul 2013 19:45:49 +0000 Subject: hg: jdk8/tl/jdk: 8019627: RuntimeException gets obscured during OCSP cert revocation checking Message-ID: <20130712194602.3A5D648A47@hg.openjdk.java.net> Changeset: b3ca5fb77e2c Author: vinnie Date: 2013-07-12 20:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3ca5fb77e2c 8019627: RuntimeException gets obscured during OCSP cert revocation checking Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java From mike.duigou at oracle.com Fri Jul 12 12:16:52 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 12 Jul 2013 19:16:52 +0000 Subject: hg: jdk8/tl/jdk: 4 new changesets Message-ID: <20130712191742.313E348A42@hg.openjdk.java.net> Changeset: fe6e4e2c367d Author: mduigou Date: 2013-07-12 11:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe6e4e2c367d 7129185: Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} Reviewed-by: dmocek, martin, smarks ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/NavigableSet.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collections/CheckedIdentityMap.java ! test/java/util/Collections/CheckedMapBash.java ! test/java/util/Collections/CheckedSetBash.java ! test/java/util/Collections/EmptyCollectionSerialization.java + test/java/util/Collections/EmptyNavigableMap.java + test/java/util/Collections/EmptyNavigableSet.java - test/java/util/Collections/EmptySortedSet.java ! test/java/util/Map/LockStep.java ! test/java/util/NavigableMap/LockStep.java Changeset: 623a10b23ed8 Author: mduigou Date: 2013-07-12 11:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/623a10b23ed8 8015317: Optional.filter, map, and flatMap Reviewed-by: psandoz, mduigou Contributed-by: brian.goetz at oracle.com, henry.jen at oracle.com ! src/share/classes/java/util/Optional.java ! src/share/classes/java/util/OptionalDouble.java ! src/share/classes/java/util/OptionalInt.java ! src/share/classes/java/util/OptionalLong.java ! test/java/util/Optional/Basic.java Changeset: 06749efce430 Author: mduigou Date: 2013-07-12 12:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06749efce430 8015315: Stream.concat methods Reviewed-by: psandoz, mduigou Contributed-by: brian.goetz at oracle.com, henry.jen at oracle.com ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java Changeset: 5b6f94559589 Author: mduigou Date: 2013-07-12 12:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b6f94559589 Merge - test/java/util/Collections/EmptySortedSet.java From jonathan.gibbons at oracle.com Fri Jul 12 13:11:17 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 12 Jul 2013 20:11:17 +0000 Subject: hg: jdk8/tl/langtools: 8020278: NPE in javadoc Message-ID: <20130712201123.E123248A48@hg.openjdk.java.net> Changeset: 37031963493e Author: jjg Date: 2013-07-12 13:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/37031963493e 8020278: NPE in javadoc Reviewed-by: mcimadamore, vromero ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/Env.java + test/tools/doclint/BadPackageCommentTest.java + test/tools/doclint/BadPackageCommentTest.out From christian.tornqvist at oracle.com Fri Jul 12 13:19:51 2013 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Fri, 12 Jul 2013 20:19:51 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130712201957.A897048A49@hg.openjdk.java.net> Changeset: 2e8f19c2feef Author: allwin Date: 2013-07-12 18:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2e8f19c2feef 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Summary: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Reviewed-by: dcubed, dholmes, sspitsyn, mgerdin, ctornqvi, dsamersoff ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/linux/vm/attachListener_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/windows/vm/attachListener_windows.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/attachListener.hpp + test/serviceability/attach/AttachWithStalePidFile.java + test/serviceability/attach/AttachWithStalePidFileTarget.java Changeset: c0cb474be37e Author: ctornqvi Date: 2013-07-12 20:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c0cb474be37e Merge From jiangli.zhou at oracle.com Fri Jul 12 13:55:25 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 12 Jul 2013 13:55:25 -0700 Subject: Request for review:8020309:Remove InstanceKlass::_cached_class_file_len and record the length together with the cached class file bytes In-Reply-To: <51DE695B.1020600@oracle.com> References: <51DDF518.6020303@oracle.com> <51DE0218.9090107@oracle.com> <51DE0CEA.5010501@oracle.com> <51DE695B.1020600@oracle.com> Message-ID: <51E06D3D.2020100@oracle.com> Hi Ioi and Serguei, Here is the updated the webrev: http://cr.openjdk.java.net/~jiangli/8020309/webrev.01/. I've retested with nsk.jvmti, nsk.jdi and nsk.hprof. I'm rerunning the JPRT and rest of the tests. Thanks, Jiangli On 07/11/2013 01:14 AM, serguei.spitsyn at oracle.com wrote: > Hi Jiangli, > > I like the Ioi's sugestion. > It will help to avoid the manipulations with offsets that look as > unnecessary complexity. > > Thanks, > Serguei > > > On 7/10/13 6:39 PM, Jiangli Zhou wrote: >> Hi Ioi, >> >> That's good suggestion. Let me look into it. >> >> Thanks! >> >> Jiangli >> >> On 07/10/2013 05:53 PM, Ioi Lam wrote: >>> Hi Jiangli, >>> >>> I think it's better to move the logic of deciding the length into >>> JVMTI. E.g., have something like >>> >>> struct JvmtiCachedClassFileData { >>> int _length; >>> unsigned char data[1]; >>> }; >>> >>> void >>> instanceKlass::set_jvmti_cached_class_file_data(JvmtiCachedClassFileData >>> *data); >>> >>> - Ioi >>> >>> On 07/10/2013 04:58 PM, Jiangli Zhou wrote: >>>> Hi, >>>> >>>> Please review the webrev for JDK-8020309 >>>> : >>>> >>>> http://cr.openjdk.java.net/~jiangli/8020309/webrev.00/ >>>> >>>> The _cached_class_file_bytes and _cached_class_file_len are not >>>> set/used if no jvmti agent is attached. The _cached_class_file_len >>>> field can be eliminated and the file length can be recorded as part >>>> of the cached class data in _cached_class_file_bytes for redefined >>>> class. The above change allocates extra 4bytes when allocating >>>> memory for cached class file and stores the length as the first >>>> 4bytes and the file data as the rest. It saves 4 bytes per class. >>>> For classes redefined, the memory usage is the same. >>>> >>>> Tested with following tests and JPRT: >>>> >>>> jdk/test/java/lang/instrument >>>> jdk/test/com/sun/jdi >>>> nsk.jvmti >>>> nsk.jdi >>>> nsk.hprof >>>> >>>> Thanks, >>>> Jiangli >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130712/0a70188c/attachment.html From john.r.rose at oracle.com Fri Jul 12 15:15:44 2013 From: john.r.rose at oracle.com (John Rose) Date: Fri, 12 Jul 2013 15:15:44 -0700 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: <9DA4C2B3-4923-4C02-AED8-62E3AE0CB502@oracle.com> References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> <0D743CDF-C8AB-421C-8D20-C29F08104642@oracle.com> <9DA4C2B3-4923-4C02-AED8-62E3AE0CB502@oracle.com> Message-ID: <1E59732F-8B2D-44EC-94AA-838B36E40790@oracle.com> It's good. One comment: The new overloading of aux. function entry_frame_is_first(_) belongs somewhere else. Since it doesn't really use frame::this, it is confusing as an overload beside a function that does use frame::this. Suggest placing it in JavaCallWrapper not frame. ? John On Jul 10, 2013, at 4:59 AM, Rickard B?ckman wrote: > Still looking for a Reviewer. > > Thanks > /R > > On Jul 8, 2013, at 5:49 PM, Rickard B?ckman wrote: > >> Thanks Markus! >> >> /R >> >> On Jul 8, 2013, at 5:45 PM, Markus Gr?nlund wrote: >> >>> Rickard, >>> >>> I think it looks good (not a Reviewer). >>> >>> Cheers >>> Markus >>> >>> -----Original Message----- >>> From: Rickard B?ckman >>> Sent: den 4 juli 2013 11:30 >>> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>> Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' >>> >>> Hi, >>> >>> can I please have a couple of reviews for this change? >>> >>> The problem in this crash was that we were given an incorrect fp (in this case 0x0) and had a pc that matched the C -> Java entry frame. The code then dereferenced fp +- offset. >>> >>> This change verifies that the fp +- offset is actually on the stack of the thread before doing the derefencing. >>> >>> Webrev: http://cr.openjdk.java.net/~rbackman/8016131/ >>> >>> Thanks >>> /R >> > From jeremymanson at google.com Fri Jul 12 15:21:46 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 12 Jul 2013 15:21:46 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51DDB632.4050805@oracle.com> References: <51D494E9.2020200@oracle.com> <51DDB632.4050805@oracle.com> Message-ID: Okay. I'd be happy to talk about what we did, if you think it would be of interest. All invocations of the JVM at Google use the same JVMTI agent. We're moving to a model where everyone builds their own launcher [1], so the obvious thing for us to do was combine the launcher and the agent statically, which simplifies our deployment and matches better with other parts of the Google workflow. However, we weren't too worried about people statically linking in multiple agents, so we didn't put in support for that. We will certainly use what you are doing, since that gives us said support for free (plus, it will be more work not to use it when we move to HS25). In that model, having a VM flag to grab an agent out of the launcher makes some sense, but it's also useful for people like me in debugging scenarios to build a separate agent, pass it with -agentlib and/or -agentpath, and override the one in the launcher. Arguably, I'm not your use case. Although, having said that, perhaps I am - I'm the only one I know who is already statically linking JNI and JVMTI in a production context! [1] Actually, they will build a single static self-executing JAR file containing their own launcher, which statically links in all of their JNI and our JVMTI agent, and all the classes their application needs. There is lots of overlap with JEP178, as you can see. Jeremy On Wed, Jul 10, 2013 at 12:29 PM, BILL PITTORE wrote: > On 7/3/2013 6:32 PM, Jeremy Manson wrote: > > I know that this is mentioned in the JEP, but does it really make sense to > have -agentpath work here, rather than just -agentlib? I would think that > specifying a full pathname and getting the library loaded out of the > launcher would be a little surprising to people who are basically saying > "please load this agent from the given path". > > Also, in practice, we do something very similar at Google, and, when > testing, I find it occasionally useful to be able to say "please load this > agent on the command line via the agentpath I gave you, rather than loading > the one with the same name I baked into the launcher". > > (FWIW, when we did this internally at Google, we added a special -XX > flag for when the agent is in the launcher. I know that you don't want to > go that way, though.) > > Thanks for the comments. I would say the thinking here is that we want > this to be as transparent as possible to the end user. In our view of the > end user is someone perhaps using an IDE and the actual execution of the VM > with agent arguments is hidden. In your case it sounds like you are > actually developing agents which is a whole different ball game. I could > certainly see adding a -XX argument that forces agentpath to load the > external library which would be good for agent development and debugging. > No need to relink the entire VM with the new agent. Our tech lead is out on > vacation this week so I'll bring this up when he's back. > > bill > > > > On Wed, Jul 3, 2013 at 2:17 PM, BILL PITTORE wrote: > >> These changes address bug 8014135 which adds support for statically >> linked agents in the VM. This is a followup to the recent JNI spec changes >> that addressed statically linked JNI libraries( 8005716). >> The JEP for this change is the same JEP as the JNI changes: >> http://openjdk.java.net/jeps/178 >> >> Webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >> >> The changes to jvmti.xml can also be seen in the output file that I >> placed here: >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >> >> Thanks, >> bill >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130712/5214387f/attachment-0001.html From mike.duigou at oracle.com Fri Jul 12 15:45:01 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 12 Jul 2013 22:45:01 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130712224538.1056A48A4C@hg.openjdk.java.net> Changeset: 9b17939958e7 Author: henryjen Date: 2013-07-12 15:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b17939958e7 8015320: Pull spliterator() up from Collection to Iterable Reviewed-by: psandoz, mduigou Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/ConcurrentModificationException.java ! test/java/util/Spliterator/SpliteratorCollisions.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Changeset: 37c37361a7ad Author: henryjen Date: 2013-07-08 15:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37c37361a7ad 8020062: Nest StreamBuilder interfaces inside relevant Stream interfaces Reviewed-by: psandoz, mduigou Contributed-by: brian goetz ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java - src/share/classes/java/util/stream/StreamBuilder.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java From weijun.wang at oracle.com Fri Jul 12 17:48:23 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Sat, 13 Jul 2013 00:48:23 +0000 Subject: hg: jdk8/tl/jdk: 8019410: sun/security/krb5/auto/ReplayCacheTestProc.java Message-ID: <20130713004834.DA19248A54@hg.openjdk.java.net> Changeset: 5f2a8db78aca Author: weijun Date: 2013-07-13 08:47 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f2a8db78aca 8019410: sun/security/krb5/auto/ReplayCacheTestProc.java Reviewed-by: mullan ! test/sun/security/krb5/auto/ReplayCacheTestProc.java From rickard.backman at oracle.com Sun Jul 14 23:51:47 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Mon, 15 Jul 2013 08:51:47 +0200 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: <1E59732F-8B2D-44EC-94AA-838B36E40790@oracle.com> References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> <0D743CDF-C8AB-421C-8D20-C29F08104642@oracle.com> <9DA4C2B3-4923-4C02-AED8-62E3AE0CB502@oracle.com> <1E59732F-8B2D-44EC-94AA-838B36E40790@oracle.com> Message-ID: John, thanks for the review. I move the entry_frame_is_first(?) to JavaCallWrapper and named it is_first_frame(). Updated webrev: http://cr.openjdk.java.net/~rbackman/8016131.u1/ Thanks /R On Jul 13, 2013, at 12:15 AM, John Rose wrote: > It's good. > > One comment: The new overloading of aux. function entry_frame_is_first(_) belongs somewhere else. Since it doesn't really use frame::this, it is confusing as an overload beside a function that does use frame::this. Suggest placing it in JavaCallWrapper not frame. > > ? John > > On Jul 10, 2013, at 4:59 AM, Rickard B?ckman wrote: > >> Still looking for a Reviewer. >> >> Thanks >> /R >> >> On Jul 8, 2013, at 5:49 PM, Rickard B?ckman wrote: >> >>> Thanks Markus! >>> >>> /R >>> >>> On Jul 8, 2013, at 5:45 PM, Markus Gr?nlund wrote: >>> >>>> Rickard, >>>> >>>> I think it looks good (not a Reviewer). >>>> >>>> Cheers >>>> Markus >>>> >>>> -----Original Message----- >>>> From: Rickard B?ckman >>>> Sent: den 4 juli 2013 11:30 >>>> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>> Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' >>>> >>>> Hi, >>>> >>>> can I please have a couple of reviews for this change? >>>> >>>> The problem in this crash was that we were given an incorrect fp (in this case 0x0) and had a pc that matched the C -> Java entry frame. The code then dereferenced fp +- offset. >>>> >>>> This change verifies that the fp +- offset is actually on the stack of the thread before doing the derefencing. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rbackman/8016131/ >>>> >>>> Thanks >>>> /R >>> >> > From jaroslav.bachorik at oracle.com Mon Jul 15 01:41:10 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 15 Jul 2013 10:41:10 +0200 Subject: RFR: 8019584 javax/management/remote/mandatory/loading/MissingClassTest.java failed in nightly against jdk7u45: java.io.InvalidObjectException: Invalid notification: null Message-ID: <51E3B5A6.4060301@oracle.com> Please, review the patch for https://jbs.oracle.com/bugs/browse/JDK-8019584 http://cr.openjdk.java.net/~jbachorik/8019584/webrev.00/ The reason for the failure is that the ObjectInputStream.readFields() method does not throw CNFE as specified when encountering instances of unknown in the object graph to be deserialized. Instead, it leaves the fields in the default state which in this case is "null" and is not valid. Hence, the deserialization validation fails. Since the main cause is in the RMI code, has been there for very long time and changing the behaviour there might have disrupting effects on various 3rd party applications I decided to work around this problem in the JMX code. The workaround adds InvalidObjectException to the list of expected exceptions when processing JMX notifications. It is treated the same way as eg. CNFE - the exception is logged and the notification will be reported as missing. This will resolve the problem on the JMX side. Thanks, -JB- From joel.franck at oracle.com Mon Jul 15 02:27:10 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Mon, 15 Jul 2013 09:27:10 +0000 Subject: hg: jdk8/tl/jdk: 7122142: (ann) Race condition between isAnnotationPresent and getAnnotations Message-ID: <20130715092739.9D7D8480AA@hg.openjdk.java.net> Changeset: e4ce6502eac0 Author: plevart Date: 2013-07-15 10:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4ce6502eac0 7122142: (ann) Race condition between isAnnotationPresent and getAnnotations Reviewed-by: dholmes, jfranck ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/reflect/annotation/AnnotationType.java + test/java/lang/annotation/AnnotationType/AnnotationTypeDeadlockTest.java + test/java/lang/annotation/AnnotationType/AnnotationTypeRuntimeAssumptionTest.java From frederic.parain at oracle.com Mon Jul 15 03:02:16 2013 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Mon, 15 Jul 2013 10:02:16 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 17 new changesets Message-ID: <20130715100304.5F854480AB@hg.openjdk.java.net> Changeset: e50be1620201 Author: goetz Date: 2013-07-08 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e50be1620201 8020059: The flag introduced by 8014972 is not defined if Hotspot is built without a compiler (zero, ppc64 core build). Summary: define CodeCacheMinimumUseSpace flag for cppInterpeter build. Reviewed-by: kvn ! src/share/vm/runtime/globals.hpp Changeset: e554162ab094 Author: adlertz Date: 2013-07-09 17:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e554162ab094 8019625: Test compiler/8005956/PolynomialRoot.java timeouts on Solaris SPARCs Summary: Disable the test for SPARC and reduce the number of test iterations Reviewed-by: kvn ! test/compiler/8005956/PolynomialRoot.java Changeset: b42fe1a8e180 Author: drchase Date: 2013-07-09 08:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b42fe1a8e180 8017578: Hotspot compilation error with latest Studio compiler Summary: Make the destructor virtual (note more non-compiler hotspot errors occur downstream) Reviewed-by: kvn, twisti ! src/share/vm/adlc/forms.hpp Changeset: 7ac80525ece9 Author: anoll Date: 2013-07-09 11:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7ac80525ece9 8015635: Crash when specifying very large code cache size Summary: Limit the size of the code cache to at most 2G when arguments are checked; added regression test Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp + test/compiler/codecache/CheckUpperLimit.java Changeset: 5f533e38e7d5 Author: twisti Date: 2013-07-09 22:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5f533e38e7d5 Merge Changeset: dec841e0c9aa Author: anoll Date: 2013-07-10 13:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dec841e0c9aa 8016749: -XX:+UseISM fails an assert(obj->is_oop()) when running SPECjbb2005 Summary: Remove obsolete code that relates to ISM which was used only on Solaris 8. Reviewed-by: kvn, twisti ! src/os/solaris/vm/globals_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/share/vm/runtime/arguments.cpp Changeset: ec173c8f3739 Author: roland Date: 2013-07-11 01:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ec173c8f3739 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2cbc8f3011a0 Author: ehelin Date: 2013-06-05 09:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2cbc8f3011a0 8015972: Refactor the sending of the object count after GC event Reviewed-by: brutisso, pliden ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp + src/share/vm/gc_implementation/shared/objectCountEventSender.cpp + src/share/vm/gc_implementation/shared/objectCountEventSender.hpp ! src/share/vm/memory/heapInspection.hpp - src/share/vm/memory/klassInfoClosure.hpp Changeset: 63cffb381adc Author: ehelin Date: 2013-06-12 15:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/63cffb381adc 8016170: GC id variable in gcTrace.cpp should use typedef GCId Reviewed-by: johnc, jwilhelm, jmasa ! src/share/vm/gc_implementation/shared/gcTrace.cpp Changeset: 6aa440bc1125 Author: ehelin Date: 2013-06-12 15:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6aa440bc1125 8015683: object_count_after_gc should have the same timestamp for all events Reviewed-by: mgerdin, stefank ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.hpp Changeset: 27c53c9f3a7e Author: ehelin Date: 2013-07-10 15:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/27c53c9f3a7e 8013939: Metaspace capacity not available Reviewed-by: tschatzl, mgerdin, stefank ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 0f631140d13b Author: tamao Date: 2013-07-11 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0f631140d13b Merge - src/share/vm/memory/klassInfoClosure.hpp Changeset: 1a3390aa8326 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1a3390aa8326 Added tag jdk8-b98 for changeset 30b5b75c42ac ! .hgtags Changeset: 2b9946e10587 Author: amurillo Date: 2013-07-12 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2b9946e10587 Merge - src/share/vm/memory/klassInfoClosure.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ea979302bb70 Author: amurillo Date: 2013-07-12 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ea979302bb70 Added tag hs25-b41 for changeset 2b9946e10587 ! .hgtags Changeset: bd1dc81da579 Author: amurillo Date: 2013-07-12 17:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bd1dc81da579 8020382: new hotspot build - hs25-b42 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 862625d214fa Author: fparain Date: 2013-07-15 00:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/862625d214fa Merge From rickard.backman at oracle.com Mon Jul 15 04:55:25 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Mon, 15 Jul 2013 11:55:25 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130715115532.B71F4480AD@hg.openjdk.java.net> Changeset: 23123fc6968a Author: rbackman Date: 2013-07-15 11:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/23123fc6968a 8019324: assert(_f2 == 0 || _f2 == f2) failed: illegal field change Reviewed-by: dholmes, rbackman Contributed-by: David Simms ! src/share/vm/oops/cpCache.hpp Changeset: ee9e76adced3 Author: rbackman Date: 2013-07-15 12:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ee9e76adced3 Merge From sean.coffey at oracle.com Mon Jul 15 05:45:53 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Mon, 15 Jul 2013 12:45:53 +0000 Subject: hg: jdk8/tl/jdk: 8017566: Backout 8000450 - Cannot access to com.sun.corba.se.impl.orb.ORBImpl Message-ID: <20130715124606.E31EC480AE@hg.openjdk.java.net> Changeset: 7cc35dd1885d Author: coffeys Date: 2013-07-15 13:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7cc35dd1885d 8017566: Backout 8000450 - Cannot access to com.sun.corba.se.impl.orb.ORBImpl Reviewed-by: mchung ! 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/lang/SecurityManager/CheckPackageAccess.java From daniel.fuchs at oracle.com Mon Jul 15 05:56:35 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 15 Jul 2013 14:56:35 +0200 Subject: jmx-dev RFR: 8019584 javax/management/remote/mandatory/loading/MissingClassTest.java failed in nightly against jdk7u45: java.io.InvalidObjectException: Invalid notification: null In-Reply-To: <51DE9B72.5030308@oracle.com> References: <51DE9B72.5030308@oracle.com> Message-ID: <51E3F183.3080106@oracle.com> Hi Jaroslav, This looks reasonable. I assume you have run the JCK to verify that it doesn't break anything else? best regards, -- daniel On 7/11/13 1:48 PM, Jaroslav Bachorik wrote: > Please, review the change. > > http://cr.openjdk.java.net/~jbachorik/8019584/webrev.00/ > > The combination of the fix for JDK-8014085 and > ObjectInputStream.readFields() not throwing CNFE when trying to > deserialize an object graph containing references to non-available > classes makes an InvalidObjectException being thrown instead of the CNFE > when processing JMX notifications. > > The patch makes the ClientNotificationForwarder ready for > InvalidObjectException - it will correctly report lost notifications but > will not cause the notification processing loop to fail with unhandled > exception. > > Thanks, > > -JB- > From vladimir.kozlov at oracle.com Mon Jul 15 09:59:48 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Jul 2013 09:59:48 -0700 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> <0D743CDF-C8AB-421C-8D20-C29F08104642@oracle.com> <9DA4C2B3-4923-4C02-AED8-62E3AE0CB502@oracle.com> <1E59732F-8B2D-44EC-94AA-838B36E40790@oracle.com> Message-ID: <51E42A84.20505@oracle.com> Hi, Rickard There are several methods already in Thread class which do similar address cheacks: on_local_stackO, is_in_stack(). It would be nice to have new check (at least part of it) at the same place. What about closed changes for entry_frame_call_wrapper_addr()? Thanks, Vladimir On 7/14/13 11:51 PM, Rickard B?ckman wrote: > John, thanks for the review. > > I move the entry_frame_is_first(?) to JavaCallWrapper and named it is_first_frame(). > Updated webrev: http://cr.openjdk.java.net/~rbackman/8016131.u1/ > > Thanks > /R > > On Jul 13, 2013, at 12:15 AM, John Rose wrote: > >> It's good. >> >> One comment: The new overloading of aux. function entry_frame_is_first(_) belongs somewhere else. Since it doesn't really use frame::this, it is confusing as an overload beside a function that does use frame::this. Suggest placing it in JavaCallWrapper not frame. >> >> ? John >> >> On Jul 10, 2013, at 4:59 AM, Rickard B?ckman wrote: >> >>> Still looking for a Reviewer. >>> >>> Thanks >>> /R >>> >>> On Jul 8, 2013, at 5:49 PM, Rickard B?ckman wrote: >>> >>>> Thanks Markus! >>>> >>>> /R >>>> >>>> On Jul 8, 2013, at 5:45 PM, Markus Gr?nlund wrote: >>>> >>>>> Rickard, >>>>> >>>>> I think it looks good (not a Reviewer). >>>>> >>>>> Cheers >>>>> Markus >>>>> >>>>> -----Original Message----- >>>>> From: Rickard B?ckman >>>>> Sent: den 4 juli 2013 11:30 >>>>> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>> Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' >>>>> >>>>> Hi, >>>>> >>>>> can I please have a couple of reviews for this change? >>>>> >>>>> The problem in this crash was that we were given an incorrect fp (in this case 0x0) and had a pc that matched the C -> Java entry frame. The code then dereferenced fp +- offset. >>>>> >>>>> This change verifies that the fp +- offset is actually on the stack of the thread before doing the derefencing. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8016131/ >>>>> >>>>> Thanks >>>>> /R >>>> >>> >> > From serguei.spitsyn at oracle.com Mon Jul 15 13:07:26 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 15 Jul 2013 13:07:26 -0700 Subject: Request for review:8020309:Remove InstanceKlass::_cached_class_file_len and record the length together with the cached class file bytes In-Reply-To: <51E06D3D.2020100@oracle.com> References: <51DDF518.6020303@oracle.com> <51DE0218.9090107@oracle.com> <51DE0CEA.5010501@oracle.com> <51DE695B.1020600@oracle.com> <51E06D3D.2020100@oracle.com> Message-ID: <51E4567E.3040704@oracle.com> Hi Jiangli, It looks good, thank you for the update! It makes sense to also run the JTREG java/lang/instrument tests. Thanks, Serguei On 7/12/13 1:55 PM, Jiangli Zhou wrote: > Hi Ioi and Serguei, > > Here is the updated the webrev: > > http://cr.openjdk.java.net/~jiangli/8020309/webrev.01/. > > I've retested with nsk.jvmti, nsk.jdi and nsk.hprof. I'm rerunning the > JPRT and rest of the tests. > > Thanks, > Jiangli > > On 07/11/2013 01:14 AM, serguei.spitsyn at oracle.com wrote: >> Hi Jiangli, >> >> I like the Ioi's sugestion. >> It will help to avoid the manipulations with offsets that look as >> unnecessary complexity. >> >> Thanks, >> Serguei >> >> >> On 7/10/13 6:39 PM, Jiangli Zhou wrote: >>> Hi Ioi, >>> >>> That's good suggestion. Let me look into it. >>> >>> Thanks! >>> >>> Jiangli >>> >>> On 07/10/2013 05:53 PM, Ioi Lam wrote: >>>> Hi Jiangli, >>>> >>>> I think it's better to move the logic of deciding the length into >>>> JVMTI. E.g., have something like >>>> >>>> struct JvmtiCachedClassFileData { >>>> int _length; >>>> unsigned char data[1]; >>>> }; >>>> >>>> void >>>> instanceKlass::set_jvmti_cached_class_file_data(JvmtiCachedClassFileData >>>> *data); >>>> >>>> - Ioi >>>> >>>> On 07/10/2013 04:58 PM, Jiangli Zhou wrote: >>>>> Hi, >>>>> >>>>> Please review the webrev for JDK-8020309 >>>>> : >>>>> >>>>> http://cr.openjdk.java.net/~jiangli/8020309/webrev.00/ >>>>> >>>>> The _cached_class_file_bytes and _cached_class_file_len are not >>>>> set/used if no jvmti agent is attached. The _cached_class_file_len >>>>> field can be eliminated and the file length can be recorded as >>>>> part of the cached class data in _cached_class_file_bytes for >>>>> redefined class. The above change allocates extra 4bytes when >>>>> allocating memory for cached class file and stores the length as >>>>> the first 4bytes and the file data as the rest. It saves 4 bytes >>>>> per class. For classes redefined, the memory usage is the same. >>>>> >>>>> Tested with following tests and JPRT: >>>>> >>>>> jdk/test/java/lang/instrument >>>>> jdk/test/com/sun/jdi >>>>> nsk.jvmti >>>>> nsk.jdi >>>>> nsk.hprof >>>>> >>>>> Thanks, >>>>> Jiangli >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130715/5bf75480/attachment.html From jiangli.zhou at oracle.com Mon Jul 15 13:58:52 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 15 Jul 2013 13:58:52 -0700 Subject: Request for review:8020309:Remove InstanceKlass::_cached_class_file_len and record the length together with the cached class file bytes In-Reply-To: <51E4567E.3040704@oracle.com> References: <51DDF518.6020303@oracle.com> <51DE0218.9090107@oracle.com> <51DE0CEA.5010501@oracle.com> <51DE695B.1020600@oracle.com> <51E06D3D.2020100@oracle.com> <51E4567E.3040704@oracle.com> Message-ID: <51E4628C.6060200@oracle.com> Hi Serguei, Thanks for the review! I've rerun all following tests and JPTR: jdk/test/java/lang/instrument jdk/test/com/sun/jdi nsk.jvmti nsk.jdi nsk.hprof Thanks, Jiangli On 07/15/2013 01:07 PM, serguei.spitsyn at oracle.com wrote: > Hi Jiangli, > > It looks good, thank you for the update! > It makes sense to also run the JTREG java/lang/instrument tests. > > Thanks, > Serguei > > On 7/12/13 1:55 PM, Jiangli Zhou wrote: >> Hi Ioi and Serguei, >> >> Here is the updated the webrev: >> >> http://cr.openjdk.java.net/~jiangli/8020309/webrev.01/. >> >> I've retested with nsk.jvmti, nsk.jdi and nsk.hprof. I'm rerunning >> the JPRT and rest of the tests. >> >> Thanks, >> Jiangli >> >> On 07/11/2013 01:14 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Jiangli, >>> >>> I like the Ioi's sugestion. >>> It will help to avoid the manipulations with offsets that look as >>> unnecessary complexity. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 7/10/13 6:39 PM, Jiangli Zhou wrote: >>>> Hi Ioi, >>>> >>>> That's good suggestion. Let me look into it. >>>> >>>> Thanks! >>>> >>>> Jiangli >>>> >>>> On 07/10/2013 05:53 PM, Ioi Lam wrote: >>>>> Hi Jiangli, >>>>> >>>>> I think it's better to move the logic of deciding the length into >>>>> JVMTI. E.g., have something like >>>>> >>>>> struct JvmtiCachedClassFileData { >>>>> int _length; >>>>> unsigned char data[1]; >>>>> }; >>>>> >>>>> void >>>>> instanceKlass::set_jvmti_cached_class_file_data(JvmtiCachedClassFileData >>>>> *data); >>>>> >>>>> - Ioi >>>>> >>>>> On 07/10/2013 04:58 PM, Jiangli Zhou wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the webrev for JDK-8020309 >>>>>> : >>>>>> >>>>>> http://cr.openjdk.java.net/~jiangli/8020309/webrev.00/ >>>>>> >>>>>> The _cached_class_file_bytes and _cached_class_file_len are not >>>>>> set/used if no jvmti agent is attached. The >>>>>> _cached_class_file_len field can be eliminated and the file >>>>>> length can be recorded as part of the cached class data in >>>>>> _cached_class_file_bytes for redefined class. The above change >>>>>> allocates extra 4bytes when allocating memory for cached class >>>>>> file and stores the length as the first 4bytes and the file data >>>>>> as the rest. It saves 4 bytes per class. For classes redefined, >>>>>> the memory usage is the same. >>>>>> >>>>>> Tested with following tests and JPRT: >>>>>> >>>>>> jdk/test/java/lang/instrument >>>>>> jdk/test/com/sun/jdi >>>>>> nsk.jvmti >>>>>> nsk.jdi >>>>>> nsk.hprof >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130715/0919752c/attachment.html From jiangli.zhou at oracle.com Mon Jul 15 14:02:09 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 15 Jul 2013 14:02:09 -0700 Subject: Request for review:8020309:Remove InstanceKlass::_cached_class_file_len and record the length together with the cached class file bytes In-Reply-To: <51E4628C.6060200@oracle.com> References: <51DDF518.6020303@oracle.com> <51DE0218.9090107@oracle.com> <51DE0CEA.5010501@oracle.com> <51DE695B.1020600@oracle.com> <51E06D3D.2020100@oracle.com> <51E4567E.3040704@oracle.com> <51E4628C.6060200@oracle.com> Message-ID: <51E46351.5090708@oracle.com> On 07/15/2013 01:58 PM, Jiangli Zhou wrote: > Hi Serguei, > > Thanks for the review! I've rerun all following tests and JPTR: > > jdk/test/java/lang/instrument > jdk/test/com/sun/jdi > nsk.jvmti > nsk.jdi > nsk.hprof And vm.quick.testlist as well. Thanks, Jiangli > > Thanks, > Jiangli > > On 07/15/2013 01:07 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jiangli, >> >> It looks good, thank you for the update! >> It makes sense to also run the JTREG java/lang/instrument tests. >> >> Thanks, >> Serguei >> >> On 7/12/13 1:55 PM, Jiangli Zhou wrote: >>> Hi Ioi and Serguei, >>> >>> Here is the updated the webrev: >>> >>> http://cr.openjdk.java.net/~jiangli/8020309/webrev.01/. >>> >>> I've retested with nsk.jvmti, nsk.jdi and nsk.hprof. I'm rerunning >>> the JPRT and rest of the tests. >>> >>> Thanks, >>> Jiangli >>> >>> On 07/11/2013 01:14 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi Jiangli, >>>> >>>> I like the Ioi's sugestion. >>>> It will help to avoid the manipulations with offsets that look as >>>> unnecessary complexity. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 7/10/13 6:39 PM, Jiangli Zhou wrote: >>>>> Hi Ioi, >>>>> >>>>> That's good suggestion. Let me look into it. >>>>> >>>>> Thanks! >>>>> >>>>> Jiangli >>>>> >>>>> On 07/10/2013 05:53 PM, Ioi Lam wrote: >>>>>> Hi Jiangli, >>>>>> >>>>>> I think it's better to move the logic of deciding the length into >>>>>> JVMTI. E.g., have something like >>>>>> >>>>>> struct JvmtiCachedClassFileData { >>>>>> int _length; >>>>>> unsigned char data[1]; >>>>>> }; >>>>>> >>>>>> void >>>>>> instanceKlass::set_jvmti_cached_class_file_data(JvmtiCachedClassFileData >>>>>> *data); >>>>>> >>>>>> - Ioi >>>>>> >>>>>> On 07/10/2013 04:58 PM, Jiangli Zhou wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the webrev for JDK-8020309 >>>>>>> : >>>>>>> >>>>>>> http://cr.openjdk.java.net/~jiangli/8020309/webrev.00/ >>>>>>> >>>>>>> The _cached_class_file_bytes and _cached_class_file_len are not >>>>>>> set/used if no jvmti agent is attached. The >>>>>>> _cached_class_file_len field can be eliminated and the file >>>>>>> length can be recorded as part of the cached class data in >>>>>>> _cached_class_file_bytes for redefined class. The above change >>>>>>> allocates extra 4bytes when allocating memory for cached class >>>>>>> file and stores the length as the first 4bytes and the file data >>>>>>> as the rest. It saves 4 bytes per class. For classes redefined, >>>>>>> the memory usage is the same. >>>>>>> >>>>>>> Tested with following tests and JPRT: >>>>>>> >>>>>>> jdk/test/java/lang/instrument >>>>>>> jdk/test/com/sun/jdi >>>>>>> nsk.jvmti >>>>>>> nsk.jdi >>>>>>> nsk.hprof >>>>>>> >>>>>>> Thanks, >>>>>>> Jiangli >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130715/187553bd/attachment-0001.html From ioi.lam at oracle.com Mon Jul 15 15:05:49 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 15 Jul 2013 15:05:49 -0700 Subject: Request for review:8020309:Remove InstanceKlass::_cached_class_file_len and record the length together with the cached class file bytes In-Reply-To: <51E06D3D.2020100@oracle.com> References: <51DDF518.6020303@oracle.com> <51DE0218.9090107@oracle.com> <51DE0CEA.5010501@oracle.com> <51DE695B.1020600@oracle.com> <51E06D3D.2020100@oracle.com> Message-ID: <51E4723D.2050401@oracle.com> Looks good to me. Thanks - Ioi On 07/12/2013 01:55 PM, Jiangli Zhou wrote: > Hi Ioi and Serguei, > > Here is the updated the webrev: > > http://cr.openjdk.java.net/~jiangli/8020309/webrev.01/. > > I've retested with nsk.jvmti, nsk.jdi and nsk.hprof. I'm rerunning the > JPRT and rest of the tests. > > Thanks, > Jiangli > > On 07/11/2013 01:14 AM, serguei.spitsyn at oracle.com wrote: >> Hi Jiangli, >> >> I like the Ioi's sugestion. >> It will help to avoid the manipulations with offsets that look as >> unnecessary complexity. >> >> Thanks, >> Serguei >> >> >> On 7/10/13 6:39 PM, Jiangli Zhou wrote: >>> Hi Ioi, >>> >>> That's good suggestion. Let me look into it. >>> >>> Thanks! >>> >>> Jiangli >>> >>> On 07/10/2013 05:53 PM, Ioi Lam wrote: >>>> Hi Jiangli, >>>> >>>> I think it's better to move the logic of deciding the length into >>>> JVMTI. E.g., have something like >>>> >>>> struct JvmtiCachedClassFileData { >>>> int _length; >>>> unsigned char data[1]; >>>> }; >>>> >>>> void >>>> instanceKlass::set_jvmti_cached_class_file_data(JvmtiCachedClassFileData >>>> *data); >>>> >>>> - Ioi >>>> >>>> On 07/10/2013 04:58 PM, Jiangli Zhou wrote: >>>>> Hi, >>>>> >>>>> Please review the webrev for JDK-8020309 >>>>> : >>>>> >>>>> http://cr.openjdk.java.net/~jiangli/8020309/webrev.00/ >>>>> >>>>> The _cached_class_file_bytes and _cached_class_file_len are not >>>>> set/used if no jvmti agent is attached. The _cached_class_file_len >>>>> field can be eliminated and the file length can be recorded as >>>>> part of the cached class data in _cached_class_file_bytes for >>>>> redefined class. The above change allocates extra 4bytes when >>>>> allocating memory for cached class file and stores the length as >>>>> the first 4bytes and the file data as the rest. It saves 4 bytes >>>>> per class. For classes redefined, the memory usage is the same. >>>>> >>>>> Tested with following tests and JPRT: >>>>> >>>>> jdk/test/java/lang/instrument >>>>> jdk/test/com/sun/jdi >>>>> nsk.jvmti >>>>> nsk.jdi >>>>> nsk.hprof >>>>> >>>>> Thanks, >>>>> Jiangli >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130715/f26e601e/attachment.html From jiangli.zhou at oracle.com Mon Jul 15 15:07:32 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 15 Jul 2013 15:07:32 -0700 Subject: Request for review:8020309:Remove InstanceKlass::_cached_class_file_len and record the length together with the cached class file bytes In-Reply-To: <51E4723D.2050401@oracle.com> References: <51DDF518.6020303@oracle.com> <51DE0218.9090107@oracle.com> <51DE0CEA.5010501@oracle.com> <51DE695B.1020600@oracle.com> <51E06D3D.2020100@oracle.com> <51E4723D.2050401@oracle.com> Message-ID: <51E472A4.8040801@oracle.com> Thanks, Ioi! Jiangli On 07/15/2013 03:05 PM, Ioi Lam wrote: > Looks good to me. > > Thanks > - Ioi > On 07/12/2013 01:55 PM, Jiangli Zhou wrote: >> Hi Ioi and Serguei, >> >> Here is the updated the webrev: >> >> http://cr.openjdk.java.net/~jiangli/8020309/webrev.01/. >> >> I've retested with nsk.jvmti, nsk.jdi and nsk.hprof. I'm rerunning >> the JPRT and rest of the tests. >> >> Thanks, >> Jiangli >> >> On 07/11/2013 01:14 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Jiangli, >>> >>> I like the Ioi's sugestion. >>> It will help to avoid the manipulations with offsets that look as >>> unnecessary complexity. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 7/10/13 6:39 PM, Jiangli Zhou wrote: >>>> Hi Ioi, >>>> >>>> That's good suggestion. Let me look into it. >>>> >>>> Thanks! >>>> >>>> Jiangli >>>> >>>> On 07/10/2013 05:53 PM, Ioi Lam wrote: >>>>> Hi Jiangli, >>>>> >>>>> I think it's better to move the logic of deciding the length into >>>>> JVMTI. E.g., have something like >>>>> >>>>> struct JvmtiCachedClassFileData { >>>>> int _length; >>>>> unsigned char data[1]; >>>>> }; >>>>> >>>>> void >>>>> instanceKlass::set_jvmti_cached_class_file_data(JvmtiCachedClassFileData >>>>> *data); >>>>> >>>>> - Ioi >>>>> >>>>> On 07/10/2013 04:58 PM, Jiangli Zhou wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the webrev for JDK-8020309 >>>>>> : >>>>>> >>>>>> http://cr.openjdk.java.net/~jiangli/8020309/webrev.00/ >>>>>> >>>>>> The _cached_class_file_bytes and _cached_class_file_len are not >>>>>> set/used if no jvmti agent is attached. The >>>>>> _cached_class_file_len field can be eliminated and the file >>>>>> length can be recorded as part of the cached class data in >>>>>> _cached_class_file_bytes for redefined class. The above change >>>>>> allocates extra 4bytes when allocating memory for cached class >>>>>> file and stores the length as the first 4bytes and the file data >>>>>> as the rest. It saves 4 bytes per class. For classes redefined, >>>>>> the memory usage is the same. >>>>>> >>>>>> Tested with following tests and JPRT: >>>>>> >>>>>> jdk/test/java/lang/instrument >>>>>> jdk/test/com/sun/jdi >>>>>> nsk.jvmti >>>>>> nsk.jdi >>>>>> nsk.hprof >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130715/f7b9b894/attachment.html From daniel.daugherty at oracle.com Mon Jul 15 15:45:13 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 15 Jul 2013 16:45:13 -0600 Subject: Request for review:8020309:Remove InstanceKlass::_cached_class_file_len and record the length together with the cached class file bytes In-Reply-To: <51E06D3D.2020100@oracle.com> References: <51DDF518.6020303@oracle.com> <51DE0218.9090107@oracle.com> <51DE0CEA.5010501@oracle.com> <51DE695B.1020600@oracle.com> <51E06D3D.2020100@oracle.com> Message-ID: <51E47B79.7010601@oracle.com> On 7/12/13 2:55 PM, Jiangli Zhou wrote: > Hi Ioi and Serguei, > > Here is the updated the webrev: > > http://cr.openjdk.java.net/~jiangli/8020309/webrev.01/. Thumbs up! src/share/vm/classfile/classFileParser.cpp nit line 3960: &ptr, &end_ptr, nit line 3961: &cached_class_file); Now that 'cached_class_file' is shorter, you can probably fit lines 3960 and 3961 on the same line without being longer than 80 chars. src/share/vm/oops/instanceKlass.cpp No comments. src/share/vm/oops/instanceKlass.hpp No comments. src/share/vm/prims/jvmtiExport.cpp line 620: p = (JvmtiCachedClassFileData *)os::malloc( line 621: offset_of(JvmtiCachedClassFileData, data) + _curr_len, mtInternal); The whole JvmtiCachedClassFileData* overlay trick reminds me of UDP and/OR TCP packet processing code. Much cleaner. src/share/vm/prims/jvmtiExport.hpp No comments. src/share/vm/prims/jvmtiRedefineClasses.cpp No comments. src/share/vm/prims/jvmtiRedefineClasses.hpp line 522: return cache == NULL ? NULL : cache->data; Will a picky compiler want '&cache->data[0]' to get a 'char *' instead of a 'char [1]'? Dan > > I've retested with nsk.jvmti, nsk.jdi and nsk.hprof. I'm rerunning the > JPRT and rest of the tests. > > Thanks, > Jiangli > > On 07/11/2013 01:14 AM, serguei.spitsyn at oracle.com wrote: >> Hi Jiangli, >> >> I like the Ioi's sugestion. >> It will help to avoid the manipulations with offsets that look as >> unnecessary complexity. >> >> Thanks, >> Serguei >> >> >> On 7/10/13 6:39 PM, Jiangli Zhou wrote: >>> Hi Ioi, >>> >>> That's good suggestion. Let me look into it. >>> >>> Thanks! >>> >>> Jiangli >>> >>> On 07/10/2013 05:53 PM, Ioi Lam wrote: >>>> Hi Jiangli, >>>> >>>> I think it's better to move the logic of deciding the length into >>>> JVMTI. E.g., have something like >>>> >>>> struct JvmtiCachedClassFileData { >>>> int _length; >>>> unsigned char data[1]; >>>> }; >>>> >>>> void >>>> instanceKlass::set_jvmti_cached_class_file_data(JvmtiCachedClassFileData >>>> *data); >>>> >>>> - Ioi >>>> >>>> On 07/10/2013 04:58 PM, Jiangli Zhou wrote: >>>>> Hi, >>>>> >>>>> Please review the webrev for JDK-8020309 >>>>> : >>>>> >>>>> http://cr.openjdk.java.net/~jiangli/8020309/webrev.00/ >>>>> >>>>> The _cached_class_file_bytes and _cached_class_file_len are not >>>>> set/used if no jvmti agent is attached. The _cached_class_file_len >>>>> field can be eliminated and the file length can be recorded as >>>>> part of the cached class data in _cached_class_file_bytes for >>>>> redefined class. The above change allocates extra 4bytes when >>>>> allocating memory for cached class file and stores the length as >>>>> the first 4bytes and the file data as the rest. It saves 4 bytes >>>>> per class. For classes redefined, the memory usage is the same. >>>>> >>>>> Tested with following tests and JPRT: >>>>> >>>>> jdk/test/java/lang/instrument >>>>> jdk/test/com/sun/jdi >>>>> nsk.jvmti >>>>> nsk.jdi >>>>> nsk.hprof >>>>> >>>>> Thanks, >>>>> Jiangli >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130715/e436e001/attachment-0001.html From jiangli.zhou at oracle.com Mon Jul 15 16:30:39 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 15 Jul 2013 16:30:39 -0700 Subject: Request for review:8020309:Remove InstanceKlass::_cached_class_file_len and record the length together with the cached class file bytes In-Reply-To: <51E47B79.7010601@oracle.com> References: <51DDF518.6020303@oracle.com> <51DE0218.9090107@oracle.com> <51DE0CEA.5010501@oracle.com> <51DE695B.1020600@oracle.com> <51E06D3D.2020100@oracle.com> <51E47B79.7010601@oracle.com> Message-ID: <51E4861F.4060503@oracle.com> Hi Dan, Thanks for the review! On 07/15/2013 03:45 PM, Daniel D. Daugherty wrote: > On 7/12/13 2:55 PM, Jiangli Zhou wrote: >> Hi Ioi and Serguei, >> >> Here is the updated the webrev: >> >> http://cr.openjdk.java.net/~jiangli/8020309/webrev.01/. > > Thumbs up! > > src/share/vm/classfile/classFileParser.cpp > nit line 3960: &ptr, &end_ptr, > nit line 3961: &cached_class_file); > Now that 'cached_class_file' is shorter, you can probably fit > lines 3960 and 3961 on the same line without being longer than > 80 chars. Fixed. > > src/share/vm/oops/instanceKlass.cpp > No comments. > > src/share/vm/oops/instanceKlass.hpp > No comments. > > src/share/vm/prims/jvmtiExport.cpp > line 620: p = (JvmtiCachedClassFileData *)os::malloc( > line 621: offset_of(JvmtiCachedClassFileData, data) + _curr_len, > mtInternal); > The whole JvmtiCachedClassFileData* overlay trick reminds me of > UDP and/OR TCP packet processing code. Much cleaner. > > src/share/vm/prims/jvmtiExport.hpp > No comments. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > No comments. > > src/share/vm/prims/jvmtiRedefineClasses.hpp > line 522: return cache == NULL ? NULL : cache->data; > Will a picky compiler want '&cache->data[0]' to get > a 'char *' instead of a 'char [1]'? I think we are safe in the case. We use this kind of define quite commonly in CDC VM (probably CLDC VM as well), all compilers handle it properly. Thanks! Jiangli > > Dan > > >> >> I've retested with nsk.jvmti, nsk.jdi and nsk.hprof. I'm rerunning >> the JPRT and rest of the tests. >> >> Thanks, >> Jiangli >> >> On 07/11/2013 01:14 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Jiangli, >>> >>> I like the Ioi's sugestion. >>> It will help to avoid the manipulations with offsets that look as >>> unnecessary complexity. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 7/10/13 6:39 PM, Jiangli Zhou wrote: >>>> Hi Ioi, >>>> >>>> That's good suggestion. Let me look into it. >>>> >>>> Thanks! >>>> >>>> Jiangli >>>> >>>> On 07/10/2013 05:53 PM, Ioi Lam wrote: >>>>> Hi Jiangli, >>>>> >>>>> I think it's better to move the logic of deciding the length into >>>>> JVMTI. E.g., have something like >>>>> >>>>> struct JvmtiCachedClassFileData { >>>>> int _length; >>>>> unsigned char data[1]; >>>>> }; >>>>> >>>>> void >>>>> instanceKlass::set_jvmti_cached_class_file_data(JvmtiCachedClassFileData >>>>> *data); >>>>> >>>>> - Ioi >>>>> >>>>> On 07/10/2013 04:58 PM, Jiangli Zhou wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the webrev for JDK-8020309 >>>>>> : >>>>>> >>>>>> http://cr.openjdk.java.net/~jiangli/8020309/webrev.00/ >>>>>> >>>>>> The _cached_class_file_bytes and _cached_class_file_len are not >>>>>> set/used if no jvmti agent is attached. The >>>>>> _cached_class_file_len field can be eliminated and the file >>>>>> length can be recorded as part of the cached class data in >>>>>> _cached_class_file_bytes for redefined class. The above change >>>>>> allocates extra 4bytes when allocating memory for cached class >>>>>> file and stores the length as the first 4bytes and the file data >>>>>> as the rest. It saves 4 bytes per class. For classes redefined, >>>>>> the memory usage is the same. >>>>>> >>>>>> Tested with following tests and JPRT: >>>>>> >>>>>> jdk/test/java/lang/instrument >>>>>> jdk/test/com/sun/jdi >>>>>> nsk.jvmti >>>>>> nsk.jdi >>>>>> nsk.hprof >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130715/a90e109c/attachment.html From david.holmes at oracle.com Mon Jul 15 18:01:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Jul 2013 11:01:09 +1000 Subject: RFR: 8019584 javax/management/remote/mandatory/loading/MissingClassTest.java failed in nightly against jdk7u45: java.io.InvalidObjectException: Invalid notification: null In-Reply-To: <51E3B5A6.4060301@oracle.com> References: <51E3B5A6.4060301@oracle.com> Message-ID: <51E49B55.2060603@oracle.com> On 15/07/2013 6:41 PM, Jaroslav Bachorik wrote: > Please, review the patch for https://jbs.oracle.com/bugs/browse/JDK-8019584 > > http://cr.openjdk.java.net/~jbachorik/8019584/webrev.00/ > > The reason for the failure is that the ObjectInputStream.readFields() > method does not throw CNFE as specified when encountering instances of > unknown in the object graph to be deserialized. Instead, it leaves the > fields in the default state which in this case is "null" and is not > valid. Hence, the deserialization validation fails. > > Since the main cause is in the RMI code, has been there for very long > time and changing the behaviour there might have disrupting effects on > various 3rd party applications I decided to work around this problem in > the JMX code. Can you pinpoint the code that actually fails to propagate the ClassNotFoundException - I don't see any issue in OIS.readFields itself so this comes from elsewhere. Failing to throw CNFE when deserializing seems like a major bug to me. Thanks, David > The workaround adds InvalidObjectException to the list of expected > exceptions when processing JMX notifications. It is treated the same way > as eg. CNFE - the exception is logged and the notification will be > reported as missing. This will resolve the problem on the JMX side. > > Thanks, > > -JB- > From joe.darcy at oracle.com Mon Jul 15 18:16:08 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 16 Jul 2013 01:16:08 +0000 Subject: hg: jdk8/tl/jdk: 8020409: Clean up doclint problems in java.util package, part 1 Message-ID: <20130716011631.A0175480D3@hg.openjdk.java.net> Changeset: 94e1a4b10811 Author: bpb Date: 2013-07-15 14:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94e1a4b10811 8020409: Clean up doclint problems in java.util package, part 1 Summary: Clean up doclint problems in java.util package, part 1 Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Base64.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/ResourceBundle.java From john.r.rose at oracle.com Mon Jul 15 19:26:05 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 15 Jul 2013 19:26:05 -0700 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: <51E42A84.20505@oracle.com> References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> <0D743CDF-C8AB-421C-8D20-C29F08104642@oracle.com> <9DA4C2B3-4923-4C02-AED8-62E3AE0CB502@oracle.com> <1E59732F-8B2D-44EC-94AA-838B36E40790@oracle.com> <51E42A84.20505@oracle.com> Message-ID: <87E8E61B-A2CC-4AB1-A1CB-79E4AFFF2FCB@oracle.com> On Jul 15, 2013, at 9:59 AM, Vladimir Kozlov wrote: > There are several methods already in Thread class which do similar address cheacks: on_local_stackO, is_in_stack(). It would be nice to have new check (at least part of it) at the same place. Yes, that's a good idea! Thread::is_in_usable_stack. That way the computation that involves stack_guard_size, etc., goes in thread.cpp which is more logical than in frame.cpp. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130715/e45a914e/attachment.html From rickard.backman at oracle.com Mon Jul 15 22:11:07 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Tue, 16 Jul 2013 07:11:07 +0200 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: <87E8E61B-A2CC-4AB1-A1CB-79E4AFFF2FCB@oracle.com> References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> <0D743CDF-C8AB-421C-8D20-C29F08104642@oracle.com> <9DA4C2B3-4923-4C02-AED8-62E3AE0CB502@oracle.com> <1E59732F-8B2D-44EC-94AA-838B36E40790@oracle.com> <51E42A84.20505@oracle.com> <87E8E61B-A2CC-4AB1-A1CB-79E4AFFF2FCB@oracle.com> Message-ID: Vladimir & John, thanks for the suggestion. It makes sense. Updated webrev: http://cr.openjdk.java.net/~rbackman/8016131.u2/ Thanks /R On Jul 16, 2013, at 4:26 AM, John Rose wrote: > On Jul 15, 2013, at 9:59 AM, Vladimir Kozlov wrote: > >> There are several methods already in Thread class which do similar address cheacks: on_local_stackO, is_in_stack(). It would be nice to have new check (at least part of it) at the same place. > > Yes, that's a good idea! Thread::is_in_usable_stack. That way the computation that involves stack_guard_size, etc., goes in thread.cpp which is more logical than in frame.cpp. > > ? John From sundararajan.athijegannathan at oracle.com Mon Jul 15 22:27:55 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 16 Jul 2013 05:27:55 +0000 Subject: hg: jdk8/tl/nashorn: 7 new changesets Message-ID: <20130716052801.71484480DA@hg.openjdk.java.net> Changeset: 973d78ee0728 Author: attila Date: 2013-07-15 12:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/973d78ee0728 8020324: Implement Object.bindProperties(target, source) for beans Reviewed-by: hannesw, sundar ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java + src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethod.java + src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java + test/script/basic/JDK-8020324.js + test/script/basic/JDK-8020324.js.EXPECTED + test/src/jdk/nashorn/test/models/PropertyBind.java Changeset: 62c552bcc342 Author: hannesw Date: 2013-07-15 15:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/62c552bcc342 8020354: Object literal property initialization is not done in source order Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8020354.js + test/script/basic/JDK-8020354.js.EXPECTED Changeset: ede320e13c82 Author: attila Date: 2013-07-15 16:31 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ede320e13c82 8020508: Enforce reflection access restrictions on Object.bindProperties Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java + test/script/basic/JDK-8020508.js + test/script/basic/JDK-8020508.js.EXPECTED Changeset: e5505f0b10de Author: hannesw Date: 2013-07-15 16:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e5505f0b10de 8020283: Don't use exceptions for widening of ArrayData Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java Changeset: 01212f5e7dad Author: attila Date: 2013-07-15 16:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/01212f5e7dad 8011210: fix reporting of call site locations; print them on -tcs=miss Reviewed-by: jlaskey, hannesw ! src/jdk/internal/dynalink/DynamicLinker.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java Changeset: 28f1f2374004 Author: hannesw Date: 2013-07-15 18:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/28f1f2374004 8020358: Array(0xfffffff) throws OutOfMemoryError Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java + test/script/basic/JDK-8020358.js + test/script/basic/JDK-8020358.js.EXPECTED Changeset: d685fec24d13 Author: sundar Date: 2013-07-16 09:54 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d685fec24d13 Merge From david.holmes at oracle.com Mon Jul 15 23:10:48 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 16 Jul 2013 06:10:48 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8015759: hotspot changes needed to compile with Visual Studio 2012 Message-ID: <20130716061052.6E479480DC@hg.openjdk.java.net> Changeset: 33c52908bcdb Author: dholmes Date: 2013-07-15 23:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/33c52908bcdb 8015759: hotspot changes needed to compile with Visual Studio 2012 Reviewed-by: anthony, dholmes, dcubed Contributed-by: Tim Bell ! make/windows/makefiles/compile.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/vm.make ! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp From john.r.rose at oracle.com Mon Jul 15 23:24:44 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 15 Jul 2013 23:24:44 -0700 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> <0D743CDF-C8AB-421C-8D20-C29F08104642@oracle.com> <9DA4C2B3-4923-4C02-AED8-62E3AE0CB502@oracle.com> <1E59732F-8B2D-44EC-94AA-838B36E40790@oracle.com> <51E42A84.20505@oracle.com> <87E8E61B-A2CC-4AB1-A1CB-79E4AFFF2FCB@oracle.com> Message-ID: Good. ? John On Jul 15, 2013, at 10:11 PM, Rickard B?ckman wrote: > thanks for the suggestion. It makes sense. > Updated webrev: http://cr.openjdk.java.net/~rbackman/8016131.u2/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130715/1ec6e165/attachment.html From rickard.backman at oracle.com Mon Jul 15 23:53:40 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Tue, 16 Jul 2013 08:53:40 +0200 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> <0D743CDF-C8AB-421C-8D20-C29F08104642@oracle.com> <9DA4C2B3-4923-4C02-AED8-62E3AE0CB502@oracle.com> <1E59732F-8B2D-44EC-94AA-838B36E40790@oracle.com> <51E42A84.20505@oracle.com> <87E8E61B-A2CC-4AB1-A1CB-79E4AFFF2FCB@oracle.com> Message-ID: <75D73BA8-8CF5-4AFD-9C1F-7DE33F8B283E@oracle.com> Thank you! /R On Jul 16, 2013, at 8:24 AM, John Rose wrote: > Good. ? John > > On Jul 15, 2013, at 10:11 PM, Rickard B?ckman wrote: > >> thanks for the suggestion. It makes sense. >> Updated webrev: http://cr.openjdk.java.net/~rbackman/8016131.u2/ > From vladimir.kozlov at oracle.com Mon Jul 15 23:56:47 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Jul 2013 23:56:47 -0700 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> <0D743CDF-C8AB-421C-8D20-C29F08104642@oracle.com> <9DA4C2B3-4923-4C02-AED8-62E3AE0CB502@oracle.com> <1E59732F-8B2D-44EC-94AA-838B36E40790@oracle.com> <51E42A84.20505@oracle.com> <87E8E61B-A2CC-4AB1-A1CB-79E4AFFF2FCB@oracle.com> Message-ID: <51E4EEAF.8060206@oracle.com> Rickard, One thing is_in_stack() has is check _stack_base == NULL. In your case it may not happen then you need to add assert to make sure it really does not happen. Or use stack_base() method which has the assert. Thanks, Vladimir On 7/15/13 10:11 PM, Rickard B?ckman wrote: > Vladimir & John, > > thanks for the suggestion. It makes sense. > Updated webrev: http://cr.openjdk.java.net/~rbackman/8016131.u2/ > > Thanks > /R > > On Jul 16, 2013, at 4:26 AM, John Rose wrote: > >> On Jul 15, 2013, at 9:59 AM, Vladimir Kozlov wrote: >> >>> There are several methods already in Thread class which do similar address cheacks: on_local_stackO, is_in_stack(). It would be nice to have new check (at least part of it) at the same place. >> >> Yes, that's a good idea! Thread::is_in_usable_stack. That way the computation that involves stack_guard_size, etc., goes in thread.cpp which is more logical than in frame.cpp. >> >> ? John > From rickard.backman at oracle.com Mon Jul 15 23:59:56 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Tue, 16 Jul 2013 08:59:56 +0200 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: <51E4EEAF.8060206@oracle.com> References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> <0D743CDF-C8AB-421C-8D20-C29F08104642@oracle.com> <9DA4C2B3-4923-4C02-AED8-62E3AE0CB502@oracle.com> <1E59732F-8B2D-44EC-94AA-838B36E40790@oracle.com> <51E42A84.20505@oracle.com> <87E8E61B-A2CC-4AB1-A1CB-79E4AFFF2FCB@oracle.com> <51E4EEAF.8060206@oracle.com> Message-ID: <2FBCABDA-E4AA-4FC9-8DCF-E4DF64B01B6A@oracle.com> Vladimir, I'll use the stack_base() method instead. Thanks /R On Jul 16, 2013, at 8:56 AM, Vladimir Kozlov wrote: > Rickard, > > One thing is_in_stack() has is check _stack_base == NULL. In your case it may not happen then you need to add assert to make sure it really does not happen. Or use stack_base() method which has the assert. > > Thanks, > Vladimir > > On 7/15/13 10:11 PM, Rickard B?ckman wrote: >> Vladimir & John, >> >> thanks for the suggestion. It makes sense. >> Updated webrev: http://cr.openjdk.java.net/~rbackman/8016131.u2/ >> >> Thanks >> /R >> >> On Jul 16, 2013, at 4:26 AM, John Rose wrote: >> >>> On Jul 15, 2013, at 9:59 AM, Vladimir Kozlov wrote: >>> >>>> There are several methods already in Thread class which do similar address cheacks: on_local_stackO, is_in_stack(). It would be nice to have new check (at least part of it) at the same place. >>> >>> Yes, that's a good idea! Thread::is_in_usable_stack. That way the computation that involves stack_guard_size, etc., goes in thread.cpp which is more logical than in frame.cpp. >>> >>> ? John >> From shanliang.jiang at oracle.com Tue Jul 16 00:31:52 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 16 Jul 2013 09:31:52 +0200 Subject: RFR: 8019584 javax/management/remote/mandatory/loading/MissingClassTest.java failed in nightly against jdk7u45: java.io.InvalidObjectException: Invalid notification: null In-Reply-To: <51DE9B72.5030308@oracle.com> References: <51DE9B72.5030308@oracle.com> Message-ID: <51E4F6E8.7030200@oracle.com> Jaroslav, I am not sure that it is a good idea to add simply InvalidObjectException into the catching list. I remember that we carefully analyzed and tested the catching list, in order to avoid no-needed call of "fetchOneNotif", and to avoid fetching on a dead connection. Look at javax.management.remote.rmi.RMIConnector$RMINotifClient.fetchNotifs, we carefully retrieve an original exception wrapped in a UnmarshalException, with different protocol to allow ClientNotifForwarder to do right catching. What I am afraid is that InvalidObjectException would be thrown with other situations, like the connection was cut in the middle way of fetching, then the fix would make ClientNotifForwarder fail to stop fetching. Shanliang Jaroslav Bachorik wrote: > Please, review the change. > > http://cr.openjdk.java.net/~jbachorik/8019584/webrev.00/ > > The combination of the fix for JDK-8014085 and > ObjectInputStream.readFields() not throwing CNFE when trying to > deserialize an object graph containing references to non-available > classes makes an InvalidObjectException being thrown instead of the CNFE > when processing JMX notifications. > > The patch makes the ClientNotificationForwarder ready for > InvalidObjectException - it will correctly report lost notifications but > will not cause the notification processing loop to fail with unhandled > exception. > > Thanks, > > -JB- > From jaroslav.bachorik at oracle.com Tue Jul 16 00:47:05 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 16 Jul 2013 09:47:05 +0200 Subject: RFR: 8019584 javax/management/remote/mandatory/loading/MissingClassTest.java failed in nightly against jdk7u45: java.io.InvalidObjectException: Invalid notification: null In-Reply-To: <51E4F6E8.7030200@oracle.com> References: <51DE9B72.5030308@oracle.com> <51E4F6E8.7030200@oracle.com> Message-ID: <51E4FA79.3000307@oracle.com> According to the documentation InvalidObjectException "Indicates that one or more deserialized objects failed validation tests." meaning that the severed connection should generate a different type of exception. InvalidObjectException should be reserved for the cases when the deserialized data violate the validation rules. But I can't say I am certain; when a CNFE can disappear in the process, anything might be possible ... Anyway, if I can't catch the InvalidObjectException it will leave me with two options: 1. Just forget about the validation 2. Do the validation but live with the fact that even when the validation fails a potential attacker can get access to an instance with invalid fields (eg. using the finalizer trick) -JB- On Tue 16 Jul 2013 09:31:52 AM CEST, shanliang wrote: > Jaroslav, > > I am not sure that it is a good idea to add simply > InvalidObjectException into the catching list. I remember that we > carefully analyzed and tested the catching list, in order to avoid > no-needed call of "fetchOneNotif", and to avoid fetching on a dead > connection. Look at > javax.management.remote.rmi.RMIConnector$RMINotifClient.fetchNotifs, > we carefully retrieve an original exception wrapped in a > UnmarshalException, with different protocol to allow > ClientNotifForwarder to do right catching. > > What I am afraid is that InvalidObjectException would be thrown with > other situations, like the connection was cut in the middle way of > fetching, then the fix would make ClientNotifForwarder fail to stop > fetching. > > Shanliang > > Jaroslav Bachorik wrote: >> Please, review the change. >> >> http://cr.openjdk.java.net/~jbachorik/8019584/webrev.00/ >> >> The combination of the fix for JDK-8014085 and >> ObjectInputStream.readFields() not throwing CNFE when trying to >> deserialize an object graph containing references to non-available >> classes makes an InvalidObjectException being thrown instead of the CNFE >> when processing JMX notifications. >> >> The patch makes the ClientNotificationForwarder ready for >> InvalidObjectException - it will correctly report lost notifications but >> will not cause the notification processing loop to fail with unhandled >> exception. >> >> Thanks, >> >> -JB- >> > From jaroslav.bachorik at oracle.com Tue Jul 16 00:49:21 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 16 Jul 2013 09:49:21 +0200 Subject: RFR: 8019584 javax/management/remote/mandatory/loading/MissingClassTest.java failed in nightly against jdk7u45: java.io.InvalidObjectException: Invalid notification: null In-Reply-To: <51E49B55.2060603@oracle.com> References: <51E3B5A6.4060301@oracle.com> <51E49B55.2060603@oracle.com> Message-ID: <51E4FB01.60403@oracle.com> On Tue 16 Jul 2013 03:01:09 AM CEST, David Holmes wrote: > On 15/07/2013 6:41 PM, Jaroslav Bachorik wrote: >> Please, review the patch for >> https://jbs.oracle.com/bugs/browse/JDK-8019584 >> >> http://cr.openjdk.java.net/~jbachorik/8019584/webrev.00/ >> >> The reason for the failure is that the ObjectInputStream.readFields() >> method does not throw CNFE as specified when encountering instances of >> unknown in the object graph to be deserialized. Instead, it leaves the >> fields in the default state which in this case is "null" and is not >> valid. Hence, the deserialization validation fails. >> >> Since the main cause is in the RMI code, has been there for very long >> time and changing the behaviour there might have disrupting effects on >> various 3rd party applications I decided to work around this problem in >> the JMX code. > > Can you pinpoint the code that actually fails to propagate the > ClassNotFoundException - I don't see any issue in OIS.readFields > itself so this comes from elsewhere. Failing to throw CNFE when > deserializing seems like a major bug to me. Yes, I agree. When you take a look at the ObjectInputStream.defaultReadObject() you can see that it forwards any captured exception on the lines 509-512 --- ClassNotFoundException ex = handles.lookupException(passHandle); if (ex != null) { throw ex; } --- On the other hand the GetFieldImpl just nulifies the read field on lines 2137-2138 --- return (handles.lookupException(objHandle) == null) ? objVals[off] : null; -- and the ObjectInputStream.readFields() completely disregards the "handles" map and basically swallows any exception discovered during the fields deserialization, AFAIK. -JB- and the ObjectInputStream.readFields > > Thanks, > David > > >> The workaround adds InvalidObjectException to the list of expected >> exceptions when processing JMX notifications. It is treated the same way >> as eg. CNFE - the exception is logged and the notification will be >> reported as missing. This will resolve the problem on the JMX side. >> >> Thanks, >> >> -JB- >> From mikael.gerdin at oracle.com Tue Jul 16 02:59:15 2013 From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com) Date: Tue, 16 Jul 2013 09:59:15 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 6671508: JNI GetPrimitiveArrayCritical should not be callable on object arrays Message-ID: <20130716095923.CF55F480E4@hg.openjdk.java.net> Changeset: 39deebbc90b3 Author: mgerdin Date: 2013-07-16 07:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/39deebbc90b3 6671508: JNI GetPrimitiveArrayCritical should not be callable on object arrays Summary: Checked JNI now reports error for Get/ReleasePrimitiveArrayCritical on object arrays Reviewed-by: dholmes, acorn Contributed-by: david.simms at oracle.com ! src/share/vm/prims/jniCheck.cpp From markus.gronlund at oracle.com Tue Jul 16 08:48:03 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Tue, 16 Jul 2013 08:48:03 -0700 (PDT) Subject: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) Message-ID: <0b3314f7-3733-4aac-a613-016e983c8b3a@default> Greetings, ? Kindly asking for reviews for the following change in hsx24: ? Bugid: http://bugs.sun.com/view_bug.do?bug_id=8020547 ? Webrev: http://cr.openjdk.java.net/~mgronlun/8020547/webrev01/ ? tracetypes.xml will declare a STRING type in order to support larger strings compared to existing UTF8 type (which is limited to a length of u2, ?max 65535 chars). ? I have also removed some stale comments. ? Thank you Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130716/f5e5b9a6/attachment.html From bill.pittore at oracle.com Tue Jul 16 09:01:44 2013 From: bill.pittore at oracle.com (bill.pittore at oracle.com) Date: Tue, 16 Jul 2013 12:01:44 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51D5A5CD.2070805@oracle.com> References: <51D494E9.2020200@oracle.com> <51D5A5CD.2070805@oracle.com> Message-ID: <51E56E68.8010305@oracle.com> I updated the text in VirtualMachine.java. The new webrev is here: http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ I ran it through javadoc and you can see the result here: http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html Let me know if you have any comments. thanks, bill On 7/4/2013 12:41 PM, Alan Bateman wrote: > On 03/07/2013 22:17, BILL PITTORE wrote: >> These changes address bug 8014135 which adds support for statically >> linked agents in the VM. This is a followup to the recent JNI spec >> changes that addressed statically linked JNI libraries( 8005716). >> The JEP for this change is the same JEP as the JNI changes: >> http://openjdk.java.net/jeps/178 >> >> Webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ > > I looked at the javadoc updates to the attach API. > > One thing that doesn't come across very clearly is the mapping from > the agentLibrary parameter to "agent-lib-name". I think that needs a > few words so that it's clear that it is not literally looking for > "Agent_OnAttach_agent-lib-name" but rather "Agent_OnAttach" + > where is the library name in the > agentLibrary parameter. > > As I recall, the JVM Tool Interface is supposed to be referred so as > "JVM TI" rather than "JVMTI". > > Otherwise it looks okay to me. > > -Alan > > > > From vladimir.kozlov at oracle.com Tue Jul 16 09:03:35 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 16 Jul 2013 09:03:35 -0700 Subject: RFR(S): 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' In-Reply-To: <2FBCABDA-E4AA-4FC9-8DCF-E4DF64B01B6A@oracle.com> References: <10CCC6A0-B444-4133-BCFB-F1A800AC05F5@oracle.com> <0D743CDF-C8AB-421C-8D20-C29F08104642@oracle.com> <9DA4C2B3-4923-4C02-AED8-62E3AE0CB502@oracle.com> <1E59732F-8B2D-44EC-94AA-838B36E40790@oracle.com> <51E42A84.20505@oracle.com> <87E8E61B-A2CC-4AB1-A1CB-79E4AFFF2FCB@oracle.com> <51E4EEAF.8060206@oracle.com> <2FBCABDA-E4AA-4FC9-8DCF-E4DF64B01B6A@oracle.com> Message-ID: <51E56ED7.6000205@oracle.com> On 7/15/13 11:59 PM, Rickard B?ckman wrote: > Vladimir, > > I'll use the stack_base() method instead. Good. Thanks, Vladimir > Thanks > /R > > On Jul 16, 2013, at 8:56 AM, Vladimir Kozlov wrote: > >> Rickard, >> >> One thing is_in_stack() has is check _stack_base == NULL. In your case it may not happen then you need to add assert to make sure it really does not happen. Or use stack_base() method which has the assert. >> >> Thanks, >> Vladimir >> >> On 7/15/13 10:11 PM, Rickard B?ckman wrote: >>> Vladimir & John, >>> >>> thanks for the suggestion. It makes sense. >>> Updated webrev: http://cr.openjdk.java.net/~rbackman/8016131.u2/ >>> >>> Thanks >>> /R >>> >>> On Jul 16, 2013, at 4:26 AM, John Rose wrote: >>> >>>> On Jul 15, 2013, at 9:59 AM, Vladimir Kozlov wrote: >>>> >>>>> There are several methods already in Thread class which do similar address cheacks: on_local_stackO, is_in_stack(). It would be nice to have new check (at least part of it) at the same place. >>>> >>>> Yes, that's a good idea! Thread::is_in_usable_stack. That way the computation that involves stack_guard_size, etc., goes in thread.cpp which is more logical than in frame.cpp. >>>> >>>> ? John >>> > From sundararajan.athijegannathan at oracle.com Tue Jul 16 09:16:30 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 16 Jul 2013 16:16:30 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20130716161634.5657648103@hg.openjdk.java.net> Changeset: 965d876853ec Author: attila Date: 2013-07-16 15:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/965d876853ec 8020357: throw RangeError for too large NativeArrayBuffer size Reviewed-by: jlaskey, hannesw, sundar ! src/jdk/nashorn/internal/objects/ArrayBufferView.java + test/script/basic/JDK-8020357.js + test/script/basic/JDK-8020357.js.EXPECTED Changeset: 7503f30c1355 Author: hannesw Date: 2013-07-16 16:12 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7503f30c1355 8010821: [findbugs] Some classes in jdk.nashorn.internal.runtime.regexp expose mutable objects Reviewed-by: attila, jlaskey, sundar ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodePrinter.java ! src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Token.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/BackRefNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/CClassNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/StateNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/StringNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPCode.java Changeset: 78bdb8a7f1e7 Author: attila Date: 2013-07-16 17:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/78bdb8a7f1e7 8015356: array concatenation should skip empty elements Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8015356.js + test/script/basic/JDK-8015356.js.EXPECTED From jason.uh at oracle.com Tue Jul 16 12:20:18 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Tue, 16 Jul 2013 19:20:18 +0000 Subject: hg: jdk8/tl/jdk: 8020557: javadoc cleanup in javax.security Message-ID: <20130716192100.E667548112@hg.openjdk.java.net> Changeset: f7af15e2c95b Author: juh Date: 2013-07-16 12:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7af15e2c95b 8020557: javadoc cleanup in javax.security Reviewed-by: darcy ! src/share/classes/javax/security/auth/AuthPermission.java ! src/share/classes/javax/security/auth/DestroyFailedException.java ! src/share/classes/javax/security/auth/Destroyable.java ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/RefreshFailedException.java ! src/share/classes/javax/security/auth/Refreshable.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/callback/Callback.java ! src/share/classes/javax/security/auth/callback/CallbackHandler.java ! src/share/classes/javax/security/auth/callback/ChoiceCallback.java ! src/share/classes/javax/security/auth/callback/ConfirmationCallback.java ! src/share/classes/javax/security/auth/callback/LanguageCallback.java ! src/share/classes/javax/security/auth/callback/NameCallback.java ! src/share/classes/javax/security/auth/callback/PasswordCallback.java ! src/share/classes/javax/security/auth/callback/TextInputCallback.java ! src/share/classes/javax/security/auth/callback/TextOutputCallback.java ! src/share/classes/javax/security/auth/callback/UnsupportedCallbackException.java + src/share/classes/javax/security/auth/callback/package-info.java - src/share/classes/javax/security/auth/callback/package.html ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/KerberosKey.java ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/share/classes/javax/security/auth/kerberos/KerberosTicket.java ! src/share/classes/javax/security/auth/kerberos/KeyImpl.java ! src/share/classes/javax/security/auth/kerberos/KeyTab.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java + src/share/classes/javax/security/auth/kerberos/package-info.java - src/share/classes/javax/security/auth/kerberos/package.html ! src/share/classes/javax/security/auth/login/AccountExpiredException.java ! src/share/classes/javax/security/auth/login/AppConfigurationEntry.java ! src/share/classes/javax/security/auth/login/Configuration.java ! src/share/classes/javax/security/auth/login/ConfigurationSpi.java ! src/share/classes/javax/security/auth/login/CredentialExpiredException.java ! src/share/classes/javax/security/auth/login/FailedLoginException.java ! src/share/classes/javax/security/auth/login/LoginContext.java + src/share/classes/javax/security/auth/login/package-info.java - src/share/classes/javax/security/auth/login/package.html + src/share/classes/javax/security/auth/package-info.java - src/share/classes/javax/security/auth/package.html ! src/share/classes/javax/security/auth/spi/LoginModule.java + src/share/classes/javax/security/auth/spi/package-info.java - src/share/classes/javax/security/auth/spi/package.html ! src/share/classes/javax/security/auth/x500/X500Principal.java ! src/share/classes/javax/security/auth/x500/X500PrivateCredential.java + src/share/classes/javax/security/auth/x500/package-info.java - src/share/classes/javax/security/auth/x500/package.html ! src/share/classes/javax/security/cert/Certificate.java ! src/share/classes/javax/security/cert/CertificateEncodingException.java ! src/share/classes/javax/security/cert/CertificateException.java ! src/share/classes/javax/security/cert/CertificateExpiredException.java ! src/share/classes/javax/security/cert/CertificateNotYetValidException.java ! src/share/classes/javax/security/cert/CertificateParsingException.java ! src/share/classes/javax/security/cert/X509Certificate.java + src/share/classes/javax/security/cert/package-info.java - src/share/classes/javax/security/cert/package.html ! src/share/classes/javax/security/sasl/AuthenticationException.java ! src/share/classes/javax/security/sasl/AuthorizeCallback.java ! src/share/classes/javax/security/sasl/RealmCallback.java ! src/share/classes/javax/security/sasl/RealmChoiceCallback.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslClient.java ! src/share/classes/javax/security/sasl/SaslClientFactory.java ! src/share/classes/javax/security/sasl/SaslException.java ! src/share/classes/javax/security/sasl/SaslServer.java ! src/share/classes/javax/security/sasl/SaslServerFactory.java + src/share/classes/javax/security/sasl/package-info.java - src/share/classes/javax/security/sasl/package.html From bob.vandette at oracle.com Tue Jul 16 14:44:31 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 16 Jul 2013 17:44:31 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51DDB632.4050805@oracle.com> References: <51D494E9.2020200@oracle.com> <51DDB632.4050805@oracle.com> Message-ID: <0F64EB55-B38C-416E-93D1-92BA8F5D43C7@oracle.com> Thanks for the suggestion Jeremy but the JVMTI agent change is being implemented as part of the original JNI static library implementation where we explicitly prohibited dynamic libraries to be loaded if a static library of the same name is baked into the launcher. "If a library L is statically linked then it will be prohibited to link a library of the same name dynamically." The primary motivation for requiring this for the -agentpath as well as the java.lang.System.load API is to minimize changes to java source code. You can statically or dynamically link a library without changing any of the code that attempts to use the library. The only thing that changes is the OnLoad name in the library and the link options. If you'd like to optionally use different implementations, you can end up with the same behavior by using a System property which alters the String of the name of the library. Bob. On Jul 10, 2013, at 3:29 PM, BILL PITTORE wrote: > On 7/3/2013 6:32 PM, Jeremy Manson wrote: >> I know that this is mentioned in the JEP, but does it really make sense to have -agentpath work here, rather than just -agentlib? I would think that specifying a full pathname and getting the library loaded out of the launcher would be a little surprising to people who are basically saying "please load this agent from the given path". >> >> Also, in practice, we do something very similar at Google, and, when testing, I find it occasionally useful to be able to say "please load this agent on the command line via the agentpath I gave you, rather than loading the one with the same name I baked into the launcher". >> >> (FWIW, when we did this internally at Google, we added a special -XX flag for when the agent is in the launcher. I know that you don't want to go that way, though.) >> > Thanks for the comments. I would say the thinking here is that we want this to be as transparent as possible to the end user. In our view of the end user is someone perhaps using an IDE and the actual execution of the VM with agent arguments is hidden. In your case it sounds like you are actually developing agents which is a whole different ball game. I could certainly see adding a -XX argument that forces agentpath to load the external library which would be good for agent development and debugging. No need to relink the entire VM with the new agent. Our tech lead is out on vacation this week so I'll bring this up when he's back. > > bill > >> >> On Wed, Jul 3, 2013 at 2:17 PM, BILL PITTORE > wrote: >> >> These changes address bug 8014135 which adds support for >> statically linked agents in the VM. This is a followup to the >> recent JNI spec changes that addressed statically linked JNI >> libraries( 8005716). >> The JEP for this change is the same JEP as the JNI changes: >> http://openjdk.java.net/jeps/178 >> >> Webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >> >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >> >> >> The changes to jvmti.xml can also be seen in the output file that >> I placed here: >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >> >> >> Thanks, >> bill >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130716/e0143094/attachment.html From rickard.backman at oracle.com Wed Jul 17 00:37:59 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Wed, 17 Jul 2013 07:37:59 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' Message-ID: <20130717073804.2223D4813A@hg.openjdk.java.net> Changeset: e619a2766bcc Author: rbackman Date: 2013-06-12 11:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e619a2766bcc 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' Reviewed-by: jrose, kvn, mgronlun ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp From markus.gronlund at oracle.com Wed Jul 17 03:25:29 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 17 Jul 2013 03:25:29 -0700 (PDT) Subject: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) In-Reply-To: <0b3314f7-3733-4aac-a613-016e983c8b3a@default> References: <0b3314f7-3733-4aac-a613-016e983c8b3a@default> Message-ID: Hi again, ? Trying again, could I please have a couple of reviews for this? Many thanks Markus ? From: Markus Gr?nlund Sent: den 16 juli 2013 17:48 To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) ? Greetings, ? Kindly asking for reviews for the following change in hsx24: ? Bugid: http://bugs.sun.com/view_bug.do?bug_id=8020547 ? Webrev: http://cr.openjdk.java.net/~mgronlun/8020547/webrev01/ ? tracetypes.xml will declare a STRING type in order to support larger strings compared to existing UTF8 type (which is limited to a length of u2, ?max 65535 chars). ? I have also removed some stale comments. ? Thank you Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130717/1779ba01/attachment-0001.html From bengt.rutisson at oracle.com Wed Jul 17 03:48:12 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 17 Jul 2013 12:48:12 +0200 Subject: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) In-Reply-To: References: <0b3314f7-3733-4aac-a613-016e983c8b3a@default> Message-ID: <51E6766C.8010300@oracle.com> Hi Markus, Looks reasonable. Bengt On 7/17/13 12:25 PM, Markus Gr?nlund wrote: > Hi again, > > > > Trying again, could I please have a couple of reviews for this? > > Many thanks > > Markus > > > > From: Markus Gr?nlund > Sent: den 16 juli 2013 17:48 > To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) > > > > Greetings, > > > > Kindly asking for reviews for the following change in hsx24: > > > > Bugid: http://bugs.sun.com/view_bug.do?bug_id=8020547 > > > > Webrev: http://cr.openjdk.java.net/~mgronlun/8020547/webrev01/ > > > > tracetypes.xml will declare a STRING type in order to support larger strings compared to existing UTF8 type (which is limited to a length of u2, max 65535 chars). > > > > I have also removed some stale comments. > > > > Thank you > > Markus > From erik.gahlin at oracle.com Wed Jul 17 04:14:01 2013 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 17 Jul 2013 13:14:01 +0200 Subject: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) In-Reply-To: <0b3314f7-3733-4aac-a613-016e983c8b3a@default> References: <0b3314f7-3733-4aac-a613-016e983c8b3a@default> Message-ID: <51E67C79.6010403@oracle.com> Looks good! (not a Reviewer) /Erik Markus Gr?nlund skrev 7/16/13 5:48 PM: > > Greetings, > > Kindly asking for reviews for the following change in hsx24: > > Bugid: http://bugs.sun.com/view_bug.do?bug_id=8020547 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8020547/webrev01/ > > > tracetypes.xml will declare a STRING type in order to support larger > strings compared to existing UTF8 type (which is limited to a length > of u2, max 65535 chars). > > I have also removed some stale comments. > > Thank you > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130717/d87f5cea/attachment.html From rickard.backman at oracle.com Wed Jul 17 04:31:11 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 17 Jul 2013 13:31:11 +0200 Subject: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) In-Reply-To: References: <0b3314f7-3733-4aac-a613-016e983c8b3a@default> Message-ID: Looks good to me. /R On Jul 17, 2013, at 12:25 PM, Markus Gr?nlund wrote: > Hi again, > > Trying again, could I please have a couple of reviews for this? > > Many thanks > Markus > > From: Markus Gr?nlund > Sent: den 16 juli 2013 17:48 > To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) > > Greetings, > > Kindly asking for reviews for the following change in hsx24: > > Bugid: http://bugs.sun.com/view_bug.do?bug_id=8020547 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8020547/webrev01/ > > tracetypes.xml will declare a STRING type in order to support larger strings compared to existing UTF8 type (which is limited to a length of u2, max 65535 chars). > > I have also removed some stale comments. > > Thank you > Markus From rickard.backman at oracle.com Wed Jul 17 04:58:54 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 17 Jul 2013 13:58:54 +0200 Subject: RFR(S): 8020107: Avoid crashes in WatcherThread Message-ID: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> Hi all, can I please have reviews for the following change? We are adding a mechanism for avoiding some crashes in the WatcherThread using different OS-specific methods. Webrev: http://cr.openjdk.java.net/~rbackman/8020701/webrev/ Thanks /R From rickard.backman at oracle.com Wed Jul 17 05:22:30 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 17 Jul 2013 14:22:30 +0200 Subject: RFR(S): 8020107: Avoid crashes in WatcherThread In-Reply-To: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> References: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> Message-ID: Sorry everyone, wrong bugnr in the topic. It should be 8020701. /R On Jul 17, 2013, at 1:58 PM, Rickard B?ckman wrote: > Hi all, > > can I please have reviews for the following change? > > We are adding a mechanism for avoiding some crashes in the WatcherThread using different OS-specific methods. > > Webrev: http://cr.openjdk.java.net/~rbackman/8020701/webrev/ > > Thanks > /R From rickard.backman at oracle.com Wed Jul 17 06:01:17 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 17 Jul 2013 15:01:17 +0200 Subject: RFR(S): 8020107: Avoid crashes in WatcherThread In-Reply-To: <51E6948D.4050801@oracle.com> References: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> <51E6948D.4050801@oracle.com> Message-ID: Thank you David. /R On Jul 17, 2013, at 2:56 PM, David Simms wrote: > > Looks good to me. > > On 17/07/2013 1:58 p.m., Rickard B?ckman wrote: >> Hi all, >> >> can I please have reviews for the following change? >> >> We are adding a mechanism for avoiding some crashes in the WatcherThread using different OS-specific methods. >> >> Webrev: http://cr.openjdk.java.net/~rbackman/8020701/webrev/ >> >> Thanks >> /R > From david.simms at oracle.com Wed Jul 17 05:56:45 2013 From: david.simms at oracle.com (David Simms) Date: Wed, 17 Jul 2013 14:56:45 +0200 Subject: RFR(S): 8020107: Avoid crashes in WatcherThread In-Reply-To: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> References: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> Message-ID: <51E6948D.4050801@oracle.com> Looks good to me. On 17/07/2013 1:58 p.m., Rickard B?ckman wrote: > Hi all, > > can I please have reviews for the following change? > > We are adding a mechanism for avoiding some crashes in the WatcherThread using different OS-specific methods. > > Webrev: http://cr.openjdk.java.net/~rbackman/8020701/webrev/ > > Thanks > /R From daniel.daugherty at oracle.com Wed Jul 17 07:06:43 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 17 Jul 2013 08:06:43 -0600 Subject: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) In-Reply-To: <0b3314f7-3733-4aac-a613-016e983c8b3a@default> References: <0b3314f7-3733-4aac-a613-016e983c8b3a@default> Message-ID: <51E6A4F3.6050200@oracle.com> On 7/16/13 9:48 AM, Markus Gr?nlund wrote: > > Greetings, > > Kindly asking for reviews for the following change in hsx24: > > Bugid: http://bugs.sun.com/view_bug.do?bug_id=8020547 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8020547/webrev01/ > > src/share/vm/trace/traceDataTypes.hpp No comments. src/share/vm/trace/tracetypes.xml line 277: type="TraceUnicodeString*" sizeop="sizeof_unicode(%)"/> The pointer type above and below this one have a space between the type name and the '*'. Any particular reason for the difference? src/share/vm/trace/xinclude.mod This one threw me for a second when I was just looking at the patch. In the frames version, it is clear that you're removing an extra copyright block... Thumbs up! Dan > tracetypes.xml will declare a STRING type in order to support larger > strings compared to existing UTF8 type (which is limited to a length > of u2, max 65535 chars). > > I have also removed some stale comments. > > Thank you > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130717/9d20a39f/attachment-0001.html From maurizio.cimadamore at oracle.com Wed Jul 17 07:28:47 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 17 Jul 2013 14:28:47 +0000 Subject: hg: jdk8/tl/langtools: 10 new changesets Message-ID: <20130717142920.800FD48153@hg.openjdk.java.net> Changeset: 44e27378f523 Author: mcimadamore Date: 2013-07-17 14:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/44e27378f523 8012242: Lambda compatibility and checked exceptions Summary: Inference variables in 'throws' clause with no constraints should be inferred as RuntimeException Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! test/tools/javac/generics/6723444/T6723444.java - test/tools/javac/generics/6723444/T6723444.out + test/tools/javac/generics/6723444/T6723444_1.out + test/tools/javac/generics/6723444/T6723444_2.out ! test/tools/javac/generics/7015430/T7015430.java - test/tools/javac/generics/7015430/T7015430.out + test/tools/javac/generics/7015430/T7015430_1.out + test/tools/javac/generics/7015430/T7015430_2.out + test/tools/javac/lambda/TargetType63.java + test/tools/javac/lambda/TargetType63.out Changeset: 866c87c01285 Author: mcimadamore Date: 2013-07-17 14:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/866c87c01285 8016175: Add bottom-up type-checking support for unambiguous method references Summary: Type-checking of non-overloaded method references should be independent from target-type Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.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/Resolve.java + test/tools/javac/lambda/MethodReference68.java + test/tools/javac/lambda/MethodReference68.out + test/tools/javac/lambda/MethodReference69.java + test/tools/javac/lambda/MethodReference69.out + test/tools/javac/lambda/MethodReference70.java + test/tools/javac/lambda/MethodReference70.out + test/tools/javac/lambda/MethodReference71.java + test/tools/javac/lambda/MethodReference71.out + test/tools/javac/lambda/MethodReference72.java + test/tools/javac/lambda/MethodReference72.out ! test/tools/javac/lambda/TargetType60.out + test/tools/javac/lambda/TargetType76.java Changeset: a204cf7aab7e Author: mcimadamore Date: 2013-07-17 14:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a204cf7aab7e 8012238: Nested method capture and inference 8008200: java/lang/Class/asSubclass/BasicUnit.java fails to compile Summary: Inference support should be more flexible w.r.t. nested method calls returning captured types Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/NestedCapture01.java + test/tools/javac/lambda/NestedCapture02.java + test/tools/javac/lambda/NestedCapture03.java Changeset: c60a5099863a Author: mcimadamore Date: 2013-07-17 14:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c60a5099863a 8020147: Spurious errors when compiling nested stuck lambdas Summary: Scope of deferred types is not copied correctly; postAttr analyzer should not run on stuck expressions Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/lambda/8020147/T8020147.java + test/tools/javac/lambda/8020147/T8020147.out Changeset: 328896931b98 Author: mcimadamore Date: 2013-07-17 14:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/328896931b98 8020286: Wrong diagnostic after compaction Summary: compact diagnostic shows the least relevant method in the list Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/Diagnostics/compressed/T8020286.java + test/tools/javac/Diagnostics/compressed/T8020286.out Changeset: db2c539819dd Author: mcimadamore Date: 2013-07-17 14:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/db2c539819dd 7041019: Bogus type-variable substitution with array types with dependencies on accessibility check Summary: call to upperBound() when performing type-variable substitution on element type leads to unsoundness Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/generics/7034511/T7034511a.java ! test/tools/javac/generics/7034511/T7034511a.out ! test/tools/javac/generics/7034511/T7034511b.java ! test/tools/javac/generics/7034511/T7034511b.out + test/tools/javac/generics/7034511/T7041019.java Changeset: fae8f309ff80 Author: mcimadamore Date: 2013-07-17 14:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fae8f309ff80 8016640: compiler hangs if the generics arity of a base class is wrong Summary: Check.checkCompatibleConcretes hang when javac creates synthetic supertypes for 269 model API Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java + test/tools/javac/generics/8016640/T8016640.java + test/tools/javac/generics/8016640/T8016640.out Changeset: 155809b1b969 Author: mcimadamore Date: 2013-07-17 14:19 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/155809b1b969 8020149: Graph inference: wrong logic for picking best variable to solve Summary: Replace logic for selecting best inference leaf in the graph during an unsticking round Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8020149/T8020149.java Changeset: b577222ef7b3 Author: mcimadamore Date: 2013-07-17 14:19 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b577222ef7b3 8019340: varargs-related warnings are meaningless on signature-polymorphic methods such as MethodHandle.invokeExact Summary: Disable certain varargs warnings when compiling polymorphic signature calls Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/meth/VarargsWarn.java + test/tools/javac/meth/VarargsWarn.out Changeset: f65a807714ba Author: mcimadamore Date: 2013-07-17 14:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f65a807714ba 8019942: Graph inference: avoid redundant computation during bound incorporation Summary: Bound incorporation should not perform same operation multiple times Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/generics/inference/8019824/T8019824.out From maurizio.cimadamore at oracle.com Wed Jul 17 07:46:04 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 17 Jul 2013 14:46:04 +0000 Subject: hg: jdk8/tl/langtools: 8020586: Warning produced for an incorrect file Message-ID: <20130717144608.EDAB948154@hg.openjdk.java.net> Changeset: 10711bd8bb2d Author: jlahoda Date: 2013-07-17 15:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/10711bd8bb2d 8020586: Warning produced for an incorrect file Summary: Always using DeferredLintHandler.immediateHandler when processing import classes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/warnings/6594914/Auxiliary.java + test/tools/javac/warnings/6594914/ExplicitCompilation.out + test/tools/javac/warnings/6594914/ImplicitCompilation.java + test/tools/javac/warnings/6594914/ImplicitCompilation.out From karen.kinnear at oracle.com Wed Jul 17 08:00:59 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 17 Jul 2013 11:00:59 -0400 Subject: RFR(S): 8020107: Avoid crashes in WatcherThread In-Reply-To: References: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> Message-ID: Code looks good. Thank you for the assertions and comments. Cleanly done, as usual for your changes Rickard. thanks, Karen On Jul 17, 2013, at 8:22 AM, Rickard B?ckman wrote: > Sorry everyone, wrong bugnr in the topic. > It should be 8020701. > > /R > > On Jul 17, 2013, at 1:58 PM, Rickard B?ckman wrote: > >> Hi all, >> >> can I please have reviews for the following change? >> >> We are adding a mechanism for avoiding some crashes in the WatcherThread using different OS-specific methods. >> >> Webrev: http://cr.openjdk.java.net/~rbackman/8020701/webrev/ >> >> Thanks >> /R > From karen.kinnear at oracle.com Wed Jul 17 08:05:37 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 17 Jul 2013 11:05:37 -0400 Subject: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) In-Reply-To: <0b3314f7-3733-4aac-a613-016e983c8b3a@default> References: <0b3314f7-3733-4aac-a613-016e983c8b3a@default> Message-ID: Markus, Looks good. (Ok, I miss the comment about j.l.Thread :-) ship it! Karen On Jul 16, 2013, at 11:48 AM, Markus Gr?nlund wrote: > Greetings, > > Kindly asking for reviews for the following change in hsx24: > > Bugid: http://bugs.sun.com/view_bug.do?bug_id=8020547 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8020547/webrev01/ > > tracetypes.xml will declare a STRING type in order to support larger strings compared to existing UTF8 type (which is limited to a length of u2, max 65535 chars). > > I have also removed some stale comments. > > Thank you > Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130717/0f2f941d/attachment.html From rickard.backman at oracle.com Wed Jul 17 08:11:53 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 17 Jul 2013 17:11:53 +0200 Subject: RFR(S): 8020107: Avoid crashes in WatcherThread In-Reply-To: References: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> Message-ID: Thank you for the review Karen! /R On Jul 17, 2013, at 5:00 PM, Karen Kinnear wrote: > Code looks good. Thank you for the assertions and comments. > > Cleanly done, as usual for your changes Rickard. > > thanks, > Karen > > On Jul 17, 2013, at 8:22 AM, Rickard B?ckman wrote: > >> Sorry everyone, wrong bugnr in the topic. >> It should be 8020701. >> >> /R >> >> On Jul 17, 2013, at 1:58 PM, Rickard B?ckman wrote: >> >>> Hi all, >>> >>> can I please have reviews for the following change? >>> >>> We are adding a mechanism for avoiding some crashes in the WatcherThread using different OS-specific methods. >>> >>> Webrev: http://cr.openjdk.java.net/~rbackman/8020701/webrev/ >>> >>> Thanks >>> /R >> > From gnu.andrew at redhat.com Wed Jul 17 08:32:44 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 17 Jul 2013 11:32:44 -0400 (EDT) Subject: Attach API on Linux and Root In-Reply-To: <338BF620-F6A5-44F4-A7E9-DCC81A4B86A6@oracle.com> References: <51AFB637.1000107@redhat.com> <51D6EE5E.1000204@redhat.com> <338BF620-F6A5-44F4-A7E9-DCC81A4B86A6@oracle.com> Message-ID: <447555466.1999831.1374075164189.JavaMail.root@redhat.com> ----- Original Message ----- > Thanks for the patch, I think it sounds like a good idea. For consistency, > however, we need to do the same modifications to the other platforms > (solaris, windows) and preferably add tests for this functionality as well. > The patch makes sense to me. While a very similar patch makes sense for Solaris and *BSD (the BSD code appears to actually be mostly the same as for GNU/Linux, bar renaming), there appears to be no equivalent code in the Windows version and we don't work on that platform. > /Staffan > > On 5 jul 2013, at 18:03, Elliott Baron wrote: > > > Hi, > > > > On 06/05/2013 06:05 PM, Elliott Baron wrote: > >> Hi, > >> > >> We use Hotspot's dynamic attach mechanism in our Thermostat monitoring > >> tool [1], however we have discovered a bit of a problem with access > >> control. One of our typical use-cases is to have our agent running as > >> root, which will monitor all JVMs on the machine. We have noticed that > >> our agent with root privileges cannot attach to other unprivileged users > >> VMs, which seems to go against the principle of the root user. > >> > >> I have attached a Hotspot patch and JDK patch targeting 7u-dev to allow > >> root to attach to any user's VMs. I'd appreciate it if someone could take > >> a look. > >> > >> Thanks, > >> Elliott > >> > >> [1] http://icedtea.classpath.org/thermostat/ > > > > Ping, just making sure this patch doesn't slip through the cracks. > > > > Thanks, > > Elliott > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From markus.gronlund at oracle.com Wed Jul 17 08:39:55 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 17 Jul 2013 08:39:55 -0700 (PDT) Subject: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) In-Reply-To: References: <0b3314f7-3733-4aac-a613-016e983c8b3a@default> Message-ID: <27986620-8c16-49e3-bd44-ea93d6cc9848@default> Many thanks for your reviews! ? Markus ? From: Karen Kinnear Sent: den 17 juli 2013 17:06 To: Markus Gr?nlund Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) ? Markus, ? Looks good. ? (Ok, I miss the comment about j.l.Thread :-) ship it! Karen ? On Jul 16, 2013, at 11:48 AM, Markus Gr?nlund wrote: Greetings, ? Kindly asking for reviews for the following change in hsx24: ? Bugid:?http://bugs.sun.com/view_bug.do?bug_id=8020547 ? Webrev:?http://cr.openjdk.java.net/~mgronlun/8020547/webrev01/ ? tracetypes.xml will declare a STRING type in order to support larger strings compared to existing UTF8 type (which is limited to a length of u2, ?max 65535 chars). ? I have also removed some stale comments. ? Thank you Markus ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130717/2000903a/attachment.html From markus.gronlund at oracle.com Wed Jul 17 08:48:02 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 17 Jul 2013 08:48:02 -0700 (PDT) Subject: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) In-Reply-To: <51E6A4F3.6050200@oracle.com> References: <0b3314f7-3733-4aac-a613-016e983c8b3a@default> <51E6A4F3.6050200@oracle.com> Message-ID: Thanks Dan! ? No technical reason for the *(star) placements in this file, it might be more readable for a human with a space added or something, I don't know, one of those human aspects again called preferences or something. ? Cheers Markus ? From: Daniel D. Daugherty Sent: den 17 juli 2013 16:07 To: Markus Gr?nlund Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(XS): 8020547 : Event based tracing needs a UNICODE string type (hsx24) ? On 7/16/13 9:48 AM, Markus Gr?nlund wrote: Greetings, ? Kindly asking for reviews for the following change in hsx24: ? Bugid: http://bugs.sun.com/view_bug.do?bug_id=8020547 ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Emgronlun/8020547/webrev01/"http://cr.openjdk.java.net/~mgronlun/8020547/webrev01/ src/share/vm/trace/traceDataTypes.hpp ??? No comments. src/share/vm/trace/tracetypes.xml ??? line 277: type="TraceUnicodeString*" sizeop="sizeof_unicode(%)"/> ??????? The pointer type above and below this one have a space ??????? between the type name and the '*'. Any particular reason ??????? for the difference? src/share/vm/trace/xinclude.mod ??? This one threw me for a second when I was just looking at the ??? patch. In the frames version, it is clear that you're removing ??? an extra copyright block... Thumbs up! Dan ? tracetypes.xml will declare a STRING type in order to support larger strings compared to existing UTF8 type (which is limited to a length of u2, ?max 65535 chars). ? I have also removed some stale comments. ? Thank you Markus ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130717/7d040e5d/attachment.html From daniel.daugherty at oracle.com Wed Jul 17 10:03:02 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 17 Jul 2013 11:03:02 -0600 Subject: RFR(S): 8020701: Avoid crashes in WatcherThread In-Reply-To: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> References: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> Message-ID: <51E6CE46.3030302@oracle.com> On 7/17/13 5:58 AM, Rickard B?ckman wrote: > Hi all, > > can I please have reviews for the following change? > > We are adding a mechanism for avoiding some crashes in the WatcherThread using different OS-specific methods. > > Webrev: http://cr.openjdk.java.net/~rbackman/8020701/webrev/ > > Thanks > /R Thumbs up! The bug mentions a few tests where you think this new infrastructure will help diagnose the failures modes for those tests. However, are there any new tests targeted to exercise this code? src/share/vm/runtime/os.hpp No comments. src/share/vm/runtime/os.cpp No comments. src/share/vm/runtime/thread.hpp line 756: void set_crash_protection(os::WatcherThreadCrashProtection* crash_protection) { assert(Thread::current()->is_Watcher_thread(), "Can only be set by WatcherThread"); _crash_protection = crash_protection; } This line is ridiculously long. Please reformat it to fit in 80 cols. src/share/vm/runtime/thread.cpp No comments. src/os/posix/vm/os_posix.hpp Nice comment. Hopefully it will keep anyone from doing something dangerous in the future. src/os/posix/vm/os_posix.cpp' Please add the following line above 268: * See the caveats for this class in os_posix.hpp. src/os/windows/vm/os_windows.hpp No comments. src/os/windows/vm/os_windows.cpp line 4692 * Protects the callback call so that S jumps back into this method Stale comment? What is 'S'? Please add the following line above 4692: * See the caveats for this class in os_windows.hpp. src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp line 405: // (no destructors run) Please change to "(no destructors can be run)" src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp line 557: // (no destructors run) Please change to "(no destructors can be run)" src/os_cpu/linux_x86/vm/os_linux_x86.cpp line 229: // (no destructors run) Please change to "(no destructors can be run)" src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp line 319: // (no destructors run) Please change to "(no destructors can be run)" src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp line 378: // (no destructors run) Please change to "(no destructors can be run)" src/share/vm/runtime/mutex.cpp No comments. Dan From rickard.backman at oracle.com Wed Jul 17 11:12:51 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 17 Jul 2013 20:12:51 +0200 Subject: RFR(S): 8020701: Avoid crashes in WatcherThread In-Reply-To: <51E6CE46.3030302@oracle.com> References: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> <51E6CE46.3030302@oracle.com> Message-ID: On Jul 17, 2013, at 7:03 PM, Daniel D. Daugherty wrote: > On 7/17/13 5:58 AM, Rickard B?ckman wrote: >> Hi all, >> >> can I please have reviews for the following change? >> >> We are adding a mechanism for avoiding some crashes in the WatcherThread using different OS-specific methods. >> >> Webrev: http://cr.openjdk.java.net/~rbackman/8020701/webrev/ >> >> Thanks >> /R > > Thumbs up! The bug mentions a few tests where you think this new > infrastructure will help diagnose the failures modes for those tests. > However, are there any new tests targeted to exercise this code? Not diagnose the failures, but avoid the crashes they are currently causing. Since at least one of them haven't been fixed yet (working on it) it will work as a good verifier at the moment. When the bug is gone, it is harder. It is a bit hard to write a test that causes the VM to crash at random but specific places. Eventually we could do something with the whitebox api, but the crashes would only happen at very specific places in that case making them a bit less interesting. > > > src/share/vm/runtime/os.hpp > No comments. > > src/share/vm/runtime/os.cpp > No comments. > > src/share/vm/runtime/thread.hpp > line 756: void set_crash_protection(os::WatcherThreadCrashProtection* crash_protection) { assert(Thread::current()->is_Watcher_thread(), "Can only be set by WatcherThread"); _crash_protection = crash_protection; } > This line is ridiculously long. Please reformat it to fit in 80 cols. Ok > > src/share/vm/runtime/thread.cpp > No comments. > > src/os/posix/vm/os_posix.hpp > Nice comment. Hopefully it will keep anyone from doing something > dangerous in the future. :) > > src/os/posix/vm/os_posix.cpp' > Please add the following line above 268: > > * See the caveats for this class in os_posix.hpp. Ok > > src/os/windows/vm/os_windows.hpp > No comments. > > src/os/windows/vm/os_windows.cpp > line 4692 * Protects the callback call so that S jumps back into this method > Stale comment? What is 'S'? typo. Should be something like raised EXCEPTIONS causes a jump back into this method. > > Please add the following line above 4692: > > * See the caveats for this class in os_windows.hpp. > > src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > line 405: // (no destructors run) > Please change to "(no destructors can be run)" Ok > > src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp > line 557: // (no destructors run) > Please change to "(no destructors can be run)" > > src/os_cpu/linux_x86/vm/os_linux_x86.cpp > line 229: // (no destructors run) > Please change to "(no destructors can be run)" > > src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp > line 319: // (no destructors run) > Please change to "(no destructors can be run)" > > src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp > line 378: // (no destructors run) > Please change to "(no destructors can be run)" > > src/share/vm/runtime/mutex.cpp > No comments. > > Dan > Thanks for the review! /R From lana.steuck at oracle.com Wed Jul 17 12:01:57 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 Jul 2013 19:01:57 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b98 for changeset b1fb4612a2ca Message-ID: <20130717190204.104B048166@hg.openjdk.java.net> Changeset: 8ef83d4b23c9 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8ef83d4b23c9 Added tag jdk8-b98 for changeset b1fb4612a2ca ! .hgtags From lana.steuck at oracle.com Wed Jul 17 12:01:55 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 Jul 2013 19:01:55 +0000 Subject: hg: jdk8/tl: 2 new changesets Message-ID: <20130717190156.42B3148163@hg.openjdk.java.net> Changeset: 0d0c983a817b Author: tbell Date: 2013-07-09 08:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0d0c983a817b 8009315: F# on PATH breaks Cygwin tools (mkdir, echo, mktemp ...) Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 59dc9da81379 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/59dc9da81379 Added tag jdk8-b98 for changeset 0d0c983a817b ! .hgtags From lana.steuck at oracle.com Wed Jul 17 12:01:57 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 Jul 2013 19:01:57 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20130717190203.3C39348165@hg.openjdk.java.net> Changeset: 10a1ab9e20a4 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/10a1ab9e20a4 Added tag jdk8-b98 for changeset 542b7803f038 ! .hgtags Changeset: 81cbb18d558a Author: lana Date: 2013-07-17 00:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/81cbb18d558a Merge From lana.steuck at oracle.com Wed Jul 17 12:02:09 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 Jul 2013 19:02:09 +0000 Subject: hg: jdk8/tl/jdk: 5 new changesets Message-ID: <20130717190344.40F0348169@hg.openjdk.java.net> Changeset: 2c26ccf0a85b Author: tbell Date: 2013-07-08 07:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c26ccf0a85b 8012925: [parfait] Missing return value in jdk/src/macosx/native/sun/awt/AWTEvent.m Reviewed-by: katleman, leonidr Contributed-by: petr.pchelko at oracle.com ! src/macosx/native/sun/awt/AWTEvent.m Changeset: c4908732fef5 Author: katleman Date: 2013-07-08 14:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4908732fef5 Merge Changeset: 758c21301545 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/758c21301545 Added tag jdk8-b98 for changeset c4908732fef5 ! .hgtags Changeset: f83794805201 Author: mcimadamore Date: 2013-07-11 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f83794805201 8016281: The SAM method should be passed to the metafactory as a MethodType not a MethodHandle 8020010: Move lambda bridge creation from metafactory and VM to compiler Summary: JDK/metafactory component of the bridge fix and and MethodType vs. MethodHandle changes. Reviewed-by: twisti, briangoetz, forax Contributed-by: robert.field at oracle.com ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/SerializedLambda.java Changeset: cbdd2529d93a Author: lana Date: 2013-07-17 00:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cbdd2529d93a Merge From lana.steuck at oracle.com Wed Jul 17 12:01:54 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 Jul 2013 19:01:54 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b98 for changeset 3370fb6146e4 Message-ID: <20130717190158.9338448164@hg.openjdk.java.net> Changeset: 3f67804ab613 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/3f67804ab613 Added tag jdk8-b98 for changeset 3370fb6146e4 ! .hgtags From lana.steuck at oracle.com Wed Jul 17 12:02:06 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 Jul 2013 19:02:06 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130717190220.0D7F948168@hg.openjdk.java.net> Changeset: bdeef606be8e Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bdeef606be8e Added tag jdk8-b98 for changeset ce5a90df517b ! .hgtags Changeset: 39ec5d8a691b Author: mcimadamore Date: 2013-07-11 14:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/39ec5d8a691b 8016281: The SAM method should be passed to the metafactory as a MethodType not a MethodHandle 8020010: Move lambda bridge creation from metafactory and VM to compiler Summary: langtools/javac component of the bridge support and MethodType vs. MethodHandle changes. Reviewed-by: jjg, vromero, briangoetz, forax Contributed-by: robert.field at oracle.com ! 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/LambdaToMethod.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/util/Names.java + test/tools/javac/generics/bridges/Bridge.java + test/tools/javac/generics/bridges/BridgeHarness.java + test/tools/javac/generics/bridges/Bridges.java + test/tools/javac/generics/bridges/tests/TestBridgeWithDefault.java + test/tools/javac/generics/bridges/tests/TestClassAndInterfaceBridgeIdentical01.java + test/tools/javac/generics/bridges/tests/TestClassAndInterfaceBridgeIdentical02.java + test/tools/javac/generics/bridges/tests/TestNoBridgeInSiblingsSuper.java + test/tools/javac/generics/bridges/tests/TestNoDuplicateBridges01.java + test/tools/javac/generics/bridges/tests/TestNoDuplicateBridges02.java + test/tools/javac/lambda/bridge/TestMetafactoryBridges.java ! test/tools/javac/lambda/lambdaExpression/LambdaTest6.java ! test/tools/javac/lambda/methodReference/BridgeMethod.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java Changeset: e990e6bcecbe Author: lana Date: 2013-07-17 10:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e990e6bcecbe Merge ! 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 From lana.steuck at oracle.com Wed Jul 17 12:02:29 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 Jul 2013 19:02:29 +0000 Subject: hg: jdk8/tl/hotspot: 69 new changesets Message-ID: <20130717190504.8CA854816A@hg.openjdk.java.net> Changeset: 8c4424890028 Author: amurillo Date: 2013-06-28 02:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8c4424890028 8019302: new hotspot build - hs25-b40 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8cff1de240de Author: zgu Date: 2013-06-25 17:22 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8cff1de240de 8017478: Kitchensink crashed with SIGSEGV in BaselineReporter::diff_callsites Summary: Fixed possible NULL pointer that caused SIGSEGV Reviewed-by: coleenp, acorn, ctornqvi ! src/share/vm/services/memReporter.cpp Changeset: c14867f95c60 Author: zgu Date: 2013-06-25 14:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c14867f95c60 Merge Changeset: 38ea2efa32a7 Author: kevinw Date: 2013-06-26 00:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/38ea2efa32a7 8010278: SA: provide mechanism for using an alternative SA debugger back-end. Reviewed-by: sla, dsamersoff ! agent/src/share/classes/sun/jvm/hotspot/CLHSDB.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxOopHandle.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java Changeset: 8eb40545e209 Author: kevinw Date: 2013-06-26 11:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8eb40545e209 Merge Changeset: 221df7e37535 Author: iklam Date: 2013-06-27 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/221df7e37535 8016075: Win32 crash with CDS enabled and small heap size Summary: Fixed MetaspaceShared::is_in_shared_space Reviewed-by: coleenp, hseigel ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: e0fe0c9a88da Author: nloodin Date: 2013-06-28 14:05 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0fe0c9a88da Merge Changeset: bb4f2b27e824 Author: dcubed Date: 2013-06-29 11:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bb4f2b27e824 Merge Changeset: 97c5acae48be Author: hseigel Date: 2013-06-30 09:59 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/97c5acae48be 7007040: Check of capacity paramenters in JNI_PushLocalFrame is wrong Summary: changed AND to OR Reviewed-by: coleenp, hseigel Contributed-by: lois.foltan at oracle.com ! src/share/vm/prims/jni.cpp Changeset: 068b406e307f Author: fparain Date: 2013-07-01 09:13 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/068b406e307f 7060111: race condition in VMError::report_and_die() Reviewed-by: zgu, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: acfa2cc19146 Author: rbackman Date: 2013-06-12 09:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/acfa2cc19146 8016444: Duplicate zombie check in safe_for_sender Reviewed-by: dholmes, sla ! src/cpu/sparc/vm/frame_sparc.cpp ! src/share/vm/memory/referenceProcessorStats.hpp Changeset: 993dfb57c575 Author: egahlin Date: 2013-06-26 17:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/993dfb57c575 8016331: Minor issues in event tracing metadata Reviewed-by: stefank, brutisso, mgronlun ! src/share/vm/trace/trace.xml Changeset: 7f11c12d7a90 Author: sspitsyn Date: 2013-07-01 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7f11c12d7a90 8009204: [dtrace] signatures returned by Java 7 jstack() are corrupted on Solaris Summary: The fix is basically a backport of JDK-7019165 (pstack issue) to jhelper.d. Reviewed-by: coleenp, sspitsyn Contributed-by: tomas.hurka at oracle.com ! src/os/solaris/dtrace/jhelper.d Changeset: de2d15ce3d4a Author: coleenp Date: 2013-07-02 08:42 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de2d15ce3d4a 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadata space could occur when metaspace is almost empty Summary: Allocate medium chunks for class metaspace when class loader has lots of classes Reviewed-by: mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: cedf20e2a655 Author: coleenp Date: 2013-07-02 16:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cedf20e2a655 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c92b74c62d97 Author: brutisso Date: 2013-06-27 09:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c92b74c62d97 8017483: G1 tests fail with native OOME on Solaris x86 after HeapBaseMinAddress has been increased Summary: Set HeapBaseMinAddress as default rather than ergo Reviewed-by: stefank, jmasa, kvn ! src/share/vm/runtime/arguments.cpp Changeset: 3ea89789ba39 Author: ehelin Date: 2013-06-28 18:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3ea89789ba39 Merge Changeset: b30744960351 Author: brutisso Date: 2013-06-30 21:42 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b30744960351 8014022: G1: Non Java threads should lock the shared SATB queue lock without safepoint checks. Reviewed-by: tschatzl, brutisso, jmasa, ysr Contributed-by: per.liden at oracle.com ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp Changeset: 5ea20b3bd249 Author: johnc Date: 2013-07-01 09:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ea20b3bd249 8017070: G1: assert(_card_counts[card_num] <= G1ConcRSHotCardLimit) failed Summary: The assert is invalid when a card is being refined by two different threads and its count crosses the hot threshold - the refinement count will be updated once by each thread triggering the assert. Remove the assert and update the count using a bounded expression. Reviewed-by: jmasa, tamao, brutisso ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp Changeset: 6e3634222155 Author: tamao Date: 2013-06-28 20:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e3634222155 8017611: Auto corrector for mistyped vm options Summary: The auto corrector for mistyped vm options fuzzy-matches existing flags based on string similarity (Dice's coefficient). Reviewed-by: kvn, dsamersoff, hseigel, johnc ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp + test/gc/arguments/TestUnrecognizedVMOptionsHandling.java Changeset: 536976a22f5f Author: tamao Date: 2013-07-03 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/536976a22f5f Merge Changeset: 70bea4a43c6d Author: tamao Date: 2013-07-03 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/70bea4a43c6d Merge Changeset: ac7193063af8 Author: jiangli Date: 2013-07-01 19:44 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ac7193063af8 8006023: Embedded Builds fail management test because of requirement for UsePerfData being enabled. Summary: Added -XX:+UsePerfData to Test7196045.java. Reviewed-by: dholmes, collins ! test/runtime/7196045/Test7196045.java Changeset: 94aa8de029c5 Author: clucasius Date: 2013-07-03 22:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/94aa8de029c5 Merge Changeset: fea6a49c2762 Author: bdelsart Date: 2013-07-04 01:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fea6a49c2762 Merge Changeset: f765bfec8f07 Author: kvn Date: 2013-07-01 12:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f765bfec8f07 8006629: NEED_TEST: need test for JDK-8001071 Summary: added regression test Reviewed-by: kvn, coleenp Contributed-by: Filipp Zhinkin + test/runtime/8001071/Test8001071.java + test/runtime/8001071/Test8001071.sh Changeset: a023ec3452c7 Author: simonis Date: 2013-07-01 14:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a023ec3452c7 8019382: PPC64: Fix bytecodeInterpreter to compile with '-Wunused-value' Summary: cast the offending expressions to (void) Reviewed-by: kvn, coleenp ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 2b3fe74309b6 Author: kvn Date: 2013-07-02 10:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b3fe74309b6 8019247: SIGSEGV in compiled method c8e.e.t_.getArray(Ljava/lang/Class;)[Ljava/lang/Object Summary: Undo recent changes (and add more comments) in Ideal_allocation(). Reviewed-by: roland ! src/share/vm/opto/graphKit.cpp Changeset: 738e04fb1232 Author: anoll Date: 2013-07-02 07:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/738e04fb1232 8014972: Crash with specific values for -XX:InitialCodeCacheSize=500K -XX:ReservedCodeCacheSize=500k Summary: Introduce a minimum code cache size that guarantees that the VM can startup. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: b800986664f4 Author: drchase Date: 2013-07-02 20:42 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b800986664f4 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 Summary: add intrinsics using new instruction to interpreter, C1, C2, for suitable x86; add test Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp + src/cpu/x86/vm/stubRoutines_x86.cpp + src/cpu/x86/vm/stubRoutines_x86.hpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp + test/compiler/7088419/CRCTest.java Changeset: c1bd7b5bdc70 Author: twisti Date: 2013-07-02 20:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c1bd7b5bdc70 8017571: JSR292: JVM crashing on assert "cast to instanceKlass" while producing MethodHandle for array methods with MethodHandle.findVirtual Reviewed-by: kvn ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/reflection.cpp Changeset: bed0eddd82cd Author: twisti Date: 2013-07-02 22:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bed0eddd82cd Merge Changeset: 8b789ce47503 Author: roland Date: 2013-07-04 01:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b789ce47503 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: fece0ee013fc Author: roland Date: 2013-07-04 03:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fece0ee013fc Merge Changeset: c9dd82da51ed Author: amurillo Date: 2013-07-04 14:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9dd82da51ed Merge Changeset: 30b5b75c42ac Author: amurillo Date: 2013-07-04 14:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/30b5b75c42ac Added tag hs25-b40 for changeset c9dd82da51ed ! .hgtags Changeset: 1a3390aa8326 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a3390aa8326 Added tag jdk8-b98 for changeset 30b5b75c42ac ! .hgtags Changeset: ea4d24c1e0c6 Author: amurillo Date: 2013-07-04 14:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ea4d24c1e0c6 8019934: new hotspot build - hs25-b41 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f323bbb0e6c1 Author: coleenp Date: 2013-07-03 13:45 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f323bbb0e6c1 8019833: Wrong JNI error code for preexisting JVM Summary: Return the appropriate JNI error message (instead of the generic one) when the JVM is already started Reviewed-by: coleenp, hseigel Contributed-by: sylvestre at debian.org ! src/share/vm/prims/jni.cpp Changeset: 5f7a4367c787 Author: zgu Date: 2013-07-04 06:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5f7a4367c787 8016074: NMT: assertion failed: assert(thread->thread_state() == from) failed: coming from wrong thread state Summary: Uses os::NakedYield() on Solaris instead of os::yield_all() Reviewed-by: acorn, coleenp, hseigel ! src/share/vm/services/memTracker.hpp Changeset: a55aa67bce1a Author: zgu Date: 2013-07-04 04:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a55aa67bce1a Merge Changeset: 59b052799158 Author: dcubed Date: 2013-07-04 21:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/59b052799158 8015884: runThese crashed with SIGSEGV, hs_err has an error instead of stacktrace Summary: Dl_info struct should only be used if dladdr() has returned non-zero (no errors) and always check the dladdr() return value; Dl_info.dli_sname and Dl_info.dli_saddr fields should only be used if non-NULL; update/improve runtime/6888954/vmerrors.sh test Reviewed-by: dsamersoff, zgu, hseigel, coleenp ! 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/os/windows/vm/os_windows.hpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! test/runtime/6888954/vmerrors.sh Changeset: 93e6dce53ba7 Author: fparain Date: 2013-07-05 08:26 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/93e6dce53ba7 8016465: The hs_err file gets wrong name Reviewed-by: dcubed, dholmes, rdurbin ! src/share/vm/utilities/vmError.cpp Changeset: cc5b7915104e Author: fparain Date: 2013-07-05 08:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc5b7915104e Merge Changeset: cf9d71d3e474 Author: iklam Date: 2013-07-08 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cf9d71d3e474 8016903: Thread::_handle_area initial size too big Summary: Changed initial size to Chunk::tiny_size (216 bytes) Reviewed-by: coleenp, dholmes, sspitsyn ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/handles.hpp Changeset: 71180a6e5080 Author: jiangli Date: 2013-07-03 17:26 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/71180a6e5080 7133260: AllocationProfiler uses space in metadata and doesn't seem to do anything useful. Summary: Remove -Xaprof and Klass::_alloc_count & ArrayKlass::_alloc_size. Reviewed-by: stefank, coleenp ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.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/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fa6929d0b0a9 Author: jiangli Date: 2013-07-08 14:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fa6929d0b0a9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3c7b4b7b2625 Author: jiangli Date: 2013-07-08 14:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c7b4b7b2625 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ba9dacff9c9d Author: hseigel Date: 2013-07-08 19:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ba9dacff9c9d 8014399: Remove JVM_SetProtectionDomain from hotspot Summary: JVM_SetProtectionDomain has been deprecated since 1.5 and is being removed Reviewed-by: coleenp, hseigel 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/javaClasses.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 26037663c2a6 Author: hseigel Date: 2013-07-08 16:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/26037663c2a6 Merge Changeset: e79a9f26ba2e Author: hseigel Date: 2013-07-08 18:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e79a9f26ba2e Merge Changeset: 72fce0b2d341 Author: zgu Date: 2013-07-09 13:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/72fce0b2d341 8011760: assert(delta != 0) failed: dup pointer in MemBaseline::malloc_sort_by_addr Summary: Some of qsort implementation on Linux x86 compares element to itself, which is mistakenly treated as duplicate pointer Reviewed-by: dcubed, acorn ! src/share/vm/services/memBaseline.cpp Changeset: 2839ce15e450 Author: zgu Date: 2013-07-09 19:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2839ce15e450 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: 50257d6f5aaa Author: acorn Date: 2013-07-09 14:02 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/50257d6f5aaa 8013635: VM should no longer create bridges for generic signatures. Summary: Requires: 8013789: Compiler bridges, 8015402: metafactory Reviewed-by: sspitsyn, coleenp, bharadwaj ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/runtime/globals.hpp Changeset: 22baec423e2f Author: acorn Date: 2013-07-09 22:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22baec423e2f Merge Changeset: e50be1620201 Author: goetz Date: 2013-07-08 14:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e50be1620201 8020059: The flag introduced by 8014972 is not defined if Hotspot is built without a compiler (zero, ppc64 core build). Summary: define CodeCacheMinimumUseSpace flag for cppInterpeter build. Reviewed-by: kvn ! src/share/vm/runtime/globals.hpp Changeset: e554162ab094 Author: adlertz Date: 2013-07-09 17:20 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e554162ab094 8019625: Test compiler/8005956/PolynomialRoot.java timeouts on Solaris SPARCs Summary: Disable the test for SPARC and reduce the number of test iterations Reviewed-by: kvn ! test/compiler/8005956/PolynomialRoot.java Changeset: b42fe1a8e180 Author: drchase Date: 2013-07-09 08:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b42fe1a8e180 8017578: Hotspot compilation error with latest Studio compiler Summary: Make the destructor virtual (note more non-compiler hotspot errors occur downstream) Reviewed-by: kvn, twisti ! src/share/vm/adlc/forms.hpp Changeset: 7ac80525ece9 Author: anoll Date: 2013-07-09 11:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ac80525ece9 8015635: Crash when specifying very large code cache size Summary: Limit the size of the code cache to at most 2G when arguments are checked; added regression test Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp + test/compiler/codecache/CheckUpperLimit.java Changeset: 5f533e38e7d5 Author: twisti Date: 2013-07-09 22:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5f533e38e7d5 Merge Changeset: dec841e0c9aa Author: anoll Date: 2013-07-10 13:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dec841e0c9aa 8016749: -XX:+UseISM fails an assert(obj->is_oop()) when running SPECjbb2005 Summary: Remove obsolete code that relates to ISM which was used only on Solaris 8. Reviewed-by: kvn, twisti ! src/os/solaris/vm/globals_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/share/vm/runtime/arguments.cpp Changeset: ec173c8f3739 Author: roland Date: 2013-07-11 01:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ec173c8f3739 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2cbc8f3011a0 Author: ehelin Date: 2013-06-05 09:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2cbc8f3011a0 8015972: Refactor the sending of the object count after GC event Reviewed-by: brutisso, pliden ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp + src/share/vm/gc_implementation/shared/objectCountEventSender.cpp + src/share/vm/gc_implementation/shared/objectCountEventSender.hpp ! src/share/vm/memory/heapInspection.hpp - src/share/vm/memory/klassInfoClosure.hpp Changeset: 63cffb381adc Author: ehelin Date: 2013-06-12 15:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/63cffb381adc 8016170: GC id variable in gcTrace.cpp should use typedef GCId Reviewed-by: johnc, jwilhelm, jmasa ! src/share/vm/gc_implementation/shared/gcTrace.cpp Changeset: 6aa440bc1125 Author: ehelin Date: 2013-06-12 15:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6aa440bc1125 8015683: object_count_after_gc should have the same timestamp for all events Reviewed-by: mgerdin, stefank ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.hpp Changeset: 27c53c9f3a7e Author: ehelin Date: 2013-07-10 15:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/27c53c9f3a7e 8013939: Metaspace capacity not available Reviewed-by: tschatzl, mgerdin, stefank ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 0f631140d13b Author: tamao Date: 2013-07-11 11:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f631140d13b Merge - src/share/vm/memory/klassInfoClosure.hpp Changeset: 2b9946e10587 Author: amurillo Date: 2013-07-12 16:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b9946e10587 Merge - src/share/vm/memory/klassInfoClosure.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ea979302bb70 Author: amurillo Date: 2013-07-12 16:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ea979302bb70 Added tag hs25-b41 for changeset 2b9946e10587 ! .hgtags From lana.steuck at oracle.com Wed Jul 17 12:02:00 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 Jul 2013 19:02:00 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20130717190211.4493348167@hg.openjdk.java.net> Changeset: adf49c3ef83c Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/adf49c3ef83c Added tag jdk8-b98 for changeset 15e5bb51bc0c ! .hgtags Changeset: 74ec7b48e3be Author: lana Date: 2013-07-17 00:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/74ec7b48e3be Merge From yumin.qi at oracle.com Wed Jul 17 17:10:29 2013 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Thu, 18 Jul 2013 00:10:29 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 Message-ID: <20130718001032.DD8D348181@hg.openjdk.java.net> Changeset: 732af649bc3a Author: ccheung Date: 2013-07-17 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/732af649bc3a 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 Summary: Added (sig < MAXSIGNUM) check in jsig.c Reviewed-by: dholmes, acorn ! src/os/linux/vm/jsig.c + test/runtime/jsig/Test8017498.sh + test/runtime/jsig/TestJNI.c + test/runtime/jsig/TestJNI.java From jonathan.gibbons at oracle.com Wed Jul 17 18:19:24 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 18 Jul 2013 01:19:24 +0000 Subject: hg: jdk8/tl/langtools: 8014636: TestLiteralCodeInPre fails on windows Message-ID: <20130718011931.069B048183@hg.openjdk.java.net> Changeset: 80e75aa6a707 Author: jjg Date: 2013-07-17 18:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/80e75aa6a707 8014636: TestLiteralCodeInPre fails on windows Reviewed-by: ksrini ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! test/com/sun/javadoc/testCRLineSeparator/TestCRLineSeparator.java ! test/com/sun/javadoc/testLeadingSpaces/LeadingSpaces.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testLiteralCodeInPre/TestLiteralCodeInPre.java ! test/com/sun/javadoc/testRelativeLinks/TestRelativeLinks.java From jonathan.gibbons at oracle.com Wed Jul 17 19:16:35 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 18 Jul 2013 02:16:35 +0000 Subject: hg: jdk8/tl/langtools: 8020664: doclint gives incorrect warnings on normal package statements Message-ID: <20130718021638.82C1748189@hg.openjdk.java.net> Changeset: 1476d54fdc61 Author: jjg Date: 2013-07-17 19:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1476d54fdc61 8020664: doclint gives incorrect warnings on normal package statements Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! test/tools/doclint/BadPackageCommentTest.out ! test/tools/doclint/DocLintTester.java + test/tools/doclint/packageTests/bad/Test.java + test/tools/doclint/packageTests/bad/Test.out + test/tools/doclint/packageTests/bad/package-info.java + test/tools/doclint/packageTests/bad/package-info.out + test/tools/doclint/packageTests/good/Test.java + test/tools/doclint/packageTests/good/package-info.java From jonathan.gibbons at oracle.com Wed Jul 17 19:12:28 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 18 Jul 2013 02:12:28 +0000 Subject: hg: jdk8/tl/langtools: 8020313: doclint doesn't reset HTML anchors correctly Message-ID: <20130718021233.D097348187@hg.openjdk.java.net> Changeset: 1e533c1bfb01 Author: jjg Date: 2013-07-17 19:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1e533c1bfb01 8020313: doclint doesn't reset HTML anchors correctly Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/AnchorTest2.java + test/tools/doclint/AnchorTest2.out + test/tools/doclint/AnchorTest2a.java From jiangli.zhou at oracle.com Wed Jul 17 19:29:51 2013 From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com) Date: Thu, 18 Jul 2013 02:29:51 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130718022955.1C9574818A@hg.openjdk.java.net> Changeset: 825e6cb66923 Author: jiangli Date: 2013-07-17 18:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/825e6cb66923 8020309: Eliminate InstanceKlass::_cached_class_file_len. Summary: Use JvmtiCachedClassFileData. Reviewed-by: iklam, sspitsyn, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: 6388dbc4b7ca Author: jiangli Date: 2013-07-17 17:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6388dbc4b7ca Merge From jaroslav.bachorik at oracle.com Thu Jul 18 02:54:52 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 18 Jul 2013 11:54:52 +0200 Subject: jmx-dev RFR: 8002307 javax.management.modelmbean.ModelMBeanInfoSupport may expose internal representation by storing an externally mutable object In-Reply-To: <51A4DC90.7050809@oracle.com> References: <51A4AB45.4070100@oracle.com> <51A4DC90.7050809@oracle.com> Message-ID: <51E7BB6C.6030704@oracle.com> Hi, thanks for the comments. Here (http://cr.openjdk.java.net/~jbachorik/8002307/webrev.03/) is the updated webrev implementing suggestions from Daniel and Shanliang. -JB- From poonam.bajaj at oracle.com Thu Jul 18 03:20:33 2013 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Thu, 18 Jul 2013 15:50:33 +0530 Subject: RFR: 8015576: CMS: svc agent throws java.lang.RuntimeException: No type named "FreeList" in database In-Reply-To: <51E3F94D.7080602@oracle.com> References: <51D58BCC.4030803@oracle.com> <51E3F94D.7080602@oracle.com> Message-ID: <51E7C171.7020507@oracle.com> Hi Vladimir, The changes look good. Thanks, Poonam On 7/15/2013 6:59 PM, Vladimir Kempik wrote: > Can I have a couple of reviewers for this please ? > This is urgent now, as ZBB for 7u40 is nearing. > > Thanks > On 04.07.2013 18:50, Vladimir Kempik wrote: >> Hi all, >> >> this change fixes an issue where we could not run jmap -heap on a >> java process running with -XX:+UseConcMarkSweepGC. >> >> Partially (1 line) it's a backport of >> http://bugs.sun.com/view_bug.do?bug_id=8005278 from jdk8 >> >> The problem originated from the following change in hotspot: >> changeset 3294:9f059abe8cf2 >> parent 3284:3c91f2c9fd21 >> 7131629: Generalize the CMS free list code >> >> --- >> a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Fri >> Apr 20 17:13:36 2012 -0700 >> +++ >> b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Thu >> Mar 29 19:46:24 2012 -0700 >> @@ -44,11 +44,11 @@ >> nonstatic_field(FreeChunk, _next, FreeChunk*) \ >> nonstatic_field(FreeChunk, _prev, FreeChunk*) \ >> nonstatic_field(LinearAllocBlock, _word_size, size_t) \ >> - nonstatic_field(FreeList, _size, size_t) \ >> - nonstatic_field(FreeList, _count, ssize_t) \ >> - nonstatic_field(BinaryTreeDictionary, _totalSize, size_t) \ >> - nonstatic_field(CompactibleFreeListSpace, _dictionary, >> FreeBlockDictionary*) \ >> - nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >> FreeList) \ >> + nonstatic_field(FreeList, _size, size_t) \ >> + nonstatic_field(FreeList, _count, ssize_t) \ >> + nonstatic_field(BinaryTreeDictionary,_totalSize, size_t) \ >> + nonstatic_field(CompactibleFreeListSpace, _dictionary, >> FreeBlockDictionary*) \ >> + nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >> FreeList) \ >> nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >> LinearAllocBlock) >> @@ -70,13 +70,13 @@ >> declare_toplevel_type(CompactibleFreeListSpace*) \ >> declare_toplevel_type(CMSCollector*) \ >> declare_toplevel_type(FreeChunk*) \ >> - declare_toplevel_type(BinaryTreeDictionary*) \ >> - declare_toplevel_type(FreeBlockDictionary*) \ >> - declare_toplevel_type(FreeList*) \ >> - declare_toplevel_type(FreeList) \ >> + declare_toplevel_type(BinaryTreeDictionary*) \ >> + declare_toplevel_type(FreeBlockDictionary*) \ >> + declare_toplevel_type(FreeList*) \ >> + declare_toplevel_type(FreeList) \ >> declare_toplevel_type(LinearAllocBlock) \ >> - declare_toplevel_type(FreeBlockDictionary) \ >> - declare_type(BinaryTreeDictionary, FreeBlockDictionary) >> + declare_toplevel_type(FreeBlockDictionary) \ >> + declare_type(BinaryTreeDictionary, >> FreeBlockDictionary) >> #define VM_INT_CONSTANTS_CMS(declare_constant) \ >> declare_constant(Generation::ConcurrentMarkSweep) \ >> >> >> This fix updates the SA code to be like the hotspot code. >> >> Webrev: http://cr.openjdk.java.net/~mcherkas/vladimir/8015576/webrev.00/ >> >> Testing: >> - JPRT >> - Running jmap -heap successfully on a java process using >> -XX:+UseConcMarkSweepGC >> >> Thanks, >> Vladimir > From rickard.backman at oracle.com Thu Jul 18 03:37:18 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Thu, 18 Jul 2013 12:37:18 +0200 Subject: RFR(S): 8020701: Avoid crashes in WatcherThread In-Reply-To: References: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> <51E6CE46.3030302@oracle.com> Message-ID: <51400C27-933D-433D-BF86-4351213F2D5D@oracle.com> Hi, here is the updated webrev containing Dans suggested changes. I also had to change the assert check in os::malloc, we discovered it wasn't safe to check Thread::current() since os::malloc() can be called when the libjvm is loaded / initialized and we don't have a thread yet. Changing to logic a bit to require that the WatcherThread exists before looking up the thread and doing it by ThreadLocalStorage::get_thread_slow() makes it safe. That is the only code change, other changes are comments or newlines in code (thread.hpp). See the updated webrev: http://cr.openjdk.java.net/~rbackman/8020701.1/ Thanks /R On Jul 17, 2013, at 8:12 PM, Rickard B?ckman wrote: > > On Jul 17, 2013, at 7:03 PM, Daniel D. Daugherty wrote: > >> On 7/17/13 5:58 AM, Rickard B?ckman wrote: >>> Hi all, >>> >>> can I please have reviews for the following change? >>> >>> We are adding a mechanism for avoiding some crashes in the WatcherThread using different OS-specific methods. >>> >>> Webrev: http://cr.openjdk.java.net/~rbackman/8020701/webrev/ >>> >>> Thanks >>> /R >> >> Thumbs up! The bug mentions a few tests where you think this new >> infrastructure will help diagnose the failures modes for those tests. >> However, are there any new tests targeted to exercise this code? > > Not diagnose the failures, but avoid the crashes they are currently causing. > Since at least one of them haven't been fixed yet (working on it) it will work as > a good verifier at the moment. When the bug is gone, it is harder. It is a bit hard > to write a test that causes the VM to crash at random but specific places. Eventually > we could do something with the whitebox api, but the crashes would only happen at > very specific places in that case making them a bit less interesting. > >> >> >> src/share/vm/runtime/os.hpp >> No comments. >> >> src/share/vm/runtime/os.cpp >> No comments. >> >> src/share/vm/runtime/thread.hpp >> line 756: void set_crash_protection(os::WatcherThreadCrashProtection* crash_protection) { assert(Thread::current()->is_Watcher_thread(), "Can only be set by WatcherThread"); _crash_protection = crash_protection; } >> This line is ridiculously long. Please reformat it to fit in 80 cols. > > Ok > >> >> src/share/vm/runtime/thread.cpp >> No comments. >> >> src/os/posix/vm/os_posix.hpp >> Nice comment. Hopefully it will keep anyone from doing something >> dangerous in the future. > > :) > >> >> src/os/posix/vm/os_posix.cpp' >> Please add the following line above 268: >> >> * See the caveats for this class in os_posix.hpp. > > Ok > >> >> src/os/windows/vm/os_windows.hpp >> No comments. >> >> src/os/windows/vm/os_windows.cpp >> line 4692 * Protects the callback call so that S jumps back into this method >> Stale comment? What is 'S'? > > typo. Should be something like raised EXCEPTIONS causes a jump back into this method. > >> >> Please add the following line above 4692: >> >> * See the caveats for this class in os_windows.hpp. >> >> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >> line 405: // (no destructors run) >> Please change to "(no destructors can be run)" > > Ok > >> >> src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp >> line 557: // (no destructors run) >> Please change to "(no destructors can be run)" >> >> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >> line 229: // (no destructors run) >> Please change to "(no destructors can be run)" >> >> src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp >> line 319: // (no destructors run) >> Please change to "(no destructors can be run)" >> >> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >> line 378: // (no destructors run) >> Please change to "(no destructors can be run)" >> >> src/share/vm/runtime/mutex.cpp >> No comments. >> >> Dan >> > > Thanks for the review! > > /R > From daniel.fuchs at oracle.com Thu Jul 18 05:11:37 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 18 Jul 2013 14:11:37 +0200 Subject: jmx-dev RFR: 8002307 javax.management.modelmbean.ModelMBeanInfoSupport may expose internal representation by storing an externally mutable object In-Reply-To: <51E7BB6C.6030704@oracle.com> References: <51A4AB45.4070100@oracle.com> <51A4DC90.7050809@oracle.com> <51E7BB6C.6030704@oracle.com> Message-ID: <51E7DB79.2010504@oracle.com> Hi Jaroslav, Looks good overall. Small nit: You should remove the comment lines 322-327 in ModelMBeanInfoSupport.java since your changes make it obsolete. Also the copyright year in ImmutableDataTest should be 2013 (not 2005). No need for another round of review. -- daniel On 7/18/13 11:54 AM, Jaroslav Bachorik wrote: > Hi, > > thanks for the comments. > > Here (http://cr.openjdk.java.net/~jbachorik/8002307/webrev.03/) is the > updated webrev implementing suggestions from Daniel and Shanliang. > > -JB- > > From david.holmes at oracle.com Thu Jul 18 05:45:55 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 18 Jul 2013 12:45:55 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8020697: jniCheck.cpp:check_is_obj_array asserts on TypeArrayKlass::cast(aOop->klass()) Message-ID: <20130718124602.7F152481A2@hg.openjdk.java.net> Changeset: c29568b733d2 Author: dholmes Date: 2013-07-18 06:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c29568b733d2 8020697: jniCheck.cpp:check_is_obj_array asserts on TypeArrayKlass::cast(aOop->klass()) Reviewed-by: dcubed, fparain, dholmes Contributed-by: David Simms ! src/share/vm/prims/jniCheck.cpp From daniel.daugherty at oracle.com Thu Jul 18 06:09:40 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 18 Jul 2013 07:09:40 -0600 Subject: RFR(S): 8020701: Avoid crashes in WatcherThread In-Reply-To: <51400C27-933D-433D-BF86-4351213F2D5D@oracle.com> References: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> <51E6CE46.3030302@oracle.com> <51400C27-933D-433D-BF86-4351213F2D5D@oracle.com> Message-ID: <51E7E914.1010807@oracle.com> > http://cr.openjdk.java.net/~rbackman/8020701.1/ Thumbs up! src/os/posix/vm/os_posix.cpp Can you reformat the new lines that are over 80 cols? No need to re-review that change if you do it. src/os/posix/vm/os_posix.hpp No comments. src/os/windows/vm/os_windows.cpp The os_posix.cpp funcation has these: 274 assert(Thread::current()->is_Watcher_thread(), "Only for WatcherThread"); 275 assert(!WatcherThread::watcher_thread()->has_crash_protection(), "crash_protection already set?"); but the Windows version of WatcherThreadCrashProtection::call() does not. Any particular reason for the difference? Sorry I missed this in the first round. src/os/windows/vm/os_windows.hpp No comments. src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp src/os_cpu/linux_x86/vm/os_linux_x86.cpp src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp No comments. src/share/vm/runtime/mutex.cpp The new assert line is well past 80 cols. Again, no need to re-review. src/share/vm/runtime/os.cpp line 600: // since os::malloc can be called when the libjvm.{dll.so} is typo: '{dll.so}' -> '{dll,so}' line 601: // loaded and we don't have a thread yet. Please change "loaded" -> "first loaded" src/share/vm/runtime/os.hpp No comments. src/share/vm/runtime/thread.cpp No comments. src/share/vm/runtime/thread.hpp No comments. Dan On 7/18/13 4:37 AM, Rickard B?ckman wrote: > Hi, > > here is the updated webrev containing Dans suggested changes. > I also had to change the assert check in os::malloc, we discovered it wasn't safe to check Thread::current() since os::malloc() can be called when the libjvm is loaded / initialized and we don't have a thread yet. > Changing to logic a bit to require that the WatcherThread exists before looking up the thread and doing it by ThreadLocalStorage::get_thread_slow() makes it safe. > > That is the only code change, other changes are comments or newlines in code (thread.hpp). > > See the updated webrev: > http://cr.openjdk.java.net/~rbackman/8020701.1/ > > Thanks > /R > > > On Jul 17, 2013, at 8:12 PM, Rickard B?ckman wrote: > >> On Jul 17, 2013, at 7:03 PM, Daniel D. Daugherty wrote: >> >>> On 7/17/13 5:58 AM, Rickard B?ckman wrote: >>>> Hi all, >>>> >>>> can I please have reviews for the following change? >>>> >>>> We are adding a mechanism for avoiding some crashes in the WatcherThread using different OS-specific methods. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rbackman/8020701/webrev/ >>>> >>>> Thanks >>>> /R >>> Thumbs up! The bug mentions a few tests where you think this new >>> infrastructure will help diagnose the failures modes for those tests. >>> However, are there any new tests targeted to exercise this code? >> Not diagnose the failures, but avoid the crashes they are currently causing. >> Since at least one of them haven't been fixed yet (working on it) it will work as >> a good verifier at the moment. When the bug is gone, it is harder. It is a bit hard >> to write a test that causes the VM to crash at random but specific places. Eventually >> we could do something with the whitebox api, but the crashes would only happen at >> very specific places in that case making them a bit less interesting. >> >>> >>> src/share/vm/runtime/os.hpp >>> No comments. >>> >>> src/share/vm/runtime/os.cpp >>> No comments. >>> >>> src/share/vm/runtime/thread.hpp >>> line 756: void set_crash_protection(os::WatcherThreadCrashProtection* crash_protection) { assert(Thread::current()->is_Watcher_thread(), "Can only be set by WatcherThread"); _crash_protection = crash_protection; } >>> This line is ridiculously long. Please reformat it to fit in 80 cols. >> Ok >> >>> src/share/vm/runtime/thread.cpp >>> No comments. >>> >>> src/os/posix/vm/os_posix.hpp >>> Nice comment. Hopefully it will keep anyone from doing something >>> dangerous in the future. >> :) >> >>> src/os/posix/vm/os_posix.cpp' >>> Please add the following line above 268: >>> >>> * See the caveats for this class in os_posix.hpp. >> Ok >> >>> src/os/windows/vm/os_windows.hpp >>> No comments. >>> >>> src/os/windows/vm/os_windows.cpp >>> line 4692 * Protects the callback call so that S jumps back into this method >>> Stale comment? What is 'S'? >> typo. Should be something like raised EXCEPTIONS causes a jump back into this method. >> >>> Please add the following line above 4692: >>> >>> * See the caveats for this class in os_windows.hpp. >>> >>> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >>> line 405: // (no destructors run) >>> Please change to "(no destructors can be run)" >> Ok >> >>> src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp >>> line 557: // (no destructors run) >>> Please change to "(no destructors can be run)" >>> >>> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >>> line 229: // (no destructors run) >>> Please change to "(no destructors can be run)" >>> >>> src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp >>> line 319: // (no destructors run) >>> Please change to "(no destructors can be run)" >>> >>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >>> line 378: // (no destructors run) >>> Please change to "(no destructors can be run)" >>> >>> src/share/vm/runtime/mutex.cpp >>> No comments. >>> >>> Dan >>> >> Thanks for the review! >> >> /R >> From rickard.backman at oracle.com Thu Jul 18 06:58:38 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Thu, 18 Jul 2013 15:58:38 +0200 Subject: RFR(S): 8020701: Avoid crashes in WatcherThread In-Reply-To: <51E7E914.1010807@oracle.com> References: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> <51E6CE46.3030302@oracle.com> <51400C27-933D-433D-BF86-4351213F2D5D@oracle.com> <51E7E914.1010807@oracle.com> Message-ID: <98020C0F-9C51-4C0A-8273-F37FDA93628C@oracle.com> Fixed them all, will start jprt-jobs. Didn't know we were so strict on the 80 columns, considering all the other code in those files? :) Thanks /R On Jul 18, 2013, at 3:09 PM, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~rbackman/8020701.1/ > > Thumbs up! > > src/os/posix/vm/os_posix.cpp > Can you reformat the new lines that are over 80 cols? > No need to re-review that change if you do it. > > src/os/posix/vm/os_posix.hpp > No comments. > > src/os/windows/vm/os_windows.cpp > The os_posix.cpp funcation has these: > > 274 assert(Thread::current()->is_Watcher_thread(), "Only for WatcherThread"); > 275 assert(!WatcherThread::watcher_thread()->has_crash_protection(), "crash_protection already set?"); > > but the Windows version of WatcherThreadCrashProtection::call() > does not. Any particular reason for the difference? > > Sorry I missed this in the first round. > > src/os/windows/vm/os_windows.hpp > No comments. > > src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp > src/os_cpu/linux_x86/vm/os_linux_x86.cpp > src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp > src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp > No comments. > > src/share/vm/runtime/mutex.cpp > The new assert line is well past 80 cols. > Again, no need to re-review. > > src/share/vm/runtime/os.cpp > line 600: // since os::malloc can be called when the libjvm.{dll.so} is > typo: '{dll.so}' > -> '{dll,so}' > > line 601: // loaded and we don't have a thread yet. > Please change "loaded" -> "first loaded" > > src/share/vm/runtime/os.hpp > No comments. > > src/share/vm/runtime/thread.cpp > No comments. > > src/share/vm/runtime/thread.hpp > No comments. > > Dan > > > On 7/18/13 4:37 AM, Rickard B?ckman wrote: >> Hi, >> >> here is the updated webrev containing Dans suggested changes. >> I also had to change the assert check in os::malloc, we discovered it wasn't safe to check Thread::current() since os::malloc() can be called when the libjvm is loaded / initialized and we don't have a thread yet. >> Changing to logic a bit to require that the WatcherThread exists before looking up the thread and doing it by ThreadLocalStorage::get_thread_slow() makes it safe. >> >> That is the only code change, other changes are comments or newlines in code (thread.hpp). >> >> See the updated webrev: >> http://cr.openjdk.java.net/~rbackman/8020701.1/ >> >> Thanks >> /R >> >> >> On Jul 17, 2013, at 8:12 PM, Rickard B?ckman wrote: >> >>> On Jul 17, 2013, at 7:03 PM, Daniel D. Daugherty wrote: >>> >>>> On 7/17/13 5:58 AM, Rickard B?ckman wrote: >>>>> Hi all, >>>>> >>>>> can I please have reviews for the following change? >>>>> >>>>> We are adding a mechanism for avoiding some crashes in the WatcherThread using different OS-specific methods. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8020701/webrev/ >>>>> >>>>> Thanks >>>>> /R >>>> Thumbs up! The bug mentions a few tests where you think this new >>>> infrastructure will help diagnose the failures modes for those tests. >>>> However, are there any new tests targeted to exercise this code? >>> Not diagnose the failures, but avoid the crashes they are currently causing. >>> Since at least one of them haven't been fixed yet (working on it) it will work as >>> a good verifier at the moment. When the bug is gone, it is harder. It is a bit hard >>> to write a test that causes the VM to crash at random but specific places. Eventually >>> we could do something with the whitebox api, but the crashes would only happen at >>> very specific places in that case making them a bit less interesting. >>> >>>> >>>> src/share/vm/runtime/os.hpp >>>> No comments. >>>> >>>> src/share/vm/runtime/os.cpp >>>> No comments. >>>> >>>> src/share/vm/runtime/thread.hpp >>>> line 756: void set_crash_protection(os::WatcherThreadCrashProtection* crash_protection) { assert(Thread::current()->is_Watcher_thread(), "Can only be set by WatcherThread"); _crash_protection = crash_protection; } >>>> This line is ridiculously long. Please reformat it to fit in 80 cols. >>> Ok >>> >>>> src/share/vm/runtime/thread.cpp >>>> No comments. >>>> >>>> src/os/posix/vm/os_posix.hpp >>>> Nice comment. Hopefully it will keep anyone from doing something >>>> dangerous in the future. >>> :) >>> >>>> src/os/posix/vm/os_posix.cpp' >>>> Please add the following line above 268: >>>> >>>> * See the caveats for this class in os_posix.hpp. >>> Ok >>> >>>> src/os/windows/vm/os_windows.hpp >>>> No comments. >>>> >>>> src/os/windows/vm/os_windows.cpp >>>> line 4692 * Protects the callback call so that S jumps back into this method >>>> Stale comment? What is 'S'? >>> typo. Should be something like raised EXCEPTIONS causes a jump back into this method. >>> >>>> Please add the following line above 4692: >>>> >>>> * See the caveats for this class in os_windows.hpp. >>>> >>>> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >>>> line 405: // (no destructors run) >>>> Please change to "(no destructors can be run)" >>> Ok >>> >>>> src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp >>>> line 557: // (no destructors run) >>>> Please change to "(no destructors can be run)" >>>> >>>> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >>>> line 229: // (no destructors run) >>>> Please change to "(no destructors can be run)" >>>> >>>> src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp >>>> line 319: // (no destructors run) >>>> Please change to "(no destructors can be run)" >>>> >>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >>>> line 378: // (no destructors run) >>>> Please change to "(no destructors can be run)" >>>> >>>> src/share/vm/runtime/mutex.cpp >>>> No comments. >>>> >>>> Dan >>>> >>> Thanks for the review! >>> >>> /R >>> > From daniel.daugherty at oracle.com Thu Jul 18 07:01:48 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 18 Jul 2013 08:01:48 -0600 Subject: RFR(S): 8020701: Avoid crashes in WatcherThread In-Reply-To: <98020C0F-9C51-4C0A-8273-F37FDA93628C@oracle.com> References: <39C8EBCA-7AFD-48AC-B8C2-F8C5E92DC1DD@oracle.com> <51E6CE46.3030302@oracle.com> <51400C27-933D-433D-BF86-4351213F2D5D@oracle.com> <51E7E914.1010807@oracle.com> <98020C0F-9C51-4C0A-8273-F37FDA93628C@oracle.com> Message-ID: <51E7F54C.8040900@oracle.com> On 7/18/13 7:58 AM, Rickard B?ckman wrote: > Fixed them all, will start jprt-jobs. Thanks! > Didn't know we were so strict on the 80 columns, considering all the other code in those files? :) Most folks aren't, but I prefer that we don't add to the problem when we add new code. I personally take the opportunity to fix such things if I'm modifying such a line in the course of a bug fix, but that is a matter of personal taste. Slowly, we'll reduce the "style violations" over a very long time... Dan > > Thanks > /R > > On Jul 18, 2013, at 3:09 PM, Daniel D. Daugherty wrote: > >>> http://cr.openjdk.java.net/~rbackman/8020701.1/ >> Thumbs up! >> >> src/os/posix/vm/os_posix.cpp >> Can you reformat the new lines that are over 80 cols? >> No need to re-review that change if you do it. >> >> src/os/posix/vm/os_posix.hpp >> No comments. >> >> src/os/windows/vm/os_windows.cpp >> The os_posix.cpp funcation has these: >> >> 274 assert(Thread::current()->is_Watcher_thread(), "Only for WatcherThread"); >> 275 assert(!WatcherThread::watcher_thread()->has_crash_protection(), "crash_protection already set?"); >> >> but the Windows version of WatcherThreadCrashProtection::call() >> does not. Any particular reason for the difference? >> >> Sorry I missed this in the first round. >> >> src/os/windows/vm/os_windows.hpp >> No comments. >> >> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >> src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp >> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >> src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp >> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >> No comments. >> >> src/share/vm/runtime/mutex.cpp >> The new assert line is well past 80 cols. >> Again, no need to re-review. >> >> src/share/vm/runtime/os.cpp >> line 600: // since os::malloc can be called when the libjvm.{dll.so} is >> typo: '{dll.so}' >> -> '{dll,so}' >> >> line 601: // loaded and we don't have a thread yet. >> Please change "loaded" -> "first loaded" >> >> src/share/vm/runtime/os.hpp >> No comments. >> >> src/share/vm/runtime/thread.cpp >> No comments. >> >> src/share/vm/runtime/thread.hpp >> No comments. >> >> Dan >> >> >> On 7/18/13 4:37 AM, Rickard B?ckman wrote: >>> Hi, >>> >>> here is the updated webrev containing Dans suggested changes. >>> I also had to change the assert check in os::malloc, we discovered it wasn't safe to check Thread::current() since os::malloc() can be called when the libjvm is loaded / initialized and we don't have a thread yet. >>> Changing to logic a bit to require that the WatcherThread exists before looking up the thread and doing it by ThreadLocalStorage::get_thread_slow() makes it safe. >>> >>> That is the only code change, other changes are comments or newlines in code (thread.hpp). >>> >>> See the updated webrev: >>> http://cr.openjdk.java.net/~rbackman/8020701.1/ >>> >>> Thanks >>> /R >>> >>> >>> On Jul 17, 2013, at 8:12 PM, Rickard B?ckman wrote: >>> >>>> On Jul 17, 2013, at 7:03 PM, Daniel D. Daugherty wrote: >>>> >>>>> On 7/17/13 5:58 AM, Rickard B?ckman wrote: >>>>>> Hi all, >>>>>> >>>>>> can I please have reviews for the following change? >>>>>> >>>>>> We are adding a mechanism for avoiding some crashes in the WatcherThread using different OS-specific methods. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8020701/webrev/ >>>>>> >>>>>> Thanks >>>>>> /R >>>>> Thumbs up! The bug mentions a few tests where you think this new >>>>> infrastructure will help diagnose the failures modes for those tests. >>>>> However, are there any new tests targeted to exercise this code? >>>> Not diagnose the failures, but avoid the crashes they are currently causing. >>>> Since at least one of them haven't been fixed yet (working on it) it will work as >>>> a good verifier at the moment. When the bug is gone, it is harder. It is a bit hard >>>> to write a test that causes the VM to crash at random but specific places. Eventually >>>> we could do something with the whitebox api, but the crashes would only happen at >>>> very specific places in that case making them a bit less interesting. >>>> >>>>> src/share/vm/runtime/os.hpp >>>>> No comments. >>>>> >>>>> src/share/vm/runtime/os.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/runtime/thread.hpp >>>>> line 756: void set_crash_protection(os::WatcherThreadCrashProtection* crash_protection) { assert(Thread::current()->is_Watcher_thread(), "Can only be set by WatcherThread"); _crash_protection = crash_protection; } >>>>> This line is ridiculously long. Please reformat it to fit in 80 cols. >>>> Ok >>>> >>>>> src/share/vm/runtime/thread.cpp >>>>> No comments. >>>>> >>>>> src/os/posix/vm/os_posix.hpp >>>>> Nice comment. Hopefully it will keep anyone from doing something >>>>> dangerous in the future. >>>> :) >>>> >>>>> src/os/posix/vm/os_posix.cpp' >>>>> Please add the following line above 268: >>>>> >>>>> * See the caveats for this class in os_posix.hpp. >>>> Ok >>>> >>>>> src/os/windows/vm/os_windows.hpp >>>>> No comments. >>>>> >>>>> src/os/windows/vm/os_windows.cpp >>>>> line 4692 * Protects the callback call so that S jumps back into this method >>>>> Stale comment? What is 'S'? >>>> typo. Should be something like raised EXCEPTIONS causes a jump back into this method. >>>> >>>>> Please add the following line above 4692: >>>>> >>>>> * See the caveats for this class in os_windows.hpp. >>>>> >>>>> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >>>>> line 405: // (no destructors run) >>>>> Please change to "(no destructors can be run)" >>>> Ok >>>> >>>>> src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp >>>>> line 557: // (no destructors run) >>>>> Please change to "(no destructors can be run)" >>>>> >>>>> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >>>>> line 229: // (no destructors run) >>>>> Please change to "(no destructors can be run)" >>>>> >>>>> src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp >>>>> line 319: // (no destructors run) >>>>> Please change to "(no destructors can be run)" >>>>> >>>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >>>>> line 378: // (no destructors run) >>>>> Please change to "(no destructors can be run)" >>>>> >>>>> src/share/vm/runtime/mutex.cpp >>>>> No comments. >>>>> >>>>> Dan >>>>> >>>> Thanks for the review! >>>> >>>> /R >>>> From jason.uh at oracle.com Thu Jul 18 10:50:03 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Thu, 18 Jul 2013 17:50:03 +0000 Subject: hg: jdk8/tl/jdk: 8020426: Fix doclint accessibility issues in java.io Message-ID: <20130718175031.52C09481C6@hg.openjdk.java.net> Changeset: 6e10d93273d0 Author: juh Date: 2013-07-18 10:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6e10d93273d0 8020426: Fix doclint accessibility issues in java.io Reviewed-by: mduigou, darcy, chegar ! src/share/classes/java/io/DataInput.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/ObjectStreamField.java ! src/share/classes/java/io/RandomAccessFile.java From xueming.shen at oracle.com Thu Jul 18 11:01:30 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 18 Jul 2013 18:01:30 +0000 Subject: hg: jdk8/tl/jdk: 8016025: JSR 310 DateTime API Updates IV; ... Message-ID: <20130718180152.D2595481CE@hg.openjdk.java.net> Changeset: b39797bb86c0 Author: sherman Date: 2013-07-18 11:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b39797bb86c0 8016025: JSR 310 DateTime API Updates IV 8020418: Cleanup of -Xlint warnings in java.time 8016623: test/java/time/format/TestDateTimeTextProvider.java failing Summary: Integration of JSR310 Date/Time API update IV Reviewed-by: sherman Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com, chand.basha at oracle.com ! 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/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.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/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/JapaneseEra.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/chrono/package-info.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimePrintContext.java ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/ChronoField.java ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/TemporalField.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/lib/hijrah-config-umalqura.properties ! test/java/time/tck/java/time/MockSimplePeriod.java ! test/java/time/tck/java/time/TCKClock_Fixed.java ! test/java/time/tck/java/time/TCKDayOfWeek.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/TCKMonthDay.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKPeriod.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronology.java ! test/java/time/tck/java/time/chrono/TCKHijrahChronology.java ! test/java/time/tck/java/time/chrono/TCKHijrahEra.java ! test/java/time/tck/java/time/chrono/TCKIsoChronology.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKJapaneseEra.java ! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java + test/java/time/tck/java/time/format/TCKFormatStyle.java + test/java/time/tck/java/time/format/TCKResolverStyle.java + test/java/time/tck/java/time/format/TCKSignStyle.java ! test/java/time/tck/java/time/format/TCKTextStyle.java ! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java + test/java/time/tck/java/time/temporal/TCKChronoField.java + test/java/time/tck/java/time/temporal/TCKChronoUnit.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java ! test/java/time/tck/java/time/zone/TCKZoneRules.java ! test/java/time/test/java/time/MockSimplePeriod.java ! test/java/time/test/java/time/chrono/TestChronoLocalDate.java ! test/java/time/test/java/time/chrono/TestExampleCode.java ! test/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java ! test/java/time/test/java/time/chrono/TestJapaneseChronology.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java ! test/java/time/test/java/time/format/TestDateTimeTextProvider.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/java/time/test/java/time/format/TestNumberPrinter.java ! test/java/time/test/java/time/format/TestReducedPrinter.java ! test/java/time/test/java/time/temporal/MockFieldNoValue.java ! test/java/time/test/java/time/temporal/MockFieldValue.java From john.coomes at oracle.com Thu Jul 18 11:11:35 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:11:35 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b99 for changeset 59dc9da81379 Message-ID: <20130718181135.A1603481D8@hg.openjdk.java.net> Changeset: d2dcb110e9db Author: cl Date: 2013-07-18 03:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/d2dcb110e9db Added tag jdk8-b99 for changeset 59dc9da81379 ! .hgtags From john.coomes at oracle.com Thu Jul 18 11:11:59 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:11:59 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b99 for changeset 8ef83d4b23c9 Message-ID: <20130718181208.3B81D481DB@hg.openjdk.java.net> Changeset: 4fd722afae5c Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/4fd722afae5c Added tag jdk8-b99 for changeset 8ef83d4b23c9 ! .hgtags From john.coomes at oracle.com Thu Jul 18 11:11:46 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:11:46 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b99 for changeset adf49c3ef83c Message-ID: <20130718181154.E12E6481DA@hg.openjdk.java.net> Changeset: 043da456d316 Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/043da456d316 Added tag jdk8-b99 for changeset adf49c3ef83c ! .hgtags From john.coomes at oracle.com Thu Jul 18 11:11:39 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:11:39 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b99 for changeset 3f67804ab613 Message-ID: <20130718181141.ED164481D9@hg.openjdk.java.net> Changeset: 8d492f1dfd1b Author: cl Date: 2013-07-18 03:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/8d492f1dfd1b Added tag jdk8-b99 for changeset 3f67804ab613 ! .hgtags From john.coomes at oracle.com Thu Jul 18 11:12:19 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:12:19 +0000 Subject: hg: hsx/hotspot-rt/jdk: 5 new changesets Message-ID: <20130718181412.7FC8C481DC@hg.openjdk.java.net> Changeset: f83794805201 Author: mcimadamore Date: 2013-07-11 14:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f83794805201 8016281: The SAM method should be passed to the metafactory as a MethodType not a MethodHandle 8020010: Move lambda bridge creation from metafactory and VM to compiler Summary: JDK/metafactory component of the bridge fix and and MethodType vs. MethodHandle changes. Reviewed-by: twisti, briangoetz, forax Contributed-by: robert.field at oracle.com ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/SerializedLambda.java Changeset: 56bc019a0525 Author: katleman Date: 2013-07-11 14:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/56bc019a0525 8020414: JDK8 b98 source with GPL header errors Reviewed-by: darcy, lancea, iris ! test/sun/security/krb5/auto/NoneReplayCacheTest.java Changeset: 030d1ca7432f Author: katleman Date: 2013-07-11 14:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/030d1ca7432f Merge Changeset: 6a099a36589b Author: katleman Date: 2013-07-16 15:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6a099a36589b Merge Changeset: 9b6070690e50 Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9b6070690e50 Added tag jdk8-b99 for changeset 6a099a36589b ! .hgtags From john.coomes at oracle.com Thu Jul 18 11:15:39 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:15:39 +0000 Subject: hg: hsx/hotspot-rt/langtools: 3 new changesets Message-ID: <20130718181559.7A3B5481DD@hg.openjdk.java.net> Changeset: 39ec5d8a691b Author: mcimadamore Date: 2013-07-11 14:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/39ec5d8a691b 8016281: The SAM method should be passed to the metafactory as a MethodType not a MethodHandle 8020010: Move lambda bridge creation from metafactory and VM to compiler Summary: langtools/javac component of the bridge support and MethodType vs. MethodHandle changes. Reviewed-by: jjg, vromero, briangoetz, forax Contributed-by: robert.field at oracle.com ! 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/LambdaToMethod.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/util/Names.java + test/tools/javac/generics/bridges/Bridge.java + test/tools/javac/generics/bridges/BridgeHarness.java + test/tools/javac/generics/bridges/Bridges.java + test/tools/javac/generics/bridges/tests/TestBridgeWithDefault.java + test/tools/javac/generics/bridges/tests/TestClassAndInterfaceBridgeIdentical01.java + test/tools/javac/generics/bridges/tests/TestClassAndInterfaceBridgeIdentical02.java + test/tools/javac/generics/bridges/tests/TestNoBridgeInSiblingsSuper.java + test/tools/javac/generics/bridges/tests/TestNoDuplicateBridges01.java + test/tools/javac/generics/bridges/tests/TestNoDuplicateBridges02.java + test/tools/javac/lambda/bridge/TestMetafactoryBridges.java ! test/tools/javac/lambda/lambdaExpression/LambdaTest6.java ! test/tools/javac/lambda/methodReference/BridgeMethod.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java Changeset: 6d85acab769e Author: mcimadamore Date: 2013-07-17 19:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6d85acab769e 8013638: Few policy tests are failing in Lambda nightly Summary: BridgeHarness test is leaving files open Reviewed-by: ksrini ! test/tools/javac/generics/bridges/BridgeHarness.java Changeset: e73f00139fb5 Author: cl Date: 2013-07-18 03:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/e73f00139fb5 Added tag jdk8-b99 for changeset 6d85acab769e ! .hgtags From john.coomes at oracle.com Thu Jul 18 11:16:06 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:16:06 +0000 Subject: hg: hsx/hotspot-rt/nashorn: Added tag jdk8-b99 for changeset 10a1ab9e20a4 Message-ID: <20130718181611.2324E481DE@hg.openjdk.java.net> Changeset: 10503ced6cc2 Author: cl Date: 2013-07-18 03:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/10503ced6cc2 Added tag jdk8-b99 for changeset 10a1ab9e20a4 ! .hgtags From rickard.backman at oracle.com Thu Jul 18 12:23:41 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Thu, 18 Jul 2013 19:23:41 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8020701: Avoid crashes in WatcherThread Message-ID: <20130718192350.62499481E1@hg.openjdk.java.net> Changeset: 5e3b6f79d280 Author: rbackman Date: 2013-07-17 13:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5e3b6f79d280 8020701: Avoid crashes in WatcherThread Reviewed-by: acorn, dcubed, dsimms ! src/os/posix/vm/os_posix.cpp ! src/os/posix/vm/os_posix.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp From daniel.daugherty at oracle.com Thu Jul 18 17:54:51 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 19 Jul 2013 00:54:51 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 16 new changesets Message-ID: <20130719005522.DEC97481FB@hg.openjdk.java.net> Changeset: f4311079200c Author: brutisso Date: 2013-07-11 11:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f4311079200c 8020155: PSR:PERF G1 not collecting old regions when humongous allocations interfer Summary: Take _last_young_gc into account when deciding on starting a concurrent mark. Also reviewed-by: per.liden at oracle.com. Reviewed-by: tschatzl, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: e7a47f226600 Author: tamao Date: 2013-07-15 15:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e7a47f226600 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: 980532a806a5 Author: goetz Date: 2013-06-20 15:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/980532a806a5 8016697: Use stubs to implement safefetch Summary: Implement Safefetch as stub routines. This reduces compiler and os dependencies. Reviewed-by: twisti, kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/bsd_x86_64.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/linux_sparc.s ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/linux_x86_64.s ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_64.s ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: a74ec8831c7b Author: clucasius Date: 2013-07-15 12:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a74ec8831c7b Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 16b10327b00d Author: jprovino Date: 2013-07-16 10:55 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16b10327b00d 8011569: ARM -- avoid native stack walking Summary: ARM compilers do not emit FramePointer on each native frame by default Reviewed-by: dholmes, zgu ! make/linux/makefiles/vm.make ! src/share/vm/services/memTracker.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 90d6c221d4e5 Author: jprovino Date: 2013-07-16 12:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/90d6c221d4e5 Merge ! make/linux/makefiles/vm.make - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp ! src/share/vm/services/memTracker.cpp - src/share/vm/trace/traceEventTypes.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 9d18d92e54b5 Author: clucasius Date: 2013-07-18 00:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9d18d92e54b5 Merge Changeset: dc8afa03e5c9 Author: katleman Date: 2013-07-11 14:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dc8afa03e5c9 8020414: JDK8 b98 source with GPL header errors Reviewed-by: darcy, lancea, iris ! test/runtime/8001071/Test8001071.sh Changeset: 1c474723a324 Author: katleman Date: 2013-07-11 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1c474723a324 Merge Changeset: 81b6cb70717c Author: katleman Date: 2013-07-16 15:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/81b6cb70717c Merge Changeset: bb416ee2a79b Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bb416ee2a79b Added tag jdk8-b99 for changeset 81b6cb70717c ! .hgtags Changeset: 9f71e36a471a Author: amurillo Date: 2013-07-18 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9f71e36a471a Merge Changeset: 5787fac72e76 Author: amurillo Date: 2013-07-18 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5787fac72e76 Added tag hs25-b42 for changeset 9f71e36a471a ! .hgtags Changeset: 2285b4a0a4e6 Author: amurillo Date: 2013-07-18 09:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2285b4a0a4e6 8020797: new hotspot build - hs25-b43 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 248c459b2b75 Author: dcubed Date: 2013-07-18 12:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/248c459b2b75 Merge ! src/share/vm/services/memTracker.cpp Changeset: af21010d1062 Author: dcubed Date: 2013-07-18 12:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/af21010d1062 Merge ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/os.hpp From yumin.qi at oracle.com Thu Jul 18 20:11:39 2013 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Fri, 19 Jul 2013 03:11:39 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130719031146.9DF96481FF@hg.openjdk.java.net> Changeset: 02d7aa1456c9 Author: ccheung Date: 2013-07-18 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/02d7aa1456c9 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed Summary: this fix also removes the -XX:+UseStringCache option Reviewed-by: dholmes, acorn, iklam ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: 383a5e21cc2d Author: minqi Date: 2013-07-18 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/383a5e21cc2d Merge From joe.darcy at oracle.com Thu Jul 18 23:17:08 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 19 Jul 2013 06:17:08 +0000 Subject: hg: jdk8/tl/jdk: 8020810: Typo in javadoc for Class.toGenericString() Message-ID: <20130719061730.5701448202@hg.openjdk.java.net> Changeset: 2323b973adaa Author: darcy Date: 2013-07-18 23:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2323b973adaa 8020810: Typo in javadoc for Class.toGenericString() Reviewed-by: dholmes ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Parameter.java From alexey.utkin at oracle.com Fri Jul 19 01:55:44 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Fri, 19 Jul 2013 08:55:44 +0000 Subject: hg: jdk8/tl/jdk: 8016579: (process) IOException thrown by ProcessBuilder.start() method is incorrectly encoded Message-ID: <20130719085621.7F4FA48207@hg.openjdk.java.net> Changeset: e6aeeec33e53 Author: uta Date: 2013-07-19 12:53 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6aeeec33e53 8016579: (process) IOException thrown by ProcessBuilder.start() method is incorrectly encoded Reviewed-by: martin, dxu ! src/share/native/java/io/io_util.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/lang/ProcessImpl_md.c From joe.darcy at oracle.com Fri Jul 19 09:46:25 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 19 Jul 2013 16:46:25 +0000 Subject: hg: jdk8/tl/jdk: 8020948: Fix doclint issues in misc package-info.java files Message-ID: <20130719164653.CD04D4821F@hg.openjdk.java.net> Changeset: e013b32118af Author: darcy Date: 2013-07-19 09:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e013b32118af 8020948: Fix doclint issues in misc package-info.java files Reviewed-by: dholmes, chegar ! src/share/classes/java/nio/file/attribute/package-info.java ! src/share/classes/java/util/function/package-info.java From kumar.x.srinivasan at oracle.com Fri Jul 19 10:00:46 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 19 Jul 2013 17:00:46 +0000 Subject: hg: jdk8/tl/langtools: 8017216: javac doesn't fill in end position for some errors of type not found; ... Message-ID: <20130719170052.0282148220@hg.openjdk.java.net> Changeset: 0a9f5cbe37d9 Author: ksrini Date: 2013-07-19 07:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0a9f5cbe37d9 8017216: javac doesn't fill in end position for some errors of type not found 8019421: Javac doesn't fill in end position for some annotation related errors 8019422: Javac doesn't fill in end position for uninitialized variable errors Reviewed-by: jjg, mcimadamore ! 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/Flow.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/EndPosTable.java + test/tools/javac/diags/examples/VarNotIntializedInDefaultConstructor.java + test/tools/javac/positions/TreeEndPosTest.java From markus.gronlund at oracle.com Fri Jul 19 11:11:08 2013 From: markus.gronlund at oracle.com (markus.gronlund at oracle.com) Date: Fri, 19 Jul 2013 18:11:08 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8020547: Event based tracing needs a UNICODE string type Message-ID: <20130719181113.EE86048226@hg.openjdk.java.net> Changeset: 060ae9b7ffea Author: mgronlun Date: 2013-07-19 17:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/060ae9b7ffea 8020547: Event based tracing needs a UNICODE string type Reviewed-by: egahlin, rbackman, dcubed, brutisso, acorn ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/tracetypes.xml ! src/share/vm/trace/xinclude.mod From yumin.qi at oracle.com Fri Jul 19 15:29:21 2013 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Fri, 19 Jul 2013 22:29:21 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130719222926.18C3A4822B@hg.openjdk.java.net> Changeset: 4614a598dae1 Author: minqi Date: 2013-07-19 08:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4614a598dae1 8016538: volatile double access via Unsafe.cpp is not atomic Summary: volatile jdouble load/store is not atomic, fix by using of existing volatile jlong operations which are atomic for jdouble. Reviewed-by: kvn, vladidan, jrose Contributed-by: david.holmes at oracle.com ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp Changeset: 55a61ceb2fe7 Author: minqi Date: 2013-07-19 11:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/55a61ceb2fe7 Merge From joe.darcy at oracle.com Sat Jul 20 11:40:28 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 20 Jul 2013 18:40:28 +0000 Subject: hg: jdk8/tl/jdk: 8020971: Fix doclint issues in java.nio.* Message-ID: <20130720184054.B221A48243@hg.openjdk.java.net> Changeset: 4bd04969a228 Author: darcy Date: 2013-07-20 11:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bd04969a228 8020971: Fix doclint issues in java.nio.* Reviewed-by: lancea ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/charset/MalformedInputException.java ! src/share/classes/java/nio/charset/UnmappableCharacterException.java ! src/share/classes/java/nio/file/package-info.java From jaroslav.bachorik at oracle.com Mon Jul 22 04:55:42 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 22 Jul 2013 13:55:42 +0200 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently Message-ID: <51ED1DBE.3030304@oracle.com> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test seems to be failing intermittently. The test checks the functionality of the j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by capturing the current value of "getPeakThreadCount()", starting a predefined number of the user threads, stopping them and resetting the stored peak value and making sure the new peak equals to the number of the actually running threads. The main problem is that it is not possible to prevent JVM to start/stop arbitrary system threads while executing the test. This might lead to small variations of the reported peak (a short-lived system thread is started while the batch of the user threads is running) or the expected number of running threads (again, a short-lived system thread is started at the moment the test asks for the number of running threads). The patch does not fix those shortcomings as it is not really possible to do given the nature of the JVM threading system. It rather tries to relax the conditions while still maintaining the ability to detect functional problems - eg. decreasing peak without explicitly resetting it and reporting false number of threads. The webrev is at: http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 Thanks, -JB- From chris.hegarty at oracle.com Mon Jul 22 07:27:04 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 22 Jul 2013 14:27:04 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130722142742.13EDF48264@hg.openjdk.java.net> Changeset: dcd89e60051a Author: khazra Date: 2013-07-22 15:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dcd89e60051a 8020498: Crash when both libnet.so and libmawt.so are loaded Reviewed-by: chegar, dsamersoff ! src/share/native/java/net/net_util.c Changeset: a3a2889b1049 Author: dl Date: 2013-07-22 15:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a3a2889b1049 8020976: Ensure consistent insertion for ConcurrentHashMap Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java From mike.duigou at oracle.com Mon Jul 22 14:04:03 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 22 Jul 2013 21:04:03 +0000 Subject: hg: jdk8/tl/jdk: 6799426: Adds constructor PriorityQueue(Comparator) Message-ID: <20130722210415.583074827A@hg.openjdk.java.net> Changeset: a6cbb9808e4b Author: mduigou Date: 2013-07-22 12:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6cbb9808e4b 6799426: Adds constructor PriorityQueue(Comparator) Reviewed-by: lancea ! src/share/classes/java/util/PriorityQueue.java From joe.darcy at oracle.com Mon Jul 22 22:12:03 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 23 Jul 2013 05:12:03 +0000 Subject: hg: jdk8/tl/jdk: 8021109: Add serialVersionUID to LambdaConversionException.java Message-ID: <20130723051217.A34E548288@hg.openjdk.java.net> Changeset: 7716beb127d4 Author: darcy Date: 2013-07-22 22:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7716beb127d4 8021109: Add serialVersionUID to LambdaConversionException.java Reviewed-by: jrose ! src/share/classes/java/lang/invoke/LambdaConversionException.java From david.holmes at oracle.com Tue Jul 23 01:19:39 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jul 2013 18:19:39 +1000 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51ED1DBE.3030304@oracle.com> References: <51ED1DBE.3030304@oracle.com> Message-ID: <51EE3C9B.3050604@oracle.com> Hi Jaroslav, On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote: > The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test > seems to be failing intermittently. > > The test checks the functionality of the > j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by > capturing the current value of "getPeakThreadCount()", starting a > predefined number of the user threads, stopping them and resetting the > stored peak value and making sure the new peak equals to the number of > the actually running threads. > > The main problem is that it is not possible to prevent JVM to start/stop > arbitrary system threads while executing the test. This might lead to > small variations of the reported peak (a short-lived system thread is > started while the batch of the user threads is running) or the expected > number of running threads (again, a short-lived system thread is started > at the moment the test asks for the number of running threads). Do you know what "system threads" these are? I would not expect VM internal threads to be counted in getPeakThreadCount(), but even if they are I can't think of any short-lived threads that get created other than the Signal handling thread. > The patch does not fix those shortcomings as it is not really possible > to do given the nature of the JVM threading system. It rather tries to > relax the conditions while still maintaining the ability to detect > functional problems - eg. decreasing peak without explicitly resetting > it and reporting false number of threads. > > The webrev is at: > http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 Seems reasonable. David ----- > Thanks, > > -JB- > From daniel.fuchs at oracle.com Tue Jul 23 01:25:28 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 23 Jul 2013 10:25:28 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51ED1DBE.3030304@oracle.com> References: <51ED1DBE.3030304@oracle.com> Message-ID: <51EE3DF8.8060903@oracle.com> Hi Jaroslav, This looks like a tough problem as it is altogether possible that some of the VM daemon threads will terminate during the duration of the call - and if that's the case, the condition: new peak >= old peak + delta might not even be true. I am not a VM specialist so I don't know whether there can be such daemon threads that will be arbitrarily started and stopped by the VM - but if that happens I don't see how you could work around it. There seems to be something strange in the test though: line 209, you catch InterruptedException just to call Thread.currentThread().interrupt() and interrupt the thread again?? Did you mean maybe to call Thread.currentThread().interrupted() instead? There are other places that seems to be prone to failures in this test too for instance: startThreads(...) { while(mbean.getThreadCount() < (current + count)) { ... } } If the VM can start and stop arbitrary threads then this condition seems dubious. There's the same kind of logic in terminateThreads. Not sure you can/should do anything about it though - it's just to point out that these steps might need to be revisited if the test still fails sporadically... Also I'm not sure that using volatile for the 'live' array will work - the array itself is volatile - but does it extends to its elements? It might be better to declare the live array as static final and use a synchronization block on the array itself when accessing it: private static final boolean live[] = new boolean[ALL_THREADS]; private static boolean isAlive(int i) { synchronized(live) { return live[i] }; } ... synchronized(live) { live[i] == false; } ... while (isAlive[id]) { ... } ... best regards, -- daniel On 7/22/13 1:55 PM, Jaroslav Bachorik wrote: > The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test > seems to be failing intermittently. > > The test checks the functionality of the > j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by > capturing the current value of "getPeakThreadCount()", starting a > predefined number of the user threads, stopping them and resetting the > stored peak value and making sure the new peak equals to the number of > the actually running threads. > > The main problem is that it is not possible to prevent JVM to start/stop > arbitrary system threads while executing the test. This might lead to > small variations of the reported peak (a short-lived system thread is > started while the batch of the user threads is running) or the expected > number of running threads (again, a short-lived system thread is started > at the moment the test asks for the number of running threads). > > The patch does not fix those shortcomings as it is not really possible > to do given the nature of the JVM threading system. It rather tries to > relax the conditions while still maintaining the ability to detect > functional problems - eg. decreasing peak without explicitly resetting > it and reporting false number of threads. > > The webrev is at: > http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 > > Thanks, > > -JB- > From jaroslav.bachorik at oracle.com Tue Jul 23 01:29:22 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 23 Jul 2013 10:29:22 +0200 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EE3C9B.3050604@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> Message-ID: <51EE3EE2.1000202@oracle.com> On 07/23/2013 10:19 AM, David Holmes wrote: > Hi Jaroslav, > > On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote: >> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test >> seems to be failing intermittently. >> >> The test checks the functionality of the >> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by >> capturing the current value of "getPeakThreadCount()", starting a >> predefined number of the user threads, stopping them and resetting the >> stored peak value and making sure the new peak equals to the number of >> the actually running threads. >> >> The main problem is that it is not possible to prevent JVM to start/stop >> arbitrary system threads while executing the test. This might lead to >> small variations of the reported peak (a short-lived system thread is >> started while the batch of the user threads is running) or the expected >> number of running threads (again, a short-lived system thread is started >> at the moment the test asks for the number of running threads). > > Do you know what "system threads" these are? I would not expect VM > internal threads to be counted in getPeakThreadCount(), but even if they > are I can't think of any short-lived threads that get created other than > the Signal handling thread. Unfortunatelly I don't. Capturing the thread dump at the moment of discovering the discrepancy seems to to be too late. I tried monitoring the JVM under the test from external tools but it just brings more entropy to the result. I am completely relying on the JVM native thread accounting to be correct and accurate - that it reports the thread count peak based on the real data. -JB- > >> The patch does not fix those shortcomings as it is not really possible >> to do given the nature of the JVM threading system. It rather tries to >> relax the conditions while still maintaining the ability to detect >> functional problems - eg. decreasing peak without explicitly resetting >> it and reporting false number of threads. >> >> The webrev is at: >> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 > > Seems reasonable. > > David > ----- > >> Thanks, >> >> -JB- >> From david.holmes at oracle.com Tue Jul 23 02:15:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jul 2013 19:15:07 +1000 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EE3DF8.8060903@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3DF8.8060903@oracle.com> Message-ID: <51EE499B.9060600@oracle.com> On 23/07/2013 6:25 PM, Daniel Fuchs wrote: > Hi Jaroslav, > > This looks like a tough problem as it is altogether possible that > some of the VM daemon threads will terminate during the duration > of the call - and if that's the case, the condition: > new peak >= old peak + delta > might not even be true. > I am not a VM specialist so I don't know whether there can be > such daemon threads that will be arbitrarily started and stopped > by the VM - but if that happens I don't see how you could work around > it. > > There seems to be something strange in the test though: line 209, > you catch InterruptedException just to call > Thread.currentThread().interrupt() and interrupt the thread again?? > Did you mean maybe to call Thread.currentThread().interrupted() instead? No but good catch as the way this is done is not quite right. The re-posting of the interrupt() needs to happen outside the loop otherwise the sleep() will simply rethrow the InterruptedException. The normal pattern is: boolean interrupted = false; while (...) { try { Thread.sleep(5); ... } catch (InterruptedException ie) { interrupted = true; } } if (interrupted) Thread.currentThread().interrupt(); // re-assert interrupt state Of course it is debatable whether there is any point continuing the loop if you do get interrupted (which should never happen anyway). > There are other places that seems to be prone to failures in this test > too for instance: > > startThreads(...) { > > while(mbean.getThreadCount() < (current + count)) { > ... > } > > } > > If the VM can start and stop arbitrary threads then this condition > seems dubious. There's the same kind of logic in terminateThreads. > Not sure you can/should do anything about it though - it's > just to point out that these steps might need to be revisited > if the test still fails sporadically... > > Also I'm not sure that using volatile for the 'live' array will > work - the array itself is volatile - but does it extends to its > elements? No it doesn't. David ----- > It might be better to declare the live array as static final and > use a synchronization block on the array itself when accessing it: > > private static final boolean live[] = new boolean[ALL_THREADS]; > private static boolean isAlive(int i) { > synchronized(live) { return live[i] }; > } > > ... > > synchronized(live) { > live[i] == false; > } > > ... > > while (isAlive[id]) { > ... > } > > ... > > best regards, > > -- daniel > > On 7/22/13 1:55 PM, Jaroslav Bachorik wrote: >> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test >> seems to be failing intermittently. >> >> The test checks the functionality of the >> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by >> capturing the current value of "getPeakThreadCount()", starting a >> predefined number of the user threads, stopping them and resetting the >> stored peak value and making sure the new peak equals to the number of >> the actually running threads. >> >> The main problem is that it is not possible to prevent JVM to start/stop >> arbitrary system threads while executing the test. This might lead to >> small variations of the reported peak (a short-lived system thread is >> started while the batch of the user threads is running) or the expected >> number of running threads (again, a short-lived system thread is started >> at the moment the test asks for the number of running threads). >> >> The patch does not fix those shortcomings as it is not really possible >> to do given the nature of the JVM threading system. It rather tries to >> relax the conditions while still maintaining the ability to detect >> functional problems - eg. decreasing peak without explicitly resetting >> it and reporting false number of threads. >> >> The webrev is at: >> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 >> >> Thanks, >> >> -JB- >> > From david.holmes at oracle.com Tue Jul 23 02:19:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jul 2013 19:19:13 +1000 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EE3EE2.1000202@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> Message-ID: <51EE4A91.3000305@oracle.com> On 23/07/2013 6:29 PM, Jaroslav Bachorik wrote: > On 07/23/2013 10:19 AM, David Holmes wrote: >> Hi Jaroslav, >> >> On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote: >>> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test >>> seems to be failing intermittently. >>> >>> The test checks the functionality of the >>> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by >>> capturing the current value of "getPeakThreadCount()", starting a >>> predefined number of the user threads, stopping them and resetting the >>> stored peak value and making sure the new peak equals to the number of >>> the actually running threads. >>> >>> The main problem is that it is not possible to prevent JVM to start/stop >>> arbitrary system threads while executing the test. This might lead to >>> small variations of the reported peak (a short-lived system thread is >>> started while the batch of the user threads is running) or the expected >>> number of running threads (again, a short-lived system thread is started >>> at the moment the test asks for the number of running threads). >> >> Do you know what "system threads" these are? I would not expect VM >> internal threads to be counted in getPeakThreadCount(), but even if they >> are I can't think of any short-lived threads that get created other than >> the Signal handling thread. > > Unfortunatelly I don't. Capturing the thread dump at the moment of > discovering the discrepancy seems to to be too late. I tried monitoring > the JVM under the test from external tools but it just brings more > entropy to the result. We'd need to instrument the thread creation logic to keep a separate record. Dtrace probes could probably do it - but the problem is getting the test to fail. > I am completely relying on the JVM native thread accounting to be > correct and accurate - that it reports the thread count peak based on > the real data. The spec isn't clear but I would only expect these counters to apply to Java threads not VM internal threads (compiler, gc etc). So I'd really like to know what thread is messing up this count. David > -JB- > >> >>> The patch does not fix those shortcomings as it is not really possible >>> to do given the nature of the JVM threading system. It rather tries to >>> relax the conditions while still maintaining the ability to detect >>> functional problems - eg. decreasing peak without explicitly resetting >>> it and reporting false number of threads. >>> >>> The webrev is at: >>> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 >> >> Seems reasonable. >> >> David >> ----- >> >>> Thanks, >>> >>> -JB- >>> > From jaroslav.bachorik at oracle.com Tue Jul 23 02:24:38 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 23 Jul 2013 11:24:38 +0200 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EE4A91.3000305@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> Message-ID: <51EE4BD6.7040707@oracle.com> On Tue 23 Jul 2013 11:19:13 AM CEST, David Holmes wrote: > On 23/07/2013 6:29 PM, Jaroslav Bachorik wrote: >> On 07/23/2013 10:19 AM, David Holmes wrote: >>> Hi Jaroslav, >>> >>> On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote: >>>> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test >>>> seems to be failing intermittently. >>>> >>>> The test checks the functionality of the >>>> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by >>>> capturing the current value of "getPeakThreadCount()", starting a >>>> predefined number of the user threads, stopping them and resetting the >>>> stored peak value and making sure the new peak equals to the number of >>>> the actually running threads. >>>> >>>> The main problem is that it is not possible to prevent JVM to >>>> start/stop >>>> arbitrary system threads while executing the test. This might lead to >>>> small variations of the reported peak (a short-lived system thread is >>>> started while the batch of the user threads is running) or the >>>> expected >>>> number of running threads (again, a short-lived system thread is >>>> started >>>> at the moment the test asks for the number of running threads). >>> >>> Do you know what "system threads" these are? I would not expect VM >>> internal threads to be counted in getPeakThreadCount(), but even if >>> they >>> are I can't think of any short-lived threads that get created other >>> than >>> the Signal handling thread. >> >> Unfortunatelly I don't. Capturing the thread dump at the moment of >> discovering the discrepancy seems to to be too late. I tried monitoring >> the JVM under the test from external tools but it just brings more >> entropy to the result. > > We'd need to instrument the thread creation logic to keep a separate > record. Dtrace probes could probably do it - but the problem is > getting the test to fail. Well, while responding to the previous email I thought about yet another way to try to pinpoint the mysterious thread - I've tried NB profiler. It filters out it's own threads and can do thread monitoring at the same time as tracking the call tree. The result is that the offender is j.u.l.LogManager$Cleaner thread. I am attaching the profiler snapshot (can be opened in eg. jvisualvm) > >> I am completely relying on the JVM native thread accounting to be >> correct and accurate - that it reports the thread count peak based on >> the real data. > > The spec isn't clear but I would only expect these counters to apply > to Java threads not VM internal threads (compiler, gc etc). So I'd > really like to know what thread is messing up this count. I hope my previous finding makes this clearer. -JB- > > David > >> -JB- >> >>> >>>> The patch does not fix those shortcomings as it is not really possible >>>> to do given the nature of the JVM threading system. It rather tries to >>>> relax the conditions while still maintaining the ability to detect >>>> functional problems - eg. decreasing peak without explicitly resetting >>>> it and reporting false number of threads. >>>> >>>> The webrev is at: >>>> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 >>> >>> Seems reasonable. >>> >>> David >>> ----- >>> >>>> Thanks, >>>> >>>> -JB- >>>> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: mystic_thread.nps Type: application/octet-stream Size: 121157 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130723/efdb86ab/mystic_thread-0001.nps From jaroslav.bachorik at oracle.com Tue Jul 23 02:25:59 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 23 Jul 2013 11:25:59 +0200 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EE4A91.3000305@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> Message-ID: <51EE4C27.206@oracle.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue 23 Jul 2013 11:19:13 AM CEST, David Holmes wrote: > On 23/07/2013 6:29 PM, Jaroslav Bachorik wrote: >> On 07/23/2013 10:19 AM, David Holmes wrote: >>> Hi Jaroslav, >>> >>> On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote: >>>> The >>>> java/lang/management/ThreadMXBean/ResetPeakThreadCount.java >>>> test seems to be failing intermittently. >>>> >>>> The test checks the functionality of the >>>> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so >>>> by capturing the current value of "getPeakThreadCount()", >>>> starting a predefined number of the user threads, stopping >>>> them and resetting the stored peak value and making sure the >>>> new peak equals to the number of the actually running >>>> threads. >>>> >>>> The main problem is that it is not possible to prevent JVM >>>> to start/stop arbitrary system threads while executing the >>>> test. This might lead to small variations of the reported >>>> peak (a short-lived system thread is started while the batch >>>> of the user threads is running) or the expected number of >>>> running threads (again, a short-lived system thread is >>>> started at the moment the test asks for the number of running >>>> threads). >>> >>> Do you know what "system threads" these are? I would not expect >>> VM internal threads to be counted in getPeakThreadCount(), but >>> even if they are I can't think of any short-lived threads that >>> get created other than the Signal handling thread. >> >> Unfortunatelly I don't. Capturing the thread dump at the moment >> of discovering the discrepancy seems to to be too late. I tried >> monitoring the JVM under the test from external tools but it just >> brings more entropy to the result. > > We'd need to instrument the thread creation logic to keep a > separate record. Dtrace probes could probably do it - but the > problem is getting the test to fail. Well, while responding to the previous email I thought about yet another way to try to pinpoint the mysterious thread - I've tried NB profiler. It filters out it's own threads and can do thread monitoring at the same time as tracking the call tree. The result is that the offender is j.u.l.LogManager$Cleaner thread. > >> I am completely relying on the JVM native thread accounting to >> be correct and accurate - that it reports the thread count peak >> based on the real data. > > The spec isn't clear but I would only expect these counters to > apply to Java threads not VM internal threads (compiler, gc etc). > So I'd really like to know what thread is messing up this count. I hope my previous finding makes this clearer. - -JB- > > David > >> -JB- >> >>> >>>> The patch does not fix those shortcomings as it is not really >>>> possible to do given the nature of the JVM threading system. >>>> It rather tries to relax the conditions while still >>>> maintaining the ability to detect functional problems - eg. >>>> decreasing peak without explicitly resetting it and reporting >>>> false number of threads. >>>> >>>> The webrev is at: >>>> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 >>> >>> Seems reasonable. >>> >>> David ----- >>> >>>> Thanks, >>>> >>>> -JB- >>>> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR7kwnAAoJELSZyqhGiB1MT1EH+wVuy+XhmDWRygxGnJCaSGwb B0RoeOovuhQa2y2AKKF8P1PRULNxxDQ5i+DG21Zd/xJA2WVBsm0h8Kkj0s3PJIOq 8EHZMY7Onw/kDrmoJMNlJrFf/wlSOXC6E/4lZeiSCqyzobZQRBzfLUOMPDXjYTEt 76+RYUDw5DON05ph5BbknIAr/JBy0iUoT7K39q8/b5Z6ZId8Z2pIguLUhDs49YOD xZSwHgZkJsJCQCDW3Fnth8qGOkQC4StnwE0X5vTCLCIurjIrAYiIciVBJVpjTOEZ zqo8JL7m5dFVl2NfK1on1XCV71phybgxB2qCpWGh4Z9mv+o9XNe4kY3cC1waIVs= =mSja -----END PGP SIGNATURE----- From jaroslav.bachorik at oracle.com Tue Jul 23 02:35:16 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 23 Jul 2013 11:35:16 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EE3DF8.8060903@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3DF8.8060903@oracle.com> Message-ID: <51EE4E54.5040005@oracle.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/23/2013 10:25 AM, Daniel Fuchs wrote: > Hi Jaroslav, > > This looks like a tough problem as it is altogether possible that > some of the VM daemon threads will terminate during the duration of > the call - and if that's the case, the condition: new peak >= old > peak + delta might not even be true. I am not a VM specialist so I > don't know whether there can be such daemon threads that will be > arbitrarily started and stopped by the VM - but if that happens I > don't see how you could work around it. As I wrote in my reply to David the offending thread is j.u.l.LogManager$Cleaner which kicks in randomly. This would confirm my observations that the discrepancy is always at most one thread more than expected. > > There seems to be something strange in the test though: line 209, > you catch InterruptedException just to call > Thread.currentThread().interrupt() and interrupt the thread > again?? Did you mean maybe to call > Thread.currentThread().interrupted() instead? No, it checks whether the thread has been interrupted and cleans the interrupted flag. > > There are other places that seems to be prone to failures in this > test too for instance: > > startThreads(...) { > > while(mbean.getThreadCount() < (current + count)) { ... } > > } > > If the VM can start and stop arbitrary threads then this condition > seems dubious. There's the same kind of logic in terminateThreads. > Not sure you can/should do anything about it though - it's just to > point out that these steps might need to be revisited if the test > still fails sporadically... > > Also I'm not sure that using volatile for the 'live' array will > work - the array itself is volatile - but does it extends to its > elements? No, it does not. But this code has been sitting there for some time. - -JB- > > It might be better to declare the live array as static final and > use a synchronization block on the array itself when accessing it: > > private static final boolean live[] = new boolean[ALL_THREADS]; > private static boolean isAlive(int i) { synchronized(live) { return > live[i] }; } > > ... > > synchronized(live) { live[i] == false; } > > ... > > while (isAlive[id]) { ... } > > ... > > best regards, > > -- daniel > > On 7/22/13 1:55 PM, Jaroslav Bachorik wrote: >> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java >> test seems to be failing intermittently. >> >> The test checks the functionality of the >> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by >> capturing the current value of "getPeakThreadCount()", starting >> a predefined number of the user threads, stopping them and >> resetting the stored peak value and making sure the new peak >> equals to the number of the actually running threads. >> >> The main problem is that it is not possible to prevent JVM to >> start/stop arbitrary system threads while executing the test. >> This might lead to small variations of the reported peak (a >> short-lived system thread is started while the batch of the user >> threads is running) or the expected number of running threads >> (again, a short-lived system thread is started at the moment the >> test asks for the number of running threads). >> >> The patch does not fix those shortcomings as it is not really >> possible to do given the nature of the JVM threading system. It >> rather tries to relax the conditions while still maintaining the >> ability to detect functional problems - eg. decreasing peak >> without explicitly resetting it and reporting false number of >> threads. >> >> The webrev is at: >> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 >> >> Thanks, >> >> -JB- >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR7k5UAAoJELSZyqhGiB1MsFoH/Rm/Of3/3U0hxvnB/1/PixYJ z1fakf98Gepyp9eIyNKZ5sfNCu6Zy+A826Uqfp/Hve8nUA5D9pzEiTpNoB4Fzts1 CWwn+Gd8r4crXXTNKKEg1vTOUEMcmRkUujY356ndmrcdZElRMQJwdOvkwgg9Z+Tn l0ZJLPTDyaDUtuP5D32RZYSMxf1yXL6hXbXNiOEWm9VD4NgxPpl8b4vu0cMrRiHH A+anZ9nUiEhdBsTJIcqgU4bmHBM8eXEDDepBMpnK6LyM/2eDhPj3iTqQpav26Lsd cURgR1Tgqs36bdlUCU4Q3MqPtHfnBibTTPxphXbhzgfAGMUW5JFerYGJIvTvpAw= =d/Q+ -----END PGP SIGNATURE----- From david.holmes at oracle.com Tue Jul 23 02:39:44 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jul 2013 19:39:44 +1000 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EE4A91.3000305@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> Message-ID: <51EE4F60.4000506@oracle.com> Sorry - I took a closer look at the full test rather than just that patch. We already have this code to try and help expose these intermittent failures: 213 // Nightly testing showed some intermittent failure. 214 // Check here to get diagnostic information if some strange 215 // behavior occurs. 216 checkThreadCount(expectedCount, current, 0); but the sleep loop you added means this check will rarely fail so we won't get to see this unexpected behaviour happening. So this block of code could be deleted in my view. Though it is preferable to determine exactly why we fail! Also looking at the sleep() used elsewhere you may as well follow the same pattern and abort on interrupt as it isn't expected. Finally with regard to Daniel's comment about the live array he is right that the volatile on the array is not sufficient in theory - a thread need never see the value of live[i] become false. There are a number of reasons why we are unlikely to see that in practice on hotspot. Using synchronized will fix that; or an alternative cancellation mechanism could be used. Cheers, David On 23/07/2013 7:19 PM, David Holmes wrote: > On 23/07/2013 6:29 PM, Jaroslav Bachorik wrote: >> On 07/23/2013 10:19 AM, David Holmes wrote: >>> Hi Jaroslav, >>> >>> On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote: >>>> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test >>>> seems to be failing intermittently. >>>> >>>> The test checks the functionality of the >>>> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by >>>> capturing the current value of "getPeakThreadCount()", starting a >>>> predefined number of the user threads, stopping them and resetting the >>>> stored peak value and making sure the new peak equals to the number of >>>> the actually running threads. >>>> >>>> The main problem is that it is not possible to prevent JVM to >>>> start/stop >>>> arbitrary system threads while executing the test. This might lead to >>>> small variations of the reported peak (a short-lived system thread is >>>> started while the batch of the user threads is running) or the expected >>>> number of running threads (again, a short-lived system thread is >>>> started >>>> at the moment the test asks for the number of running threads). >>> >>> Do you know what "system threads" these are? I would not expect VM >>> internal threads to be counted in getPeakThreadCount(), but even if they >>> are I can't think of any short-lived threads that get created other than >>> the Signal handling thread. >> >> Unfortunatelly I don't. Capturing the thread dump at the moment of >> discovering the discrepancy seems to to be too late. I tried monitoring >> the JVM under the test from external tools but it just brings more >> entropy to the result. > > We'd need to instrument the thread creation logic to keep a separate > record. Dtrace probes could probably do it - but the problem is getting > the test to fail. > >> I am completely relying on the JVM native thread accounting to be >> correct and accurate - that it reports the thread count peak based on >> the real data. > > The spec isn't clear but I would only expect these counters to apply to > Java threads not VM internal threads (compiler, gc etc). So I'd really > like to know what thread is messing up this count. > > David > >> -JB- >> >>> >>>> The patch does not fix those shortcomings as it is not really possible >>>> to do given the nature of the JVM threading system. It rather tries to >>>> relax the conditions while still maintaining the ability to detect >>>> functional problems - eg. decreasing peak without explicitly resetting >>>> it and reporting false number of threads. >>>> >>>> The webrev is at: >>>> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 >>> >>> Seems reasonable. >>> >>> David >>> ----- >>> >>>> Thanks, >>>> >>>> -JB- >>>> >> From dmitry.samersoff at oracle.com Tue Jul 23 02:39:00 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 23 Jul 2013 13:39:00 +0400 Subject: RR(XS) 8019396: SA-JDI: OSThread class initialization throws an exception Message-ID: <51EE4F34.5030805@oracle.com> Hi Everybody, Please, review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8019396.SA-JDI/webrev.01/ Method sun.jvm.hotspot.runtime.OSThread.initialize throws a sun.jvm.hotspot.types.WrongTypeException with message: field "_thread_id" in type OSThread is not of type jint, but instead of type unsigned OSThread::thread_id_t. After fixing an exception test still fails, because of wrong value used for JVMTI_THREAD_STATE_WAITING, fixed it as well. Testing: nsk/sajdi/ThreadReference/status/status002 -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.fuchs at oracle.com Tue Jul 23 02:44:50 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 23 Jul 2013 11:44:50 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EE4E54.5040005@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3DF8.8060903@oracle.com> <51EE4E54.5040005@oracle.com> Message-ID: <51EE5092.4050100@oracle.com> On 7/23/13 11:35 AM, Jaroslav Bachorik wrote: > As I wrote in my reply to David the offending thread is > j.u.l.LogManager$Cleaner which kicks in randomly. Argh... Logging again :-) > This would confirm my observations that the discrepancy is always at > most one thread more than expected. What you could do then is call: Logger.getLogger("foo").info("Logging initialized"); first thing in the main(). This way the Cleaner thread will already be there and won't perturb the test. >> There seems to be something strange in the test though: line 209, >> you catch InterruptedException just to call >> Thread.currentThread().interrupt() and interrupt the thread >> again?? Did you mean maybe to call >> Thread.currentThread().interrupted() instead? > > No, it checks whether the thread has been interrupted and cleans the > interrupted flag. That's what interrupted() will do. But interrupt() will cause the next call to Thread.sleep() to throw InterruptedException - hence my question. >> Also I'm not sure that using volatile for the 'live' array will >> work - the array itself is volatile - but does it extends to its >> elements? > > No, it does not. But this code has been sitting there for some time. Well - I'll leave it to you - but personally I would fix it along, just to make sure the test doesn't fail because of it. cheers, -- daniel > > - -JB- > >> >> It might be better to declare the live array as static final and >> use a synchronization block on the array itself when accessing it: >> >> private static final boolean live[] = new boolean[ALL_THREADS]; >> private static boolean isAlive(int i) { synchronized(live) { return >> live[i] }; } >> >> ... >> >> synchronized(live) { live[i] == false; } >> >> ... >> >> while (isAlive[id]) { ... } >> >> ... >> >> best regards, >> >> -- daniel >> >> On 7/22/13 1:55 PM, Jaroslav Bachorik wrote: >>> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java >>> test seems to be failing intermittently. >>> >>> The test checks the functionality of the >>> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by >>> capturing the current value of "getPeakThreadCount()", starting >>> a predefined number of the user threads, stopping them and >>> resetting the stored peak value and making sure the new peak >>> equals to the number of the actually running threads. >>> >>> The main problem is that it is not possible to prevent JVM to >>> start/stop arbitrary system threads while executing the test. >>> This might lead to small variations of the reported peak (a >>> short-lived system thread is started while the batch of the user >>> threads is running) or the expected number of running threads >>> (again, a short-lived system thread is started at the moment the >>> test asks for the number of running threads). >>> >>> The patch does not fix those shortcomings as it is not really >>> possible to do given the nature of the JVM threading system. It >>> rather tries to relax the conditions while still maintaining the >>> ability to detect functional problems - eg. decreasing peak >>> without explicitly resetting it and reporting false number of >>> threads. >>> >>> The webrev is at: >>> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 >>> >>> Thanks, >>> >>> -JB- >>> >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJR7k5UAAoJELSZyqhGiB1MsFoH/Rm/Of3/3U0hxvnB/1/PixYJ > z1fakf98Gepyp9eIyNKZ5sfNCu6Zy+A826Uqfp/Hve8nUA5D9pzEiTpNoB4Fzts1 > CWwn+Gd8r4crXXTNKKEg1vTOUEMcmRkUujY356ndmrcdZElRMQJwdOvkwgg9Z+Tn > l0ZJLPTDyaDUtuP5D32RZYSMxf1yXL6hXbXNiOEWm9VD4NgxPpl8b4vu0cMrRiHH > A+anZ9nUiEhdBsTJIcqgU4bmHBM8eXEDDepBMpnK6LyM/2eDhPj3iTqQpav26Lsd > cURgR1Tgqs36bdlUCU4Q3MqPtHfnBibTTPxphXbhzgfAGMUW5JFerYGJIvTvpAw= > =d/Q+ > -----END PGP SIGNATURE----- > From david.holmes at oracle.com Tue Jul 23 02:45:24 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jul 2013 19:45:24 +1000 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EE4BD6.7040707@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> Message-ID: <51EE50B4.8040000@oracle.com> On 23/07/2013 7:24 PM, Jaroslav Bachorik wrote: > The result is that the offender is j.u.l.LogManager$Cleaner thread. I > am attaching the profiler snapshot (can be opened in eg. jvisualvm) That doesn't quite make sense. The Cleaner thread is a shutdownhook, it should not be starting unless the VM is shutting down! David ----- > On Tue 23 Jul 2013 11:19:13 AM CEST, David Holmes wrote: >> On 23/07/2013 6:29 PM, Jaroslav Bachorik wrote: >>> On 07/23/2013 10:19 AM, David Holmes wrote: >>>> Hi Jaroslav, >>>> >>>> On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote: >>>>> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test >>>>> seems to be failing intermittently. >>>>> >>>>> The test checks the functionality of the >>>>> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by >>>>> capturing the current value of "getPeakThreadCount()", starting a >>>>> predefined number of the user threads, stopping them and resetting the >>>>> stored peak value and making sure the new peak equals to the number of >>>>> the actually running threads. >>>>> >>>>> The main problem is that it is not possible to prevent JVM to >>>>> start/stop >>>>> arbitrary system threads while executing the test. This might lead to >>>>> small variations of the reported peak (a short-lived system thread is >>>>> started while the batch of the user threads is running) or the >>>>> expected >>>>> number of running threads (again, a short-lived system thread is >>>>> started >>>>> at the moment the test asks for the number of running threads). >>>> >>>> Do you know what "system threads" these are? I would not expect VM >>>> internal threads to be counted in getPeakThreadCount(), but even if >>>> they >>>> are I can't think of any short-lived threads that get created other >>>> than >>>> the Signal handling thread. >>> >>> Unfortunatelly I don't. Capturing the thread dump at the moment of >>> discovering the discrepancy seems to to be too late. I tried monitoring >>> the JVM under the test from external tools but it just brings more >>> entropy to the result. >> >> We'd need to instrument the thread creation logic to keep a separate >> record. Dtrace probes could probably do it - but the problem is >> getting the test to fail. > > Well, while responding to the previous email I thought about yet > another way to try to pinpoint the mysterious thread - I've tried NB > profiler. It filters out it's own threads and can do thread monitoring > at the same time as tracking the call tree. > > The result is that the offender is j.u.l.LogManager$Cleaner thread. I > am attaching the profiler snapshot (can be opened in eg. jvisualvm) > >> >>> I am completely relying on the JVM native thread accounting to be >>> correct and accurate - that it reports the thread count peak based on >>> the real data. >> >> The spec isn't clear but I would only expect these counters to apply >> to Java threads not VM internal threads (compiler, gc etc). So I'd >> really like to know what thread is messing up this count. > > I hope my previous finding makes this clearer. > > -JB- > >> >> David >> >>> -JB- >>> >>>> >>>>> The patch does not fix those shortcomings as it is not really possible >>>>> to do given the nature of the JVM threading system. It rather tries to >>>>> relax the conditions while still maintaining the ability to detect >>>>> functional problems - eg. decreasing peak without explicitly resetting >>>>> it and reporting false number of threads. >>>>> >>>>> The webrev is at: >>>>> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 >>>> >>>> Seems reasonable. >>>> >>>> David >>>> ----- >>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>>> >>> > From daniel.fuchs at oracle.com Tue Jul 23 02:53:19 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 23 Jul 2013 11:53:19 +0200 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EE50B4.8040000@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> Message-ID: <51EE528F.2050302@oracle.com> On 7/23/13 11:45 AM, David Holmes wrote: > On 23/07/2013 7:24 PM, Jaroslav Bachorik wrote: > > The result is that the offender is j.u.l.LogManager$Cleaner thread. I > > am attaching the profiler snapshot (can be opened in eg. jvisualvm) > > That doesn't quite make sense. The Cleaner thread is a shutdownhook, it > should not be starting unless the VM is shutting down! Hummm... Right: the javadoc says "Returns the peak live thread count since the Java virtual machine started or peak was reset." so the Cleaner thread should not be counted. If it is actually counted it might indicate a real problem in the implementation of the ThreadMXBean. -- daniel. > > David > ----- > >> On Tue 23 Jul 2013 11:19:13 AM CEST, David Holmes wrote: >>> On 23/07/2013 6:29 PM, Jaroslav Bachorik wrote: >>>> On 07/23/2013 10:19 AM, David Holmes wrote: >>>>> Hi Jaroslav, >>>>> >>>>> On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote: >>>>>> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test >>>>>> seems to be failing intermittently. >>>>>> >>>>>> The test checks the functionality of the >>>>>> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by >>>>>> capturing the current value of "getPeakThreadCount()", starting a >>>>>> predefined number of the user threads, stopping them and resetting >>>>>> the >>>>>> stored peak value and making sure the new peak equals to the >>>>>> number of >>>>>> the actually running threads. >>>>>> >>>>>> The main problem is that it is not possible to prevent JVM to >>>>>> start/stop >>>>>> arbitrary system threads while executing the test. This might lead to >>>>>> small variations of the reported peak (a short-lived system thread is >>>>>> started while the batch of the user threads is running) or the >>>>>> expected >>>>>> number of running threads (again, a short-lived system thread is >>>>>> started >>>>>> at the moment the test asks for the number of running threads). >>>>> >>>>> Do you know what "system threads" these are? I would not expect VM >>>>> internal threads to be counted in getPeakThreadCount(), but even if >>>>> they >>>>> are I can't think of any short-lived threads that get created other >>>>> than >>>>> the Signal handling thread. >>>> >>>> Unfortunatelly I don't. Capturing the thread dump at the moment of >>>> discovering the discrepancy seems to to be too late. I tried monitoring >>>> the JVM under the test from external tools but it just brings more >>>> entropy to the result. >>> >>> We'd need to instrument the thread creation logic to keep a separate >>> record. Dtrace probes could probably do it - but the problem is >>> getting the test to fail. >> >> Well, while responding to the previous email I thought about yet >> another way to try to pinpoint the mysterious thread - I've tried NB >> profiler. It filters out it's own threads and can do thread monitoring >> at the same time as tracking the call tree. >> >> The result is that the offender is j.u.l.LogManager$Cleaner thread. I >> am attaching the profiler snapshot (can be opened in eg. jvisualvm) >> >>> >>>> I am completely relying on the JVM native thread accounting to be >>>> correct and accurate - that it reports the thread count peak based on >>>> the real data. >>> >>> The spec isn't clear but I would only expect these counters to apply >>> to Java threads not VM internal threads (compiler, gc etc). So I'd >>> really like to know what thread is messing up this count. >> >> I hope my previous finding makes this clearer. >> >> -JB- >> >>> >>> David >>> >>>> -JB- >>>> >>>>> >>>>>> The patch does not fix those shortcomings as it is not really >>>>>> possible >>>>>> to do given the nature of the JVM threading system. It rather >>>>>> tries to >>>>>> relax the conditions while still maintaining the ability to detect >>>>>> functional problems - eg. decreasing peak without explicitly >>>>>> resetting >>>>>> it and reporting false number of threads. >>>>>> >>>>>> The webrev is at: >>>>>> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 >>>>> >>>>> Seems reasonable. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>>> >>>> >> From david.holmes at oracle.com Tue Jul 23 02:54:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jul 2013 19:54:01 +1000 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EE528F.2050302@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> Message-ID: <51EE52B9.6070506@oracle.com> On 23/07/2013 7:53 PM, Daniel Fuchs wrote: > On 7/23/13 11:45 AM, David Holmes wrote: >> On 23/07/2013 7:24 PM, Jaroslav Bachorik wrote: >> > The result is that the offender is j.u.l.LogManager$Cleaner thread. I >> > am attaching the profiler snapshot (can be opened in eg. jvisualvm) >> >> That doesn't quite make sense. The Cleaner thread is a shutdownhook, it >> should not be starting unless the VM is shutting down! > > Hummm... Right: the javadoc says "Returns the peak live thread count > since the Java virtual machine started or peak was reset." so the > Cleaner thread should not be counted. Not sure why you say that. It is a live Java thread - if you happen to query the MXBean during VM shutdown then it should be in the count. > If it is actually counted it might indicate a real problem in the > implementation of the ThreadMXBean. My point is: why is the VM apparently shutting down while this test is running??? David > -- daniel. > > >> >> David >> ----- >> >>> On Tue 23 Jul 2013 11:19:13 AM CEST, David Holmes wrote: >>>> On 23/07/2013 6:29 PM, Jaroslav Bachorik wrote: >>>>> On 07/23/2013 10:19 AM, David Holmes wrote: >>>>>> Hi Jaroslav, >>>>>> >>>>>> On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote: >>>>>>> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test >>>>>>> seems to be failing intermittently. >>>>>>> >>>>>>> The test checks the functionality of the >>>>>>> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by >>>>>>> capturing the current value of "getPeakThreadCount()", starting a >>>>>>> predefined number of the user threads, stopping them and resetting >>>>>>> the >>>>>>> stored peak value and making sure the new peak equals to the >>>>>>> number of >>>>>>> the actually running threads. >>>>>>> >>>>>>> The main problem is that it is not possible to prevent JVM to >>>>>>> start/stop >>>>>>> arbitrary system threads while executing the test. This might >>>>>>> lead to >>>>>>> small variations of the reported peak (a short-lived system >>>>>>> thread is >>>>>>> started while the batch of the user threads is running) or the >>>>>>> expected >>>>>>> number of running threads (again, a short-lived system thread is >>>>>>> started >>>>>>> at the moment the test asks for the number of running threads). >>>>>> >>>>>> Do you know what "system threads" these are? I would not expect VM >>>>>> internal threads to be counted in getPeakThreadCount(), but even if >>>>>> they >>>>>> are I can't think of any short-lived threads that get created other >>>>>> than >>>>>> the Signal handling thread. >>>>> >>>>> Unfortunatelly I don't. Capturing the thread dump at the moment of >>>>> discovering the discrepancy seems to to be too late. I tried >>>>> monitoring >>>>> the JVM under the test from external tools but it just brings more >>>>> entropy to the result. >>>> >>>> We'd need to instrument the thread creation logic to keep a separate >>>> record. Dtrace probes could probably do it - but the problem is >>>> getting the test to fail. >>> >>> Well, while responding to the previous email I thought about yet >>> another way to try to pinpoint the mysterious thread - I've tried NB >>> profiler. It filters out it's own threads and can do thread monitoring >>> at the same time as tracking the call tree. >>> >>> The result is that the offender is j.u.l.LogManager$Cleaner thread. I >>> am attaching the profiler snapshot (can be opened in eg. jvisualvm) >>> >>>> >>>>> I am completely relying on the JVM native thread accounting to be >>>>> correct and accurate - that it reports the thread count peak based on >>>>> the real data. >>>> >>>> The spec isn't clear but I would only expect these counters to apply >>>> to Java threads not VM internal threads (compiler, gc etc). So I'd >>>> really like to know what thread is messing up this count. >>> >>> I hope my previous finding makes this clearer. >>> >>> -JB- >>> >>>> >>>> David >>>> >>>>> -JB- >>>>> >>>>>> >>>>>>> The patch does not fix those shortcomings as it is not really >>>>>>> possible >>>>>>> to do given the nature of the JVM threading system. It rather >>>>>>> tries to >>>>>>> relax the conditions while still maintaining the ability to detect >>>>>>> functional problems - eg. decreasing peak without explicitly >>>>>>> resetting >>>>>>> it and reporting false number of threads. >>>>>>> >>>>>>> The webrev is at: >>>>>>> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 >>>>>> >>>>>> Seems reasonable. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>>> >>>>> >>> > From jaroslav.bachorik at oracle.com Tue Jul 23 03:23:38 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 23 Jul 2013 12:23:38 +0200 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EE4F60.4000506@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4F60.4000506@oracle.com> Message-ID: <51EE59AA.8010002@oracle.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/23/2013 11:39 AM, David Holmes wrote: > Sorry - I took a closer look at the full test rather than just > that patch. We already have this code to try and help expose these > intermittent failures: > > 213 // Nightly testing showed some intermittent failure. > 214 // Check here to get diagnostic information if some > strange 215 // behavior occurs. 216 > checkThreadCount(expectedCount, current, 0); Unfortunately, this does not help to get any closer to the culprit. Until the code gets to the point of making the thread dump the offending thread is gone. So you only get the information that something went wrong. - -JB- > > but the sleep loop you added means this check will rarely fail so > we won't get to see this unexpected behaviour happening. So this > block of code could be deleted in my view. Though it is preferable > to determine exactly why we fail! > > Also looking at the sleep() used elsewhere you may as well follow > the same pattern and abort on interrupt as it isn't expected. > > Finally with regard to Daniel's comment about the live array he is > right that the volatile on the array is not sufficient in theory - > a thread need never see the value of live[i] become false. There > are a number of reasons why we are unlikely to see that in practice > on hotspot. Using synchronized will fix that; or an alternative > cancellation mechanism could be used. > > Cheers, David > > On 23/07/2013 7:19 PM, David Holmes wrote: >> On 23/07/2013 6:29 PM, Jaroslav Bachorik wrote: >>> On 07/23/2013 10:19 AM, David Holmes wrote: >>>> Hi Jaroslav, >>>> >>>> On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote: >>>>> The >>>>> java/lang/management/ThreadMXBean/ResetPeakThreadCount.java >>>>> test seems to be failing intermittently. >>>>> >>>>> The test checks the functionality of the >>>>> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does >>>>> so by capturing the current value of >>>>> "getPeakThreadCount()", starting a predefined number of the >>>>> user threads, stopping them and resetting the stored peak >>>>> value and making sure the new peak equals to the number of >>>>> the actually running threads. >>>>> >>>>> The main problem is that it is not possible to prevent JVM >>>>> to start/stop arbitrary system threads while executing the >>>>> test. This might lead to small variations of the reported >>>>> peak (a short-lived system thread is started while the >>>>> batch of the user threads is running) or the expected >>>>> number of running threads (again, a short-lived system >>>>> thread is started at the moment the test asks for the >>>>> number of running threads). >>>> >>>> Do you know what "system threads" these are? I would not >>>> expect VM internal threads to be counted in >>>> getPeakThreadCount(), but even if they are I can't think of >>>> any short-lived threads that get created other than the >>>> Signal handling thread. >>> >>> Unfortunatelly I don't. Capturing the thread dump at the moment >>> of discovering the discrepancy seems to to be too late. I tried >>> monitoring the JVM under the test from external tools but it >>> just brings more entropy to the result. >> >> We'd need to instrument the thread creation logic to keep a >> separate record. Dtrace probes could probably do it - but the >> problem is getting the test to fail. >> >>> I am completely relying on the JVM native thread accounting to >>> be correct and accurate - that it reports the thread count peak >>> based on the real data. >> >> The spec isn't clear but I would only expect these counters to >> apply to Java threads not VM internal threads (compiler, gc etc). >> So I'd really like to know what thread is messing up this count. >> >> David >> >>> -JB- >>> >>>> >>>>> The patch does not fix those shortcomings as it is not >>>>> really possible to do given the nature of the JVM threading >>>>> system. It rather tries to relax the conditions while still >>>>> maintaining the ability to detect functional problems - eg. >>>>> decreasing peak without explicitly resetting it and >>>>> reporting false number of threads. >>>>> >>>>> The webrev is at: >>>>> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 >>>> >>>> Seems reasonable. >>>> >>>> David ----- >>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>>> >>> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR7lmqAAoJELSZyqhGiB1MdS8IAJEgnUI83ZQNYP2Md6vMe4C+ kGRgls2ml9x9ljwqMHnreOjww7pzyXeDKoX1vR09OD6znDUIuHkvjIOD8QRjFnjz /E0uBnoaIIhREuvbopq4dHFXU0wPPK9VnU6OgGUtTKU0aqk9256NMJwprO06CrXa TZlmUljgk3rci7pE9ZA7Up4+3Qr0tWPn5EjLAVG/UmAvC5zNptsAZcYjf8i9yQ+1 9Hp+4xY68i9QffdE3bNEAWGTQGkNy2rF4HHwSorxnruUHgi3yTxxbykJ2pBgDgYl 3IwnbrwWxNOOPW3h5DLaqCjdromCBfzYbm4xmY6Tbcxfvh0LR8QWm5eCfE151Ss= =MYqb -----END PGP SIGNATURE----- From peter.allwin at oracle.com Tue Jul 23 03:25:22 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Tue, 23 Jul 2013 12:25:22 +0200 Subject: RR(XS) 8019396: SA-JDI: OSThread class initialization throws an exception In-Reply-To: <51EE4F34.5030805@oracle.com> References: <51EE4F34.5030805@oracle.com> Message-ID: <057001ce878e$f116eb80$d344c280$@oracle.com> Dmitry, Looks good to me! Thanks, Peter > -----Original Message----- > From: serviceability-dev-bounces at openjdk.java.net [mailto:serviceability- > dev-bounces at openjdk.java.net] On Behalf Of Dmitry Samersoff > Sent: Tuesday, July 23, 2013 11:39 AM > To: serviceability-dev at openjdk.java.net > Subject: RR(XS) 8019396: SA-JDI: OSThread class initialization throws an > exception > > Hi Everybody, > > Please, review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8019396.SA-JDI/webrev.01/ > > > Method sun.jvm.hotspot.runtime.OSThread.initialize throws a > sun.jvm.hotspot.types.WrongTypeException with message: field > "_thread_id" in type OSThread is not of type jint, but instead of type > unsigned OSThread::thread_id_t. > > After fixing an exception test still fails, because of wrong value used for > JVMTI_THREAD_STATE_WAITING, fixed it as well. > > Testing: > > nsk/sajdi/ThreadReference/status/status002 > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Tue Jul 23 03:31:31 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jul 2013 20:31:31 +1000 Subject: RR(XS) 8019396: SA-JDI: OSThread class initialization throws an exception In-Reply-To: <51EE4F34.5030805@oracle.com> References: <51EE4F34.5030805@oracle.com> Message-ID: <51EE5B83.7050305@oracle.com> Hi Dmitry, Looks okay. Minor nit: ! return (int)threadIdField.getJInt(addr); The cast should not be need as getJInt returns int. Aside: this looks like a major bug in BasicField to me: public long getJLong(Address addr) ... A jlong is 64-bits but a long may be 32-bits! David On 23/07/2013 7:39 PM, Dmitry Samersoff wrote: > Hi Everybody, > > Please, review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8019396.SA-JDI/webrev.01/ > > > Method sun.jvm.hotspot.runtime.OSThread.initialize throws a > sun.jvm.hotspot.types.WrongTypeException with message: field > "_thread_id" in type OSThread is not of type jint, but instead of type > unsigned OSThread::thread_id_t. > > After fixing an exception test still fails, because of wrong value used > for JVMTI_THREAD_STATE_WAITING, fixed it as well. > > Testing: > > nsk/sajdi/ThreadReference/status/status002 > > -Dmitry > From mikael.gerdin at oracle.com Tue Jul 23 04:37:46 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 23 Jul 2013 13:37:46 +0200 Subject: RR(XS) 8019396: SA-JDI: OSThread class initialization throws an exception In-Reply-To: <51EE5B83.7050305@oracle.com> References: <51EE4F34.5030805@oracle.com> <51EE5B83.7050305@oracle.com> Message-ID: <51EE6B0A.3000903@oracle.com> David, On 2013-07-23 12:31, David Holmes wrote: > Hi Dmitry, > > Looks okay. > > Minor nit: > > ! return (int)threadIdField.getJInt(addr); > > The cast should not be need as getJInt returns int. > > Aside: this looks like a major bug in BasicField to me: > > public long getJLong(Address addr) ... > > A jlong is 64-bits but a long may be 32-bits! But isn't that a Java land "long"? That's the definition of jlong :) /Mikael > > David > > On 23/07/2013 7:39 PM, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please, review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8019396.SA-JDI/webrev.01/ >> >> >> Method sun.jvm.hotspot.runtime.OSThread.initialize throws a >> sun.jvm.hotspot.types.WrongTypeException with message: field >> "_thread_id" in type OSThread is not of type jint, but instead of type >> unsigned OSThread::thread_id_t. >> >> After fixing an exception test still fails, because of wrong value used >> for JVMTI_THREAD_STATE_WAITING, fixed it as well. >> >> Testing: >> >> nsk/sajdi/ThreadReference/status/status002 >> >> -Dmitry >> From ivan.gerasimov at oracle.com Tue Jul 23 07:14:06 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 23 Jul 2013 18:14:06 +0400 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51DD399E.4030105@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> <51D64D15.2090105@oracle.com> <51D6A59A.1060703@oracle.com> <51D6B1ED.9090709@oracle.com> <51DAEF13.8010000@oracle.com> <51DAF69C.3000404@oracle.com> <51DC0B8C.9010804@oracle.com> <51DD2638.9070801@oracle.com> <51DD399E.4030105@oracle.com> Message-ID: <51EE8FAE.90808@oracle.com> Hello Daniel! Can we please move forward with this issue? I've just checked how the tests run against the latest jdk build (which is 99), and the leak is still there. Thus the proposed change (including ProblemList modifications) is still actual. Here's a link to the latest webrev: http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ I've also run jprt job to check how it works on all other platforms: http://prt-web.us.oracle.com//archive/2013/07/2013-07-22-143846.igerasim.jdk/logs/ On all the platforms (including 32-bit Linux) the tests passed as expected, on the Linux-x64 both tests were skipped. Virtual memory growth across {fastdebug,product}-{c1,c2} targets was in range from 1188K to 2584K which is less than the chosen threshold of 32M. Sincerely yours, Ivan Gerasimov On 10.07.2013 14:38, Ivan Gerasimov wrote: > Yes, I forgot to include the most important thing - a link to webrev! > Your link is correct. > http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ > > The tests fail on linux-x64 only, linux-i586 is fine. > Here's the link to the logs of the tests run by Daniel Daugherty: > http://prt-web.us.oracle.com//archive/2013/07/2013-07-05-045326.ddaugher.8016838_exp/logs/ > > > Thus the memory leak seems to be specific to 64-bit Linux. > > Sincerely yours, > Ivan > > On 10.07.2013 13:15, Se?n Coffey wrote: >> Ivan, >> >> I'll assume this is the latest webrev : >> http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ >> >> >> One comment - should the test be excluded for all linux variants >> (i.e. linux-all) ? >> >> regards, >> Sean. >> >> On 09/07/2013 14:09, Ivan Gerasimov wrote: >>> Please have a chance to review an updated webrev. >>> It now includes a change to ProblemList.txt, so both modified tests >>> are ignored for linux-x64. >>> >>> Sincerely yours, >>> Ivan Gersimov >>> >>> On 08.07.2013 21:27, Se?n Coffey wrote: >>>> >>>> On 08/07/13 17:55, Ivan Gerasimov wrote: >>>>> Thanks, Se?n! >>>>> >>>>> I located the build in which the memleak was first introduced -- >>>>> it is jdk8-b69 (hs25-b13). >>>>> I've updated the bug >>>>> http://bugs.sun.com/view_bug.do?bug_id=8019845 with this. >>>>> >>>>> So what is the correct procedure to go forward now? >>>>> Should I update the webrev to include changes to the problem list? >>>>> I believe I shouldn't -- this list seems to be a sensitive stuff. >>>> I'd suggest updating the webrev with the ProblemList >>>> modification/addition. It's best not to add a test to testruns if >>>> it's knowingly failing. The test can be removed from ProblemList >>>> when the jdk8 regression is fixed. >>>> >>>> regards, >>>> Sean. >>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>> On 05.07.2013 15:45, Se?n Coffey wrote: >>>>>> Nice work indeed Ivan. Good to have a reliable testcase to catch >>>>>> leaks in this area. >>>>>> >>>>>> I'd also suggest that this test goes on the ProblemList until the >>>>>> new leak is sorted out for jdk8. The goal of JPRT runs is to have >>>>>> clean runs. If it's on the problemList, then it's a known issue >>>>>> and is normally tagged with the relevant bug ID so that the >>>>>> responsible engineer knows the current state. >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>> On 05/07/2013 11:53, Ivan Gerasimov wrote: >>>>>>> >>>>>>> On 05.07.2013 8:35, Daniel D. Daugherty wrote: >>>>>>>> Ivan, >>>>>>>> >>>>>>>> The changes look fine, I can sponsor your commit, looks like your >>>>>>>> OpenJDK user name is 'igerasim', but I need to know a little bit >>>>>>>> more about your testing of these fixes. Did you do a test JPRT >>>>>>>> job to run the JLI tests (or just the two tests themselves)? >>>>>>>> >>>>>>> I've only run test from java/lang/instrument when checked the >>>>>>> change with JDK6u60 (all passed) and with JDK6u51 (the test >>>>>>> failed as expected, since the leak had still been there.) >>>>>>> >>>>>>>> Based on e-mail about this bug fix, I believe you've found a new >>>>>>>> leak in JDK8/HSX-25 with test >>>>>>>> java/lang/instrument/RedefineBigClass.sh. >>>>>>> Right. The test shown a memleak with the the latest jdk8. >>>>>>> I filed a bug 8019845 about this leak. >>>>>>> Stefan Karlsson guessed that this may be related to 8003419 >>>>>>> (NPG: Clean up metadata created during class loading if failure) >>>>>>> Then I've checked the builds b57 (test failed) and b58 (test >>>>>>> passed), so I confirmed that it may be the reason of the leak >>>>>>> being observed now. >>>>>>> But now I think that the reason may be different. >>>>>>> It just turns out that the test shows failures for (at least) >>>>>>> three different leaks - the one you, Daniel, solved (7121600), >>>>>>> the one Stefan wrote about (8003419) and the one currently >>>>>>> observed (8019845). >>>>>>> >>>>>>>> That's a good thing, but I think Alan and company would be a bit >>>>>>>> grumpy with me if I pushed a test that failed as soon as someone >>>>>>>> ran it. :-) Do you know if the revised RetransformBigClass.sh also >>>>>>>> finds a new memory leak in JDK8/HSX-25? >>>>>>>> >>>>>>>> The way to deal with that is to put the test on the Problem.list >>>>>>>> as part of the same changeset. However, the T&L folks might not >>>>>>>> like >>>>>>>> that either... >>>>>>> >>>>>>> Well, the leak is there, and why not have a failing test as a >>>>>>> reminder to have it fixed? >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan Gerasimov >>>>>>> >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> On 7/4/13 6:59 PM, Ivan Gerasimov wrote: >>>>>>>>> Thank you, Daniel! >>>>>>>>> >>>>>>>>> Please find an updated webrev at >>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. >>>>>>>>> It now includes the RetransformBigClass test modified in the >>>>>>>>> same way as RedefineBigClass >>>>>>>>> If the changes look fine, may I ask you to sponsor the commit, >>>>>>>>> as I'm not a committer? >>>>>>>>> Here's a link to hg export: >>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks in advance, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> On 04.07.2013 21:45, Daniel D. Daugherty wrote: >>>>>>>>>> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>>>>>>>>>> Daniel, thank you for review! >>>>>>>>>>> >>>>>>>>>>> Here's the updated with all all your suggestions adopted. >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >>>>>>>>>> >>>>>>>>>> Looks good. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I haven't yet considered applying the approach to >>>>>>>>>>> RetransformBigClass. >>>>>>>>>>> Do you want me to include this into this same change set or >>>>>>>>>>> should I make it separately? >>>>>>>>>> >>>>>>>>>> I would include it in the same changeset. >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>>>>>>>>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>> >>>>>>>>>>>>> We have a request to improve jtreg test. >>>>>>>>>>>>> The test had been written to verify fix for memory leak >>>>>>>>>>>>> during class redefinition. >>>>>>>>>>>>> The problem is that it always is reported as PASSED even >>>>>>>>>>>>> in the presence of the leak. >>>>>>>>>>>>> >>>>>>>>>>>>> The proposed change is platform specific. >>>>>>>>>>>>> It allows memory leak detection only on Linux. >>>>>>>>>>>>> This is because the memory leak was in native code, so >>>>>>>>>>>>> there's no easy way to detect it from within Java code. >>>>>>>>>>>>> >>>>>>>>>>>>> Here's the webrev for JDK8 repository: >>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Very nicely done! The logic in RedefineBigClass.sh only >>>>>>>>>>>> catches a >>>>>>>>>>>> leak big enough to cause an Exception to be thrown. >>>>>>>>>>>> >>>>>>>>>>>> When I originally wrote this test and its companion: >>>>>>>>>>>> >>>>>>>>>>>> test/java/lang/instrument/RetransformBigClass* >>>>>>>>>>>> >>>>>>>>>>>> I could not come up with a platform independent way to put >>>>>>>>>>>> a small >>>>>>>>>>>> upper limit on memory growth. It never dawned on me that >>>>>>>>>>>> putting in >>>>>>>>>>>> something on one platform (Linux) was better than nothing. >>>>>>>>>>>> >>>>>>>>>>>> Are you planning to add this same logic to >>>>>>>>>>>> RetransformBigClass*? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> test/java/lang/instrument/RedefineBigClass.sh >>>>>>>>>>>> No comments. >>>>>>>>>>>> >>>>>>>>>>>> test/java/lang/instrument/RedefineBigClassApp.java >>>>>>>>>>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // >>>>>>>>>>>> 32Mb >>>>>>>>>>>> Would be better at the top of RedefineBigClassApp >>>>>>>>>>>> rather than >>>>>>>>>>>> "buried" down here. >>>>>>>>>>>> >>>>>>>>>>>> line 51: Long.valueOf(vmMemDelta) >>>>>>>>>>>> There are several places where a long is passed to >>>>>>>>>>>> Long.valueOf(). >>>>>>>>>>>> Is there some reason you're not passing them >>>>>>>>>>>> directly to println()? >>>>>>>>>>>> >>>>>>>>>>>> line 54: } else { >>>>>>>>>>>> The "else" is redundant due to the "System.exit(1)" >>>>>>>>>>>> call above it. >>>>>>>>>>>> You can drop the "else {" and "}" and shift that >>>>>>>>>>>> last println() to >>>>>>>>>>>> the left. >>>>>>>>>>>> >>>>>>>>>>>> line 71: return Long.parseLong(line.split(" ")[22]) / >>>>>>>>>>>> 1024; >>>>>>>>>>>> How about at least a comment referring to the Linux >>>>>>>>>>>> proc(5) >>>>>>>>>>>> man page... and the fact that the 23rd field is: >>>>>>>>>>>> >>>>>>>>>>>> vsize %lu Virtual memory size in bytes. >>>>>>>>>>>> >>>>>>>>>>>> Again, very nicely done! >>>>>>>>>>>> >>>>>>>>>>>> Dan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The surprising thing is that modified test detected the >>>>>>>>>>>>> leak with the latest JDK8! >>>>>>>>>>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>>>>>>>>>> >>>>>>>>>>>>> I've filled a bug >>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019845 "Memory >>>>>>>>>>>>> leak during class redefenition" (not yet available.) >>>>>>>>>>>>> >>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>> Ivan Gerasimov >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > > > From daniel.daugherty at oracle.com Tue Jul 23 07:50:16 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 23 Jul 2013 08:50:16 -0600 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51EE8FAE.90808@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> <51D64D15.2090105@oracle.com> <51D6A59A.1060703@oracle.com> <51D6B1ED.9090709@oracle.com> <51DAEF13.8010000@oracle.com> <51DAF69C.3000404@oracle.com> <51DC0B8C.9010804@oracle.com> <51DD2638.9070801@oracle.com> <51DD399E.4030105@oracle.com> <51EE8FAE.90808@oracle.com> Message-ID: <51EE9828.4070200@oracle.com> Ivan, Sorry for forgetting about this issue... On 7/23/13 8:14 AM, Ivan Gerasimov wrote: > Hello Daniel! > > Can we please move forward with this issue? Yes. Do you have a pointer to the committed patch file? If so, I'll take care of getting the fix into JDK8-T&L. Dan > I've just checked how the tests run against the latest jdk build > (which is 99), and the leak is still there. > Thus the proposed change (including ProblemList modifications) is > still actual. > > Here's a link to the latest webrev: > http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ > > I've also run jprt job to check how it works on all other platforms: > http://prt-web.us.oracle.com//archive/2013/07/2013-07-22-143846.igerasim.jdk/logs/ > > > On all the platforms (including 32-bit Linux) the tests passed as > expected, on the Linux-x64 both tests were skipped. > > Virtual memory growth across {fastdebug,product}-{c1,c2} targets was > in range from 1188K to 2584K which is less than the chosen threshold > of 32M. > > Sincerely yours, > Ivan Gerasimov > > > On 10.07.2013 14:38, Ivan Gerasimov wrote: >> Yes, I forgot to include the most important thing - a link to webrev! >> Your link is correct. >> http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ >> >> The tests fail on linux-x64 only, linux-i586 is fine. >> Here's the link to the logs of the tests run by Daniel Daugherty: >> http://prt-web.us.oracle.com//archive/2013/07/2013-07-05-045326.ddaugher.8016838_exp/logs/ >> >> >> Thus the memory leak seems to be specific to 64-bit Linux. >> >> Sincerely yours, >> Ivan >> >> On 10.07.2013 13:15, Se?n Coffey wrote: >>> Ivan, >>> >>> I'll assume this is the latest webrev : >>> http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ >>> >>> >>> One comment - should the test be excluded for all linux variants >>> (i.e. linux-all) ? >>> >>> regards, >>> Sean. >>> >>> On 09/07/2013 14:09, Ivan Gerasimov wrote: >>>> Please have a chance to review an updated webrev. >>>> It now includes a change to ProblemList.txt, so both modified tests >>>> are ignored for linux-x64. >>>> >>>> Sincerely yours, >>>> Ivan Gersimov >>>> >>>> On 08.07.2013 21:27, Se?n Coffey wrote: >>>>> >>>>> On 08/07/13 17:55, Ivan Gerasimov wrote: >>>>>> Thanks, Se?n! >>>>>> >>>>>> I located the build in which the memleak was first introduced -- >>>>>> it is jdk8-b69 (hs25-b13). >>>>>> I've updated the bug >>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019845 with this. >>>>>> >>>>>> So what is the correct procedure to go forward now? >>>>>> Should I update the webrev to include changes to the problem list? >>>>>> I believe I shouldn't -- this list seems to be a sensitive stuff. >>>>> I'd suggest updating the webrev with the ProblemList >>>>> modification/addition. It's best not to add a test to testruns if >>>>> it's knowingly failing. The test can be removed from ProblemList >>>>> when the jdk8 regression is fixed. >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> >>>>>> On 05.07.2013 15:45, Se?n Coffey wrote: >>>>>>> Nice work indeed Ivan. Good to have a reliable testcase to catch >>>>>>> leaks in this area. >>>>>>> >>>>>>> I'd also suggest that this test goes on the ProblemList until >>>>>>> the new leak is sorted out for jdk8. The goal of JPRT runs is to >>>>>>> have clean runs. If it's on the problemList, then it's a known >>>>>>> issue and is normally tagged with the relevant bug ID so that >>>>>>> the responsible engineer knows the current state. >>>>>>> >>>>>>> regards, >>>>>>> Sean. >>>>>>> >>>>>>> On 05/07/2013 11:53, Ivan Gerasimov wrote: >>>>>>>> >>>>>>>> On 05.07.2013 8:35, Daniel D. Daugherty wrote: >>>>>>>>> Ivan, >>>>>>>>> >>>>>>>>> The changes look fine, I can sponsor your commit, looks like your >>>>>>>>> OpenJDK user name is 'igerasim', but I need to know a little bit >>>>>>>>> more about your testing of these fixes. Did you do a test JPRT >>>>>>>>> job to run the JLI tests (or just the two tests themselves)? >>>>>>>>> >>>>>>>> I've only run test from java/lang/instrument when checked the >>>>>>>> change with JDK6u60 (all passed) and with JDK6u51 (the test >>>>>>>> failed as expected, since the leak had still been there.) >>>>>>>> >>>>>>>>> Based on e-mail about this bug fix, I believe you've found a new >>>>>>>>> leak in JDK8/HSX-25 with test >>>>>>>>> java/lang/instrument/RedefineBigClass.sh. >>>>>>>> Right. The test shown a memleak with the the latest jdk8. >>>>>>>> I filed a bug 8019845 about this leak. >>>>>>>> Stefan Karlsson guessed that this may be related to 8003419 >>>>>>>> (NPG: Clean up metadata created during class loading if failure) >>>>>>>> Then I've checked the builds b57 (test failed) and b58 (test >>>>>>>> passed), so I confirmed that it may be the reason of the leak >>>>>>>> being observed now. >>>>>>>> But now I think that the reason may be different. >>>>>>>> It just turns out that the test shows failures for (at least) >>>>>>>> three different leaks - the one you, Daniel, solved (7121600), >>>>>>>> the one Stefan wrote about (8003419) and the one currently >>>>>>>> observed (8019845). >>>>>>>> >>>>>>>>> That's a good thing, but I think Alan and company would be a bit >>>>>>>>> grumpy with me if I pushed a test that failed as soon as someone >>>>>>>>> ran it. :-) Do you know if the revised RetransformBigClass.sh >>>>>>>>> also >>>>>>>>> finds a new memory leak in JDK8/HSX-25? >>>>>>>>> >>>>>>>>> The way to deal with that is to put the test on the Problem.list >>>>>>>>> as part of the same changeset. However, the T&L folks might >>>>>>>>> not like >>>>>>>>> that either... >>>>>>>> >>>>>>>> Well, the leak is there, and why not have a failing test as a >>>>>>>> reminder to have it fixed? >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan Gerasimov >>>>>>>> >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/4/13 6:59 PM, Ivan Gerasimov wrote: >>>>>>>>>> Thank you, Daniel! >>>>>>>>>> >>>>>>>>>> Please find an updated webrev at >>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. >>>>>>>>>> It now includes the RetransformBigClass test modified in the >>>>>>>>>> same way as RedefineBigClass >>>>>>>>>> If the changes look fine, may I ask you to sponsor the >>>>>>>>>> commit, as I'm not a committer? >>>>>>>>>> Here's a link to hg export: >>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks in advance, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> On 04.07.2013 21:45, Daniel D. Daugherty wrote: >>>>>>>>>>> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>>>>>>>>>>> Daniel, thank you for review! >>>>>>>>>>>> >>>>>>>>>>>> Here's the updated with all all your suggestions adopted. >>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >>>>>>>>>>> >>>>>>>>>>> Looks good. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I haven't yet considered applying the approach to >>>>>>>>>>>> RetransformBigClass. >>>>>>>>>>>> Do you want me to include this into this same change set or >>>>>>>>>>>> should I make it separately? >>>>>>>>>>> >>>>>>>>>>> I would include it in the same changeset. >>>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>>>>>>>>>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>> >>>>>>>>>>>>>> We have a request to improve jtreg test. >>>>>>>>>>>>>> The test had been written to verify fix for memory leak >>>>>>>>>>>>>> during class redefinition. >>>>>>>>>>>>>> The problem is that it always is reported as PASSED even >>>>>>>>>>>>>> in the presence of the leak. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The proposed change is platform specific. >>>>>>>>>>>>>> It allows memory leak detection only on Linux. >>>>>>>>>>>>>> This is because the memory leak was in native code, so >>>>>>>>>>>>>> there's no easy way to detect it from within Java code. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here's the webrev for JDK8 repository: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>>>>>>>>>>> >>>>>>>>>>>>> Very nicely done! The logic in RedefineBigClass.sh only >>>>>>>>>>>>> catches a >>>>>>>>>>>>> leak big enough to cause an Exception to be thrown. >>>>>>>>>>>>> >>>>>>>>>>>>> When I originally wrote this test and its companion: >>>>>>>>>>>>> >>>>>>>>>>>>> test/java/lang/instrument/RetransformBigClass* >>>>>>>>>>>>> >>>>>>>>>>>>> I could not come up with a platform independent way to put >>>>>>>>>>>>> a small >>>>>>>>>>>>> upper limit on memory growth. It never dawned on me that >>>>>>>>>>>>> putting in >>>>>>>>>>>>> something on one platform (Linux) was better than nothing. >>>>>>>>>>>>> >>>>>>>>>>>>> Are you planning to add this same logic to >>>>>>>>>>>>> RetransformBigClass*? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> test/java/lang/instrument/RedefineBigClass.sh >>>>>>>>>>>>> No comments. >>>>>>>>>>>>> >>>>>>>>>>>>> test/java/lang/instrument/RedefineBigClassApp.java >>>>>>>>>>>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // >>>>>>>>>>>>> 32Mb >>>>>>>>>>>>> Would be better at the top of RedefineBigClassApp >>>>>>>>>>>>> rather than >>>>>>>>>>>>> "buried" down here. >>>>>>>>>>>>> >>>>>>>>>>>>> line 51: Long.valueOf(vmMemDelta) >>>>>>>>>>>>> There are several places where a long is passed to >>>>>>>>>>>>> Long.valueOf(). >>>>>>>>>>>>> Is there some reason you're not passing them >>>>>>>>>>>>> directly to println()? >>>>>>>>>>>>> >>>>>>>>>>>>> line 54: } else { >>>>>>>>>>>>> The "else" is redundant due to the >>>>>>>>>>>>> "System.exit(1)" call above it. >>>>>>>>>>>>> You can drop the "else {" and "}" and shift that >>>>>>>>>>>>> last println() to >>>>>>>>>>>>> the left. >>>>>>>>>>>>> >>>>>>>>>>>>> line 71: return Long.parseLong(line.split(" ")[22]) / >>>>>>>>>>>>> 1024; >>>>>>>>>>>>> How about at least a comment referring to the >>>>>>>>>>>>> Linux proc(5) >>>>>>>>>>>>> man page... and the fact that the 23rd field is: >>>>>>>>>>>>> >>>>>>>>>>>>> vsize %lu Virtual memory size in bytes. >>>>>>>>>>>>> >>>>>>>>>>>>> Again, very nicely done! >>>>>>>>>>>>> >>>>>>>>>>>>> Dan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The surprising thing is that modified test detected the >>>>>>>>>>>>>> leak with the latest JDK8! >>>>>>>>>>>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've filled a bug >>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019845 "Memory >>>>>>>>>>>>>> leak during class redefenition" (not yet available.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>> Ivan Gerasimov >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> >> > From ivan.gerasimov at oracle.com Tue Jul 23 08:06:12 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 23 Jul 2013 19:06:12 +0400 Subject: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification In-Reply-To: <51EE9828.4070200@oracle.com> References: <51D45B8C.7010109@oracle.com> <51D595ED.7050902@oracle.com> <51D5AEB6.3060608@oracle.com> <51D5B4C5.7060402@oracle.com> <51D61A66.5010001@oracle.com> <51D64D15.2090105@oracle.com> <51D6A59A.1060703@oracle.com> <51D6B1ED.9090709@oracle.com> <51DAEF13.8010000@oracle.com> <51DAF69C.3000404@oracle.com> <51DC0B8C.9010804@oracle.com> <51DD2638.9070801@oracle.com> <51DD399E.4030105@oracle.com> <51EE8FAE.90808@oracle.com> <51EE9828.4070200@oracle.com> Message-ID: <51EE9BE4.6020908@oracle.com> On 23.07.2013 18:50, Daniel D. Daugherty wrote: > Yes. Do you have a pointer to the committed patch file? > If so, I'll take care of getting the fix into JDK8-T&L. Thanks a lot! I really appreciate it. Here's the link: http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch I've just updated the file to include the latest changes. Sincerely yours, Ivan > Dan > > >> I've just checked how the tests run against the latest jdk build >> (which is 99), and the leak is still there. >> Thus the proposed change (including ProblemList modifications) is >> still actual. >> >> Here's a link to the latest webrev: >> http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ >> >> I've also run jprt job to check how it works on all other platforms: >> http://prt-web.us.oracle.com//archive/2013/07/2013-07-22-143846.igerasim.jdk/logs/ >> >> >> On all the platforms (including 32-bit Linux) the tests passed as >> expected, on the Linux-x64 both tests were skipped. >> >> Virtual memory growth across {fastdebug,product}-{c1,c2} targets was >> in range from 1188K to 2584K which is less than the chosen threshold >> of 32M. >> >> Sincerely yours, >> Ivan Gerasimov >> >> >> On 10.07.2013 14:38, Ivan Gerasimov wrote: >>> Yes, I forgot to include the most important thing - a link to webrev! >>> Your link is correct. >>> http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ >>> >>> The tests fail on linux-x64 only, linux-i586 is fine. >>> Here's the link to the logs of the tests run by Daniel Daugherty: >>> http://prt-web.us.oracle.com//archive/2013/07/2013-07-05-045326.ddaugher.8016838_exp/logs/ >>> >>> >>> Thus the memory leak seems to be specific to 64-bit Linux. >>> >>> Sincerely yours, >>> Ivan >>> >>> On 10.07.2013 13:15, Se?n Coffey wrote: >>>> Ivan, >>>> >>>> I'll assume this is the latest webrev : >>>> http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/ >>>> >>>> >>>> One comment - should the test be excluded for all linux variants >>>> (i.e. linux-all) ? >>>> >>>> regards, >>>> Sean. >>>> >>>> On 09/07/2013 14:09, Ivan Gerasimov wrote: >>>>> Please have a chance to review an updated webrev. >>>>> It now includes a change to ProblemList.txt, so both modified >>>>> tests are ignored for linux-x64. >>>>> >>>>> Sincerely yours, >>>>> Ivan Gersimov >>>>> >>>>> On 08.07.2013 21:27, Se?n Coffey wrote: >>>>>> >>>>>> On 08/07/13 17:55, Ivan Gerasimov wrote: >>>>>>> Thanks, Se?n! >>>>>>> >>>>>>> I located the build in which the memleak was first introduced -- >>>>>>> it is jdk8-b69 (hs25-b13). >>>>>>> I've updated the bug >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019845 with this. >>>>>>> >>>>>>> So what is the correct procedure to go forward now? >>>>>>> Should I update the webrev to include changes to the problem list? >>>>>>> I believe I shouldn't -- this list seems to be a sensitive stuff. >>>>>> I'd suggest updating the webrev with the ProblemList >>>>>> modification/addition. It's best not to add a test to testruns if >>>>>> it's knowingly failing. The test can be removed from ProblemList >>>>>> when the jdk8 regression is fixed. >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>> On 05.07.2013 15:45, Se?n Coffey wrote: >>>>>>>> Nice work indeed Ivan. Good to have a reliable testcase to >>>>>>>> catch leaks in this area. >>>>>>>> >>>>>>>> I'd also suggest that this test goes on the ProblemList until >>>>>>>> the new leak is sorted out for jdk8. The goal of JPRT runs is >>>>>>>> to have clean runs. If it's on the problemList, then it's a >>>>>>>> known issue and is normally tagged with the relevant bug ID so >>>>>>>> that the responsible engineer knows the current state. >>>>>>>> >>>>>>>> regards, >>>>>>>> Sean. >>>>>>>> >>>>>>>> On 05/07/2013 11:53, Ivan Gerasimov wrote: >>>>>>>>> >>>>>>>>> On 05.07.2013 8:35, Daniel D. Daugherty wrote: >>>>>>>>>> Ivan, >>>>>>>>>> >>>>>>>>>> The changes look fine, I can sponsor your commit, looks like >>>>>>>>>> your >>>>>>>>>> OpenJDK user name is 'igerasim', but I need to know a little bit >>>>>>>>>> more about your testing of these fixes. Did you do a test JPRT >>>>>>>>>> job to run the JLI tests (or just the two tests themselves)? >>>>>>>>>> >>>>>>>>> I've only run test from java/lang/instrument when checked the >>>>>>>>> change with JDK6u60 (all passed) and with JDK6u51 (the test >>>>>>>>> failed as expected, since the leak had still been there.) >>>>>>>>> >>>>>>>>>> Based on e-mail about this bug fix, I believe you've found a new >>>>>>>>>> leak in JDK8/HSX-25 with test >>>>>>>>>> java/lang/instrument/RedefineBigClass.sh. >>>>>>>>> Right. The test shown a memleak with the the latest jdk8. >>>>>>>>> I filed a bug 8019845 about this leak. >>>>>>>>> Stefan Karlsson guessed that this may be related to 8003419 >>>>>>>>> (NPG: Clean up metadata created during class loading if failure) >>>>>>>>> Then I've checked the builds b57 (test failed) and b58 (test >>>>>>>>> passed), so I confirmed that it may be the reason of the leak >>>>>>>>> being observed now. >>>>>>>>> But now I think that the reason may be different. >>>>>>>>> It just turns out that the test shows failures for (at least) >>>>>>>>> three different leaks - the one you, Daniel, solved (7121600), >>>>>>>>> the one Stefan wrote about (8003419) and the one currently >>>>>>>>> observed (8019845). >>>>>>>>> >>>>>>>>>> That's a good thing, but I think Alan and company would be a bit >>>>>>>>>> grumpy with me if I pushed a test that failed as soon as someone >>>>>>>>>> ran it. :-) Do you know if the revised RetransformBigClass.sh >>>>>>>>>> also >>>>>>>>>> finds a new memory leak in JDK8/HSX-25? >>>>>>>>>> >>>>>>>>>> The way to deal with that is to put the test on the Problem.list >>>>>>>>>> as part of the same changeset. However, the T&L folks might >>>>>>>>>> not like >>>>>>>>>> that either... >>>>>>>>> >>>>>>>>> Well, the leak is there, and why not have a failing test as a >>>>>>>>> reminder to have it fixed? >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan Gerasimov >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/4/13 6:59 PM, Ivan Gerasimov wrote: >>>>>>>>>>> Thank you, Daniel! >>>>>>>>>>> >>>>>>>>>>> Please find an updated webrev at >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/. >>>>>>>>>>> It now includes the RetransformBigClass test modified in the >>>>>>>>>>> same way as RedefineBigClass >>>>>>>>>>> If the changes look fine, may I ask you to sponsor the >>>>>>>>>>> commit, as I'm not a committer? >>>>>>>>>>> Here's a link to hg export: >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks in advance, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> On 04.07.2013 21:45, Daniel D. Daugherty wrote: >>>>>>>>>>>> On 7/4/13 11:19 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>> Daniel, thank you for review! >>>>>>>>>>>>> >>>>>>>>>>>>> Here's the updated with all all your suggestions adopted. >>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Looks good. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I haven't yet considered applying the approach to >>>>>>>>>>>>> RetransformBigClass. >>>>>>>>>>>>> Do you want me to include this into this same change set >>>>>>>>>>>>> or should I make it separately? >>>>>>>>>>>> >>>>>>>>>>>> I would include it in the same changeset. >>>>>>>>>>>> >>>>>>>>>>>> Dan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>> Ivan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 04.07.2013 19:34, Daniel D. Daugherty wrote: >>>>>>>>>>>>>> On 7/3/13 11:12 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We have a request to improve jtreg test. >>>>>>>>>>>>>>> The test had been written to verify fix for memory leak >>>>>>>>>>>>>>> during class redefinition. >>>>>>>>>>>>>>> The problem is that it always is reported as PASSED even >>>>>>>>>>>>>>> in the presence of the leak. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The proposed change is platform specific. >>>>>>>>>>>>>>> It allows memory leak detection only on Linux. >>>>>>>>>>>>>>> This is because the memory leak was in native code, so >>>>>>>>>>>>>>> there's no easy way to detect it from within Java code. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Here's the webrev for JDK8 repository: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Very nicely done! The logic in RedefineBigClass.sh only >>>>>>>>>>>>>> catches a >>>>>>>>>>>>>> leak big enough to cause an Exception to be thrown. >>>>>>>>>>>>>> >>>>>>>>>>>>>> When I originally wrote this test and its companion: >>>>>>>>>>>>>> >>>>>>>>>>>>>> test/java/lang/instrument/RetransformBigClass* >>>>>>>>>>>>>> >>>>>>>>>>>>>> I could not come up with a platform independent way to >>>>>>>>>>>>>> put a small >>>>>>>>>>>>>> upper limit on memory growth. It never dawned on me that >>>>>>>>>>>>>> putting in >>>>>>>>>>>>>> something on one platform (Linux) was better than nothing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Are you planning to add this same logic to >>>>>>>>>>>>>> RetransformBigClass*? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> test/java/lang/instrument/RedefineBigClass.sh >>>>>>>>>>>>>> No comments. >>>>>>>>>>>>>> >>>>>>>>>>>>>> test/java/lang/instrument/RedefineBigClassApp.java >>>>>>>>>>>>>> line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; >>>>>>>>>>>>>> // 32Mb >>>>>>>>>>>>>> Would be better at the top of RedefineBigClassApp >>>>>>>>>>>>>> rather than >>>>>>>>>>>>>> "buried" down here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> line 51: Long.valueOf(vmMemDelta) >>>>>>>>>>>>>> There are several places where a long is passed >>>>>>>>>>>>>> to Long.valueOf(). >>>>>>>>>>>>>> Is there some reason you're not passing them >>>>>>>>>>>>>> directly to println()? >>>>>>>>>>>>>> >>>>>>>>>>>>>> line 54: } else { >>>>>>>>>>>>>> The "else" is redundant due to the >>>>>>>>>>>>>> "System.exit(1)" call above it. >>>>>>>>>>>>>> You can drop the "else {" and "}" and shift that >>>>>>>>>>>>>> last println() to >>>>>>>>>>>>>> the left. >>>>>>>>>>>>>> >>>>>>>>>>>>>> line 71: return Long.parseLong(line.split(" ")[22]) / >>>>>>>>>>>>>> 1024; >>>>>>>>>>>>>> How about at least a comment referring to the >>>>>>>>>>>>>> Linux proc(5) >>>>>>>>>>>>>> man page... and the fact that the 23rd field is: >>>>>>>>>>>>>> >>>>>>>>>>>>>> vsize %lu Virtual memory size in bytes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Again, very nicely done! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Dan >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The surprising thing is that modified test detected the >>>>>>>>>>>>>>> leak with the latest JDK8! >>>>>>>>>>>>>>> Latest 6 and 7 are fine, so it might be regression in JDK8. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've filled a bug >>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8019845 "Memory >>>>>>>>>>>>>>> leak during class redefenition" (not yet available.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>> Ivan Gerasimov >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> > > > From shanliang.jiang at oracle.com Tue Jul 23 08:30:17 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 23 Jul 2013 17:30:17 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51ED1DBE.3030304@oracle.com> References: <51ED1DBE.3030304@oracle.com> Message-ID: <51EEA189.5000801@oracle.com> If it is not possible to prevent JVM to start/stop arbitrary system threads, then the test may still fail even with the fix, but I should say the fix improves the test. Line 176: // assuming no system thread is added so here at line 177 is still a potential failure, even very little. To know a thread status, better to call Thread.getState() for example we can save all MyThread instances into a list, and then check them one by one like: for (Thread t : list) { while (t.getState() != TERMINATED) { Thread.sleep(10); } } (can add a max waiting time here) this is because it is possible that a MyThread is suspended after calling: barrier.signal(); but before leaving run() method, especially when stopping many threads at same time on a slow testing machine. Shanliang Jaroslav Bachorik wrote: > The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test > seems to be failing intermittently. > > The test checks the functionality of the > j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by > capturing the current value of "getPeakThreadCount()", starting a > predefined number of the user threads, stopping them and resetting the > stored peak value and making sure the new peak equals to the number of > the actually running threads. > > The main problem is that it is not possible to prevent JVM to start/stop > arbitrary system threads while executing the test. This might lead to > small variations of the reported peak (a short-lived system thread is > started while the batch of the user threads is running) or the expected > number of running threads (again, a short-lived system thread is started > at the moment the test asks for the number of running threads). > > The patch does not fix those shortcomings as it is not really possible > to do given the nature of the JVM threading system. It rather tries to > relax the conditions while still maintaining the ability to detect > functional problems - eg. decreasing peak without explicitly resetting > it and reporting false number of threads. > > The webrev is at: > http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 > > Thanks, > > -JB- > From coleen.phillimore at oracle.com Tue Jul 23 08:38:40 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 23 Jul 2013 15:38:40 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8019632: Method parameters are not copied in clone_with_new_data Message-ID: <20130723153845.A9DC8482A2@hg.openjdk.java.net> Changeset: 16511b7e3d35 Author: emc Date: 2013-07-22 17:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 8019632: Method parameters are not copied in clone_with_new_data Summary: Add code to copy method parameters data in clone_with_new_data Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/method.cpp From daniel.daugherty at oracle.com Tue Jul 23 08:39:44 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 23 Jul 2013 15:39:44 +0000 Subject: hg: jdk8/tl/jdk: 8016838: improvement of RedefineBigClass and RetransformBigClass tests Message-ID: <20130723154031.60C6C482A3@hg.openjdk.java.net> Changeset: 6f3b940fe9f8 Author: igerasim Date: 2013-07-23 18:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f3b940fe9f8 8016838: improvement of RedefineBigClass and RetransformBigClass tests Reviewed-by: dcubed ! test/ProblemList.txt ! test/java/lang/instrument/RedefineBigClass.sh ! test/java/lang/instrument/RedefineBigClassApp.java ! test/java/lang/instrument/RetransformBigClass.sh ! test/java/lang/instrument/RetransformBigClassApp.java From jeremymanson at google.com Tue Jul 23 11:37:32 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 23 Jul 2013 11:37:32 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <0F64EB55-B38C-416E-93D1-92BA8F5D43C7@oracle.com> References: <51D494E9.2020200@oracle.com> <51DDB632.4050805@oracle.com> <0F64EB55-B38C-416E-93D1-92BA8F5D43C7@oracle.com> Message-ID: Okay, Bob, thanks for the explanation. I may not agree with it, but I can certainly see where you're coming from. Jeremy On Tue, Jul 16, 2013 at 2:44 PM, Bob Vandette wrote: > Thanks for the suggestion Jeremy but the JVMTI agent change is being > implemented as part of the > original JNI static library implementation where we explicitly prohibited > dynamic libraries to be loaded > if a static library of the same name is baked into the launcher. > > "If a library L is statically linked then it will be prohibited to link a > library of the same name dynamically." > > The primary motivation for requiring this for the -agentpath as well as > the java.lang.System.load API is to > minimize changes to java source code. You can statically or dynamically > link a library without changing > any of the code that attempts to use the library. The only thing that > changes is the OnLoad name in the library > and the link options. > > If you'd like to optionally use different implementations, you can end up > with the same behavior by using a > System property which alters the String of the name of the library. > > Bob. > > > On Jul 10, 2013, at 3:29 PM, BILL PITTORE wrote: > > On 7/3/2013 6:32 PM, Jeremy Manson wrote: > > I know that this is mentioned in the JEP, but does it really make sense to > have -agentpath work here, rather than just -agentlib? I would think that > specifying a full pathname and getting the library loaded out of the > launcher would be a little surprising to people who are basically saying > "please load this agent from the given path". > > > Also, in practice, we do something very similar at Google, and, when > testing, I find it occasionally useful to be able to say "please load this > agent on the command line via the agentpath I gave you, rather than loading > the one with the same name I baked into the launcher". > > > (FWIW, when we did this internally at Google, we added a special -XX flag > for when the agent is in the launcher. I know that you don't want to go > that way, though.) > > > Thanks for the comments. I would say the thinking here is that we want > this to be as transparent as possible to the end user. In our view of the > end user is someone perhaps using an IDE and the actual execution of the VM > with agent arguments is hidden. In your case it sounds like you are > actually developing agents which is a whole different ball game. I could > certainly see adding a -XX argument that forces agentpath to load the > external library which would be good for agent development and debugging. > No need to relink the entire VM with the new agent. Our tech lead is out on > vacation this week so I'll bring this up when he's back. > > bill > > > On Wed, Jul 3, 2013 at 2:17 PM, BILL PITTORE mailto:bill.pittore at oracle.com >> wrote: > > > These changes address bug 8014135 which adds support for > > statically linked agents in the VM. This is a followup to the > > recent JNI spec changes that addressed statically linked JNI > > libraries( 8005716). > > The JEP for this change is the same JEP as the JNI changes: > > http://openjdk.java.net/jeps/178 > > > Webrevs are here: > > > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ > > > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ > > > > > The changes to jvmti.xml can also be seen in the output file that > > I placed here: > > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html > > < > http://cr.openjdk.java.net/%7Ebpittore/8014135/hotspot/webrev.00/jvmti.html > > > > > Thanks, > > bill > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130723/7e908a87/attachment-0001.html From sundararajan.athijegannathan at oracle.com Tue Jul 23 11:15:19 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 23 Jul 2013 18:15:19 +0000 Subject: hg: jdk8/tl/nashorn: 10 new changesets Message-ID: <20130723181528.83B96482AE@hg.openjdk.java.net> Changeset: e1d19f9fd5a9 Author: jlaskey Date: 2013-07-16 17:40 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e1d19f9fd5a9 8017585: Exclude two failing tests from Nashorn CC run Reviewed-by: jlaskey, sundar, attila Contributed-by: konstantin.shefov at oracle.com + exclude/exclude_list.txt + exclude/exclude_list_cc.txt ! make/build.xml Changeset: 71cfe4e66bcb Author: jlaskey Date: 2013-07-17 11:53 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/71cfe4e66bcb 8020596: Initialization of white space strings in scanner should be done with \u strings Reviewed-by: attila, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/parser/Lexer.java Changeset: 3d6f6b8d8bc8 Author: hannesw Date: 2013-07-17 18:20 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3d6f6b8d8bc8 8020356: ClassCastException Undefined->Scope on spiltter class generated for a large switch statement Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Label.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java + test/script/basic/JDK-8020356.js + test/script/basic/JDK-8020356.js.EXPECTED Changeset: e3307f1a30e5 Author: sundar Date: 2013-07-18 18:08 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e3307f1a30e5 8020731: Revisit checkPermission calls in Context class Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java - src/jdk/nashorn/internal/runtime/linker/JavaAdapterGeneratorBase.java Changeset: 624f8be5c3fe Author: attila Date: 2013-07-18 16:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/624f8be5c3fe 8020809: Java adapter should not allow overriding of caller sensitive methods Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java + test/script/trusted/JDK-8020809.js + test/script/trusted/JDK-8020809.js.EXPECTED Changeset: 4b06441b7624 Author: attila Date: 2013-07-18 16:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4b06441b7624 8020820: Limit access to static members of reflective classes Reviewed-by: jlaskey, sundar ! make/build.xml ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! test/script/basic/JDK-8010946-2.js ! test/script/basic/JDK-8010946-2.js.EXPECTED ! test/script/basic/NASHORN-473.js + test/script/basic/classloader.js + test/script/basic/classloader.js.EXPECTED ! test/script/basic/javaarray.js ! test/script/sandbox/classloader.js.EXPECTED ! test/script/sandbox/reflection.js ! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java Changeset: 0cfa27ed82fe Author: sundar Date: 2013-07-23 18:17 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0cfa27ed82fe 8021122: Not all callables are handled for toString and other function valued properties Reviewed-by: attila, hannesw, jlaskey ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + test/script/basic/JDK-8021122.js + test/script/basic/JDK-8021122.js.EXPECTED Changeset: e86b297d26aa Author: jlaskey Date: 2013-07-23 12:00 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e86b297d26aa 8021130: Comments need to be tokens Reviewed-by: lagergren, attila Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/TokenType.java Changeset: ccbea9172aa5 Author: sundar Date: 2013-07-23 21:45 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ccbea9172aa5 8021164: REGRESSION: test262 failures after JDK-8021122 Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java Changeset: 4cb1780bc385 Author: sundar Date: 2013-07-23 21:51 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4cb1780bc385 Merge - src/jdk/nashorn/internal/runtime/linker/JavaAdapterGeneratorBase.java From mike.duigou at oracle.com Tue Jul 23 13:32:27 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 23 Jul 2013 20:32:27 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130723203305.B1E3C482BE@hg.openjdk.java.net> Changeset: 8156630c1ed3 Author: mduigou Date: 2013-07-23 13:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8156630c1ed3 8019840: Spec updates for java.util.function Reviewed-by: mduigou, chegar Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/util/function/BiConsumer.java ! src/share/classes/java/util/function/BiFunction.java ! src/share/classes/java/util/function/BiPredicate.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/BooleanSupplier.java ! src/share/classes/java/util/function/Consumer.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleConsumer.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoublePredicate.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleToIntFunction.java ! src/share/classes/java/util/function/DoubleToLongFunction.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntConsumer.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntPredicate.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntToDoubleFunction.java ! src/share/classes/java/util/function/IntToLongFunction.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongConsumer.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongPredicate.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongToDoubleFunction.java ! src/share/classes/java/util/function/LongToIntFunction.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/ObjDoubleConsumer.java ! src/share/classes/java/util/function/ObjIntConsumer.java ! src/share/classes/java/util/function/ObjLongConsumer.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/java/util/function/Supplier.java ! src/share/classes/java/util/function/ToDoubleBiFunction.java ! src/share/classes/java/util/function/ToDoubleFunction.java ! src/share/classes/java/util/function/ToIntBiFunction.java ! src/share/classes/java/util/function/ToIntFunction.java ! src/share/classes/java/util/function/ToLongBiFunction.java ! src/share/classes/java/util/function/ToLongFunction.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/function/package-info.java Changeset: 012996e9259f Author: mduigou Date: 2013-07-23 13:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/012996e9259f Merge From yumin.qi at oracle.com Tue Jul 23 16:00:26 2013 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Tue, 23 Jul 2013 23:00:26 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20130723230032.9ED92482C8@hg.openjdk.java.net> Changeset: 72727c4b6dec Author: ccheung Date: 2013-07-19 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/72727c4b6dec 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code Summary: Added -DLINUX to the gcc command and improved the .sh script Reviewed-by: dcubed, dholmes, minqi ! test/runtime/jsig/Test8017498.sh ! test/runtime/jsig/TestJNI.c Changeset: 5165d659cebd Author: minqi Date: 2013-07-22 22:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5165d659cebd Merge Changeset: c0f353803b47 Author: minqi Date: 2013-07-23 12:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c0f353803b47 Merge From jonathan.gibbons at oracle.com Tue Jul 23 16:06:37 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 23 Jul 2013 23:06:37 +0000 Subject: hg: jdk8/tl/langtools: 8021215: javac gives incorrect doclint warnings on normal package statements Message-ID: <20130723230640.439AB482C9@hg.openjdk.java.net> Changeset: 129751018061 Author: jjg Date: 2013-07-23 16:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/129751018061 8021215: javac gives incorrect doclint warnings on normal package statements Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! test/tools/doclint/packageTests/bad/Test.java + test/tools/doclint/packageTests/bad/Test.javac.out ! test/tools/doclint/packageTests/bad/Test.out ! test/tools/doclint/packageTests/bad/package-info.java + test/tools/doclint/packageTests/bad/package-info.javac.out ! test/tools/doclint/packageTests/bad/package-info.out ! test/tools/doclint/packageTests/good/Test.java ! test/tools/doclint/packageTests/good/package-info.java From eric.mccorkle at oracle.com Tue Jul 23 17:44:03 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Wed, 24 Jul 2013 00:44:03 +0000 Subject: hg: jdk8/tl/langtools: 8016880: 42 tests in annot102* fail with compile-time errors. Message-ID: <20130724004410.DD60C482CB@hg.openjdk.java.net> Changeset: 558fe98d1ac0 Author: emc Date: 2013-07-23 20:42 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/558fe98d1ac0 8016880: 42 tests in annot102* fail with compile-time errors. Summary: Fixes error in type equality when bounds of type variables have annotations. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/annotations/typeAnnotations/ErasureTest.java From mandy.chung at oracle.com Tue Jul 23 23:01:58 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 24 Jul 2013 14:01:58 +0800 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EE52B9.6070506@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> Message-ID: <51EF6DD6.5060806@oracle.com> On 7/23/2013 5:54 PM, David Holmes wrote: > On 23/07/2013 7:53 PM, Daniel Fuchs wrote: >> On 7/23/13 11:45 AM, David Holmes wrote: >>> On 23/07/2013 7:24 PM, Jaroslav Bachorik wrote: >>> > The result is that the offender is j.u.l.LogManager$Cleaner >>> thread. I >>> > am attaching the profiler snapshot (can be opened in eg. jvisualvm) >>> >>> That doesn't quite make sense. The Cleaner thread is a shutdownhook, it >>> should not be starting unless the VM is shutting down! >> >> Hummm... Right: the javadoc says "Returns the peak live thread count >> since the Java virtual machine started or peak was reset." so the >> Cleaner thread should not be counted. > > Not sure why you say that. It is a live Java thread - if you happen to > query the MXBean during VM shutdown then it should be in the count. > I am catching up on this thread.... The thread count counts Java threads that are not hidden. I believe all VM internal threads are hidden from external API. This test runs in othervm mode and AFAICT the thread count is expected to be deterministic. I don't expect the VM will start and terminate any thread any time. I agree with David that we should diagnose why there is one additional thread started before the reset. If it is the LogManager$Cleaner thread, like David said, the VM is shutting down while the test is still running which doesn't quite make sense. Mandy >> If it is actually counted it might indicate a real problem in the >> implementation of the ThreadMXBean. > > My point is: why is the VM apparently shutting down while this test is > running??? > > David > >> -- daniel. >> >> >>> >>> David >>> ----- >>> >>>> On Tue 23 Jul 2013 11:19:13 AM CEST, David Holmes wrote: >>>>> On 23/07/2013 6:29 PM, Jaroslav Bachorik wrote: >>>>>> On 07/23/2013 10:19 AM, David Holmes wrote: >>>>>>> Hi Jaroslav, >>>>>>> >>>>>>> On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote: >>>>>>>> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java >>>>>>>> test >>>>>>>> seems to be failing intermittently. >>>>>>>> >>>>>>>> The test checks the functionality of the >>>>>>>> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by >>>>>>>> capturing the current value of "getPeakThreadCount()", starting a >>>>>>>> predefined number of the user threads, stopping them and resetting >>>>>>>> the >>>>>>>> stored peak value and making sure the new peak equals to the >>>>>>>> number of >>>>>>>> the actually running threads. >>>>>>>> >>>>>>>> The main problem is that it is not possible to prevent JVM to >>>>>>>> start/stop >>>>>>>> arbitrary system threads while executing the test. This might >>>>>>>> lead to >>>>>>>> small variations of the reported peak (a short-lived system >>>>>>>> thread is >>>>>>>> started while the batch of the user threads is running) or the >>>>>>>> expected >>>>>>>> number of running threads (again, a short-lived system thread is >>>>>>>> started >>>>>>>> at the moment the test asks for the number of running threads). >>>>>>> >>>>>>> Do you know what "system threads" these are? I would not expect VM >>>>>>> internal threads to be counted in getPeakThreadCount(), but even if >>>>>>> they >>>>>>> are I can't think of any short-lived threads that get created other >>>>>>> than >>>>>>> the Signal handling thread. >>>>>> >>>>>> Unfortunatelly I don't. Capturing the thread dump at the moment of >>>>>> discovering the discrepancy seems to to be too late. I tried >>>>>> monitoring >>>>>> the JVM under the test from external tools but it just brings more >>>>>> entropy to the result. >>>>> >>>>> We'd need to instrument the thread creation logic to keep a separate >>>>> record. Dtrace probes could probably do it - but the problem is >>>>> getting the test to fail. >>>> >>>> Well, while responding to the previous email I thought about yet >>>> another way to try to pinpoint the mysterious thread - I've tried NB >>>> profiler. It filters out it's own threads and can do thread monitoring >>>> at the same time as tracking the call tree. >>>> >>>> The result is that the offender is j.u.l.LogManager$Cleaner thread. I >>>> am attaching the profiler snapshot (can be opened in eg. jvisualvm) >>>> >>>>> >>>>>> I am completely relying on the JVM native thread accounting to be >>>>>> correct and accurate - that it reports the thread count peak >>>>>> based on >>>>>> the real data. >>>>> >>>>> The spec isn't clear but I would only expect these counters to apply >>>>> to Java threads not VM internal threads (compiler, gc etc). So I'd >>>>> really like to know what thread is messing up this count. >>>> >>>> I hope my previous finding makes this clearer. >>>> >>>> -JB- >>>> >>>>> >>>>> David >>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>>> The patch does not fix those shortcomings as it is not really >>>>>>>> possible >>>>>>>> to do given the nature of the JVM threading system. It rather >>>>>>>> tries to >>>>>>>> relax the conditions while still maintaining the ability to detect >>>>>>>> functional problems - eg. decreasing peak without explicitly >>>>>>>> resetting >>>>>>>> it and reporting false number of threads. >>>>>>>> >>>>>>>> The webrev is at: >>>>>>>> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 >>>>>>> >>>>>>> Seems reasonable. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>> >>>> >> From daniel.fuchs at oracle.com Tue Jul 23 23:09:37 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 24 Jul 2013 08:09:37 +0200 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EF6DD6.5060806@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> Message-ID: <51EF6FA1.9000103@oracle.com> On 7/24/13 8:01 AM, Mandy Chung wrote: > On 7/23/2013 5:54 PM, David Holmes wrote: >> On 23/07/2013 7:53 PM, Daniel Fuchs wrote: >>> On 7/23/13 11:45 AM, David Holmes wrote: >>>> On 23/07/2013 7:24 PM, Jaroslav Bachorik wrote: >>>> > The result is that the offender is j.u.l.LogManager$Cleaner >>>> thread. I >>>> > am attaching the profiler snapshot (can be opened in eg. jvisualvm) >>>> >>>> That doesn't quite make sense. The Cleaner thread is a >>>> shutdownhook, it >>>> should not be starting unless the VM is shutting down! >>> >>> Hummm... Right: the javadoc says "Returns the peak live thread count >>> since the Java virtual machine started or peak was reset." so the >>> Cleaner thread should not be counted. >> >> Not sure why you say that. It is a live Java thread - if you happen >> to query the MXBean during VM shutdown then it should be in the count. >> > > I am catching up on this thread.... > > The thread count counts Java threads that are not hidden. I believe > all VM internal threads are hidden from external API. This test runs > in othervm mode and AFAICT the thread count is expected to be > deterministic. I don't expect the VM will start and terminate any > thread any time. > > I agree with David that we should diagnose why there is one additional > thread started before the reset. If it is the LogManager$Cleaner > thread, like David said, the VM is shutting down while the test is > still running which doesn't quite make sense. I think that Shanliang's suspicion that a thread might be still alive if unscheduled just after having called its barrier.signal() is a very good suggestion. I would advise calling thread.join() on all threads in terminateThreads, just to make sure they are all really dead and not in some comatose state... If Shanliang is right then the test would be failing because some of the threads we think are dead are not actually dead yet - and not because of some new VM thread that nobody can see :-) -- daniel > > Mandy > >>> If it is actually counted it might indicate a real problem in the >>> implementation of the ThreadMXBean. >> >> My point is: why is the VM apparently shutting down while this test >> is running??? >> >> David >> >>> -- daniel. >>> >>> >>>> >>>> David >>>> ----- >>>> >>>>> On Tue 23 Jul 2013 11:19:13 AM CEST, David Holmes wrote: >>>>>> On 23/07/2013 6:29 PM, Jaroslav Bachorik wrote: >>>>>>> On 07/23/2013 10:19 AM, David Holmes wrote: >>>>>>>> Hi Jaroslav, >>>>>>>> >>>>>>>> On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote: >>>>>>>>> The >>>>>>>>> java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test >>>>>>>>> seems to be failing intermittently. >>>>>>>>> >>>>>>>>> The test checks the functionality of the >>>>>>>>> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by >>>>>>>>> capturing the current value of "getPeakThreadCount()", starting a >>>>>>>>> predefined number of the user threads, stopping them and >>>>>>>>> resetting >>>>>>>>> the >>>>>>>>> stored peak value and making sure the new peak equals to the >>>>>>>>> number of >>>>>>>>> the actually running threads. >>>>>>>>> >>>>>>>>> The main problem is that it is not possible to prevent JVM to >>>>>>>>> start/stop >>>>>>>>> arbitrary system threads while executing the test. This might >>>>>>>>> lead to >>>>>>>>> small variations of the reported peak (a short-lived system >>>>>>>>> thread is >>>>>>>>> started while the batch of the user threads is running) or the >>>>>>>>> expected >>>>>>>>> number of running threads (again, a short-lived system thread is >>>>>>>>> started >>>>>>>>> at the moment the test asks for the number of running threads). >>>>>>>> >>>>>>>> Do you know what "system threads" these are? I would not expect VM >>>>>>>> internal threads to be counted in getPeakThreadCount(), but >>>>>>>> even if >>>>>>>> they >>>>>>>> are I can't think of any short-lived threads that get created >>>>>>>> other >>>>>>>> than >>>>>>>> the Signal handling thread. >>>>>>> >>>>>>> Unfortunatelly I don't. Capturing the thread dump at the moment of >>>>>>> discovering the discrepancy seems to to be too late. I tried >>>>>>> monitoring >>>>>>> the JVM under the test from external tools but it just brings more >>>>>>> entropy to the result. >>>>>> >>>>>> We'd need to instrument the thread creation logic to keep a separate >>>>>> record. Dtrace probes could probably do it - but the problem is >>>>>> getting the test to fail. >>>>> >>>>> Well, while responding to the previous email I thought about yet >>>>> another way to try to pinpoint the mysterious thread - I've tried NB >>>>> profiler. It filters out it's own threads and can do thread >>>>> monitoring >>>>> at the same time as tracking the call tree. >>>>> >>>>> The result is that the offender is j.u.l.LogManager$Cleaner thread. I >>>>> am attaching the profiler snapshot (can be opened in eg. jvisualvm) >>>>> >>>>>> >>>>>>> I am completely relying on the JVM native thread accounting to be >>>>>>> correct and accurate - that it reports the thread count peak >>>>>>> based on >>>>>>> the real data. >>>>>> >>>>>> The spec isn't clear but I would only expect these counters to apply >>>>>> to Java threads not VM internal threads (compiler, gc etc). So I'd >>>>>> really like to know what thread is messing up this count. >>>>> >>>>> I hope my previous finding makes this clearer. >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>>> The patch does not fix those shortcomings as it is not really >>>>>>>>> possible >>>>>>>>> to do given the nature of the JVM threading system. It rather >>>>>>>>> tries to >>>>>>>>> relax the conditions while still maintaining the ability to >>>>>>>>> detect >>>>>>>>> functional problems - eg. decreasing peak without explicitly >>>>>>>>> resetting >>>>>>>>> it and reporting false number of threads. >>>>>>>>> >>>>>>>>> The webrev is at: >>>>>>>>> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00 >>>>>>>> >>>>>>>> Seems reasonable. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>> >>>>> >>> > From jaroslav.bachorik at oracle.com Tue Jul 23 23:18:12 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 24 Jul 2013 08:18:12 +0200 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EF6DD6.5060806@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> Message-ID: <51EF71A4.3090209@oracle.com> Thanks everyone for taking the time to dig into this issue. I've done more testing and it turns out that my initial analysis was wrong. There are no threads magically appearing and disappearing (it was all caused by the monitoring tools I used). It rather seems that there is an issue with terminating the test threads - I've added a lot of logging to the original test and was able to observe that sometimes the new test threads were started before the terminating test threads have disappeared. So I've added more rigorous check for the threads termination - checking the thread states instead of just comparing the thread counts. By doing this I was able to decrease the chances of failing but it still seems that there is some discrepancy between the numbers reported by the mbean and eg. the result of Thread.getAllStackTraces(). I am logging all the threads reported by Thread.getAllStackTraces() before the call to mbean.getThreadCount() and after the call and sometimes it just happens that mbean.getThreadCount() reports the thread count which is off by 1 in regards to both Thread.getAllStackTraces() calls. I will try the "thread.join()" suggestion from Daniel. -JB- From mandy.chung at oracle.com Tue Jul 23 23:20:56 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 24 Jul 2013 14:20:56 +0800 Subject: RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EF6FA1.9000103@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> Message-ID: <51EF7248.2070405@oracle.com> On 7/24/2013 2:09 PM, Daniel Fuchs wrote: > On 7/24/13 8:01 AM, Mandy Chung wrote: >> I am catching up on this thread.... >> >> The thread count counts Java threads that are not hidden. I believe >> all VM internal threads are hidden from external API. This test runs >> in othervm mode and AFAICT the thread count is expected to be >> deterministic. I don't expect the VM will start and terminate any >> thread any time. >> >> I agree with David that we should diagnose why there is one >> additional thread started before the reset. If it is the >> LogManager$Cleaner thread, like David said, the VM is shutting down >> while the test is still running which doesn't quite make sense. > I think that Shanliang's suspicion that a thread might be still alive > if unscheduled just after having > called its barrier.signal() is a very good suggestion. I would advise > calling thread.join() on all threads in > terminateThreads, just to make sure they are all really dead and not > in some comatose state... > If Shanliang is right then the test would be failing because some of > the threads we think are dead are > not actually dead yet - and not because of some new VM thread that > nobody can see :-) Thanks for pointing that out. I agree that the test should be changed to call Thread.join(). There may be other java.lang.management tests that should also be fixed to call Thread.join. Mandy From jaroslav.bachorik at oracle.com Tue Jul 23 23:47:36 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 24 Jul 2013 08:47:36 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EF7248.2070405@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> Message-ID: <51EF7888.40100@oracle.com> On Wed 24 Jul 2013 08:20:56 AM CEST, Mandy Chung wrote: > > On 7/24/2013 2:09 PM, Daniel Fuchs wrote: >> On 7/24/13 8:01 AM, Mandy Chung wrote: >>> I am catching up on this thread.... >>> >>> The thread count counts Java threads that are not hidden. I believe >>> all VM internal threads are hidden from external API. This test runs >>> in othervm mode and AFAICT the thread count is expected to be >>> deterministic. I don't expect the VM will start and terminate any >>> thread any time. >>> >>> I agree with David that we should diagnose why there is one >>> additional thread started before the reset. If it is the >>> LogManager$Cleaner thread, like David said, the VM is shutting down >>> while the test is still running which doesn't quite make sense. >> I think that Shanliang's suspicion that a thread might be still alive >> if unscheduled just after having >> called its barrier.signal() is a very good suggestion. I would advise >> calling thread.join() on all threads in >> terminateThreads, just to make sure they are all really dead and not >> in some comatose state... >> If Shanliang is right then the test would be failing because some of >> the threads we think are dead are >> not actually dead yet - and not because of some new VM thread that >> nobody can see :-) > > Thanks for pointing that out. > > I agree that the test should be changed to call Thread.join(). There > may be other java.lang.management tests that should also be fixed to > call Thread.join. I've tried using Thread.join() but I am still getting the thread count discrepancy. Specifically: 1. 10 worker threads have been successfully started - mben.getThreadCount() reports 14 and Thread.getAllStackTraces() returns 14 items --- Thread: Thread[Signal Dispatcher,9,system] Thread: Thread[worker-5,5,main] Thread: Thread[worker-7,5,main] Thread: Thread[worker-9,5,main] Thread: Thread[worker-12,5,main] Thread: Thread[worker-11,5,main] Thread: Thread[Reference Handler,10,system] Thread: Thread[main,5,main] Thread: Thread[worker-10,5,main] Thread: Thread[worker-8,5,main] Thread: Thread[Finalizer,8,system] Thread: Thread[worker-6,5,main] Thread: Thread[worker-13,5,main] Thread: Thread[worker-4,5,main] --- 2. Terminating 8 threads 3. After the threads have been terminated (waiting on Thread.join() for them to die) - mbean.getThreadCount() reports 7 while Thread.getAllStackTraces() returns only 6 items --- Thread: Thread[Signal Dispatcher,9,system] Thread: Thread[Finalizer,8,system] Thread: Thread[worker-12,5,main] Thread: Thread[Reference Handler,10,system] Thread: Thread[main,5,main] Thread: Thread[worker-13,5,main] --- This would almost point to mbean.getThreadCount() reporting a stale value. Is that possible? -JB- > > Mandy From shanliang.jiang at oracle.com Wed Jul 24 00:21:53 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 24 Jul 2013 09:21:53 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EF7888.40100@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> Message-ID: <51EF8091.9030603@oracle.com> Just to be a test, after terminated 8 threads and checked their states by calling Thread.join() (must be same to Thread.getState()), DO sleep sometime and then call mbean.getThreadCount(), if it reports a right number, then we may need to verify mbean.getThreadCount() method. Shanliang Jaroslav Bachorik wrote: > On Wed 24 Jul 2013 08:20:56 AM CEST, Mandy Chung wrote: > >> On 7/24/2013 2:09 PM, Daniel Fuchs wrote: >> >>> On 7/24/13 8:01 AM, Mandy Chung wrote: >>> >>>> I am catching up on this thread.... >>>> >>>> The thread count counts Java threads that are not hidden. I believe >>>> all VM internal threads are hidden from external API. This test runs >>>> in othervm mode and AFAICT the thread count is expected to be >>>> deterministic. I don't expect the VM will start and terminate any >>>> thread any time. >>>> >>>> I agree with David that we should diagnose why there is one >>>> additional thread started before the reset. If it is the >>>> LogManager$Cleaner thread, like David said, the VM is shutting down >>>> while the test is still running which doesn't quite make sense. >>>> >>> I think that Shanliang's suspicion that a thread might be still alive >>> if unscheduled just after having >>> called its barrier.signal() is a very good suggestion. I would advise >>> calling thread.join() on all threads in >>> terminateThreads, just to make sure they are all really dead and not >>> in some comatose state... >>> If Shanliang is right then the test would be failing because some of >>> the threads we think are dead are >>> not actually dead yet - and not because of some new VM thread that >>> nobody can see :-) >>> >> Thanks for pointing that out. >> >> I agree that the test should be changed to call Thread.join(). There >> may be other java.lang.management tests that should also be fixed to >> call Thread.join. >> > > I've tried using Thread.join() but I am still getting the thread count > discrepancy. > > Specifically: > 1. 10 worker threads have been successfully started - > mben.getThreadCount() reports 14 and Thread.getAllStackTraces() returns > 14 items > --- > Thread: Thread[Signal Dispatcher,9,system] > Thread: Thread[worker-5,5,main] > Thread: Thread[worker-7,5,main] > Thread: Thread[worker-9,5,main] > Thread: Thread[worker-12,5,main] > Thread: Thread[worker-11,5,main] > Thread: Thread[Reference Handler,10,system] > Thread: Thread[main,5,main] > Thread: Thread[worker-10,5,main] > Thread: Thread[worker-8,5,main] > Thread: Thread[Finalizer,8,system] > Thread: Thread[worker-6,5,main] > Thread: Thread[worker-13,5,main] > Thread: Thread[worker-4,5,main] > --- > 2. Terminating 8 threads > 3. After the threads have been terminated (waiting on Thread.join() for > them to die) - mbean.getThreadCount() reports 7 while > Thread.getAllStackTraces() returns only 6 items > --- > Thread: Thread[Signal Dispatcher,9,system] > Thread: Thread[Finalizer,8,system] > Thread: Thread[worker-12,5,main] > Thread: Thread[Reference Handler,10,system] > Thread: Thread[main,5,main] > Thread: Thread[worker-13,5,main] > --- > > This would almost point to mbean.getThreadCount() reporting a stale > value. Is that possible? > > -JB- > > >> Mandy >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130724/6c50234a/attachment.html From jaroslav.bachorik at oracle.com Wed Jul 24 00:35:02 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 24 Jul 2013 09:35:02 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EF8091.9030603@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> Message-ID: <51EF83A6.1040200@oracle.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/24/2013 09:21 AM, shanliang wrote: > Just to be a test, after terminated 8 threads and checked their > states by calling Thread.join() (must be same to > Thread.getState()), DO sleep sometime and then call > mbean.getThreadCount(), if it reports a right number, then we may > need to verify mbean.getThreadCount() method. The result is: Thread: Thread[Signal Dispatcher,9,system] Thread: Thread[Finalizer,8,system] Thread: Thread[worker-12,5,main] Thread: Thread[Reference Handler,10,system] Thread: Thread[main,5,main] Thread: Thread[worker-13,5,main] - ---> MBean.getThreadCount() = 7 Thread(1): Thread[Signal Dispatcher,9,system] Thread(1): Thread[Finalizer,8,system] Thread(1): Thread[worker-12,5,main] Thread(1): Thread[Reference Handler,10,system] Thread(1): Thread[main,5,main] Thread(1): Thread[worker-13,5,main] - ---> MBean.getThreadCount() = 6 - -JB- > > Shanliang > > Jaroslav Bachorik wrote: >> On Wed 24 Jul 2013 08:20:56 AM CEST, Mandy Chung wrote: >> >>> On 7/24/2013 2:09 PM, Daniel Fuchs wrote: >>> >>>> On 7/24/13 8:01 AM, Mandy Chung wrote: >>>> >>>>> I am catching up on this thread.... >>>>> >>>>> The thread count counts Java threads that are not hidden. >>>>> I believe all VM internal threads are hidden from external >>>>> API. This test runs in othervm mode and AFAICT the thread >>>>> count is expected to be deterministic. I don't expect the >>>>> VM will start and terminate any thread any time. >>>>> >>>>> I agree with David that we should diagnose why there is >>>>> one additional thread started before the reset. If it is >>>>> the LogManager$Cleaner thread, like David said, the VM is >>>>> shutting down while the test is still running which doesn't >>>>> quite make sense. >>>>> >>>> I think that Shanliang's suspicion that a thread might be >>>> still alive if unscheduled just after having called its >>>> barrier.signal() is a very good suggestion. I would advise >>>> calling thread.join() on all threads in terminateThreads, >>>> just to make sure they are all really dead and not in some >>>> comatose state... If Shanliang is right then the test would >>>> be failing because some of the threads we think are dead are >>>> not actually dead yet - and not because of some new VM thread >>>> that nobody can see :-) >>>> >>> Thanks for pointing that out. >>> >>> I agree that the test should be changed to call Thread.join(). >>> There may be other java.lang.management tests that should also >>> be fixed to call Thread.join. >>> >> >> I've tried using Thread.join() but I am still getting the thread >> count discrepancy. >> >> Specifically: 1. 10 worker threads have been successfully started >> - mben.getThreadCount() reports 14 and >> Thread.getAllStackTraces() returns 14 items --- Thread: >> Thread[Signal Dispatcher,9,system] Thread: >> Thread[worker-5,5,main] Thread: Thread[worker-7,5,main] Thread: >> Thread[worker-9,5,main] Thread: Thread[worker-12,5,main] Thread: >> Thread[worker-11,5,main] Thread: Thread[Reference >> Handler,10,system] Thread: Thread[main,5,main] Thread: >> Thread[worker-10,5,main] Thread: Thread[worker-8,5,main] Thread: >> Thread[Finalizer,8,system] Thread: Thread[worker-6,5,main] >> Thread: Thread[worker-13,5,main] Thread: Thread[worker-4,5,main] >> --- 2. Terminating 8 threads 3. After the threads have been >> terminated (waiting on Thread.join() for them to die) - >> mbean.getThreadCount() reports 7 while Thread.getAllStackTraces() >> returns only 6 items --- Thread: Thread[Signal >> Dispatcher,9,system] Thread: Thread[Finalizer,8,system] Thread: >> Thread[worker-12,5,main] Thread: Thread[Reference >> Handler,10,system] Thread: Thread[main,5,main] Thread: >> Thread[worker-13,5,main] --- >> >> This would almost point to mbean.getThreadCount() reporting a >> stale value. Is that possible? >> >> -JB- >> >> >>> Mandy >>> >> >> >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR74OmAAoJELSZyqhGiB1M4k8H/2hM5o2vVe2lfhc374IBaR5R R8i9Z2n0prBRKIqg4bTkAcllq5pmdozxwFyaEBzJtAGh9vnL7Tmojn6ksg9K+MMl bSgWSeg+gSZyymS7aE8rTVqKigH8vNOpHOogePDrUOCZGeZgJIMpmY1QcVbLeq8k mkz5mPYxEE2E7gt8cjvcXknOWeQUTyZILWGIPBfx9FL0iwBtK5h0PnfasR7bCxcR DO48USIuTxe+aN687OkAlJq9bCR6HRzWQiaSdi4ROVyrx2xYtir4n9sZtNWJwokv 3p5TdX6S64jnVZZMjbPJgCENTYMvTeRCj/8GvCYlI9KQEa9x2zhU2wIp5Zw4ag4= =4vkV -----END PGP SIGNATURE----- From yumin.qi at oracle.com Wed Jul 24 01:26:08 2013 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Wed, 24 Jul 2013 08:26:08 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130724082615.64355482DC@hg.openjdk.java.net> Changeset: 1b6395189726 Author: minqi Date: 2013-07-19 14:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1b6395189726 8012263: ciReplay: gracefully exit & report meaningful error when replay data parsing fails Summary: find_method could return NULL so need explicitly check if there is error after parse_method, exit on error to avoid crash. Reviewed-by: kvn, twisti Contributed-by: yumin.qi at oracle.com ! src/share/vm/ci/ciReplay.cpp Changeset: 5ad7f8179bf7 Author: minqi Date: 2013-07-24 08:04 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5ad7f8179bf7 Merge From shanliang.jiang at oracle.com Wed Jul 24 01:38:02 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 24 Jul 2013 10:38:02 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EF83A6.1040200@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> Message-ID: <51EF926A.3060705@oracle.com> - ---> MBean.getThreadCount() = 7 ................ - ---> MBean.getThreadCount() = 6 I suppose that you added sleep between 2 calls, then there might be an issue with MBean.getThreadCount() Shanliang Jaroslav Bachorik wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/24/2013 09:21 AM, shanliang wrote: > >> Just to be a test, after terminated 8 threads and checked their >> states by calling Thread.join() (must be same to >> Thread.getState()), DO sleep sometime and then call >> mbean.getThreadCount(), if it reports a right number, then we may >> need to verify mbean.getThreadCount() method. >> > > The result is: > > Thread: Thread[Signal Dispatcher,9,system] > Thread: Thread[Finalizer,8,system] > Thread: Thread[worker-12,5,main] > Thread: Thread[Reference Handler,10,system] > Thread: Thread[main,5,main] > Thread: Thread[worker-13,5,main] > - ---> MBean.getThreadCount() = 7 > Thread(1): Thread[Signal Dispatcher,9,system] > Thread(1): Thread[Finalizer,8,system] > Thread(1): Thread[worker-12,5,main] > Thread(1): Thread[Reference Handler,10,system] > Thread(1): Thread[main,5,main] > Thread(1): Thread[worker-13,5,main] > - ---> MBean.getThreadCount() = 6 > > - -JB- > > > >> Shanliang >> >> Jaroslav Bachorik wrote: >> >>> On Wed 24 Jul 2013 08:20:56 AM CEST, Mandy Chung wrote: >>> >>> >>>> On 7/24/2013 2:09 PM, Daniel Fuchs wrote: >>>> >>>> >>>>> On 7/24/13 8:01 AM, Mandy Chung wrote: >>>>> >>>>> >>>>>> I am catching up on this thread.... >>>>>> >>>>>> The thread count counts Java threads that are not hidden. >>>>>> I believe all VM internal threads are hidden from external >>>>>> API. This test runs in othervm mode and AFAICT the thread >>>>>> count is expected to be deterministic. I don't expect the >>>>>> VM will start and terminate any thread any time. >>>>>> >>>>>> I agree with David that we should diagnose why there is >>>>>> one additional thread started before the reset. If it is >>>>>> the LogManager$Cleaner thread, like David said, the VM is >>>>>> shutting down while the test is still running which doesn't >>>>>> quite make sense. >>>>>> >>>>>> >>>>> I think that Shanliang's suspicion that a thread might be >>>>> still alive if unscheduled just after having called its >>>>> barrier.signal() is a very good suggestion. I would advise >>>>> calling thread.join() on all threads in terminateThreads, >>>>> just to make sure they are all really dead and not in some >>>>> comatose state... If Shanliang is right then the test would >>>>> be failing because some of the threads we think are dead are >>>>> not actually dead yet - and not because of some new VM thread >>>>> that nobody can see :-) >>>>> >>>>> >>>> Thanks for pointing that out. >>>> >>>> I agree that the test should be changed to call Thread.join(). >>>> There may be other java.lang.management tests that should also >>>> be fixed to call Thread.join. >>>> >>>> >>> I've tried using Thread.join() but I am still getting the thread >>> count discrepancy. >>> >>> Specifically: 1. 10 worker threads have been successfully started >>> - mben.getThreadCount() reports 14 and >>> Thread.getAllStackTraces() returns 14 items --- Thread: >>> Thread[Signal Dispatcher,9,system] Thread: >>> Thread[worker-5,5,main] Thread: Thread[worker-7,5,main] Thread: >>> Thread[worker-9,5,main] Thread: Thread[worker-12,5,main] Thread: >>> Thread[worker-11,5,main] Thread: Thread[Reference >>> Handler,10,system] Thread: Thread[main,5,main] Thread: >>> Thread[worker-10,5,main] Thread: Thread[worker-8,5,main] Thread: >>> Thread[Finalizer,8,system] Thread: Thread[worker-6,5,main] >>> Thread: Thread[worker-13,5,main] Thread: Thread[worker-4,5,main] >>> --- 2. Terminating 8 threads 3. After the threads have been >>> terminated (waiting on Thread.join() for them to die) - >>> mbean.getThreadCount() reports 7 while Thread.getAllStackTraces() >>> returns only 6 items --- Thread: Thread[Signal >>> Dispatcher,9,system] Thread: Thread[Finalizer,8,system] Thread: >>> Thread[worker-12,5,main] Thread: Thread[Reference >>> Handler,10,system] Thread: Thread[main,5,main] Thread: >>> Thread[worker-13,5,main] --- >>> >>> This would almost point to mbean.getThreadCount() reporting a >>> stale value. Is that possible? >>> >>> -JB- >>> >>> >>> >>>> Mandy >>>> >>>> >>> >>> >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJR74OmAAoJELSZyqhGiB1M4k8H/2hM5o2vVe2lfhc374IBaR5R > R8i9Z2n0prBRKIqg4bTkAcllq5pmdozxwFyaEBzJtAGh9vnL7Tmojn6ksg9K+MMl > bSgWSeg+gSZyymS7aE8rTVqKigH8vNOpHOogePDrUOCZGeZgJIMpmY1QcVbLeq8k > mkz5mPYxEE2E7gt8cjvcXknOWeQUTyZILWGIPBfx9FL0iwBtK5h0PnfasR7bCxcR > DO48USIuTxe+aN687OkAlJq9bCR6HRzWQiaSdi4ROVyrx2xYtir4n9sZtNWJwokv > 3p5TdX6S64jnVZZMjbPJgCENTYMvTeRCj/8GvCYlI9KQEa9x2zhU2wIp5Zw4ag4= > =4vkV > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130724/723980f5/attachment.html From jaroslav.bachorik at oracle.com Wed Jul 24 01:40:46 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 24 Jul 2013 10:40:46 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EF926A.3060705@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> Message-ID: <51EF930E.4050507@oracle.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/24/2013 10:38 AM, shanliang wrote: > - ---> MBean.getThreadCount() = 7 > > ................ > > - ---> MBean.getThreadCount() = 6 > > I suppose that you added sleep between 2 calls, then there might be > an issue with MBean.getThreadCount() Actually I tried it with sleep for 10ms as well as without. It seems that the natural latency between those 2 calls is enough to get the thread count updated to the actual value. - -JB- > > Shanliang > > Jaroslav Bachorik wrote: On 07/24/2013 09:21 AM, shanliang wrote: > >>>> Just to be a test, after terminated 8 threads and checked >>>> their states by calling Thread.join() (must be same to >>>> Thread.getState()), DO sleep sometime and then call >>>> mbean.getThreadCount(), if it reports a right number, then we >>>> may need to verify mbean.getThreadCount() method. >>>> > > The result is: > > Thread: Thread[Signal Dispatcher,9,system] Thread: > Thread[Finalizer,8,system] Thread: Thread[worker-12,5,main] Thread: > Thread[Reference Handler,10,system] Thread: Thread[main,5,main] > Thread: Thread[worker-13,5,main] ---> MBean.getThreadCount() = 7 > Thread(1): Thread[Signal Dispatcher,9,system] Thread(1): > Thread[Finalizer,8,system] Thread(1): Thread[worker-12,5,main] > Thread(1): Thread[Reference Handler,10,system] Thread(1): > Thread[main,5,main] Thread(1): Thread[worker-13,5,main] ---> > MBean.getThreadCount() = 6 > > -JB- > > > >>>> Shanliang >>>> >>>> Jaroslav Bachorik wrote: >>>> >>>>> On Wed 24 Jul 2013 08:20:56 AM CEST, Mandy Chung wrote: >>>>> >>>>> >>>>>> On 7/24/2013 2:09 PM, Daniel Fuchs wrote: >>>>>> >>>>>> >>>>>>> On 7/24/13 8:01 AM, Mandy Chung wrote: >>>>>>> >>>>>>> >>>>>>>> I am catching up on this thread.... >>>>>>>> >>>>>>>> The thread count counts Java threads that are not >>>>>>>> hidden. I believe all VM internal threads are hidden >>>>>>>> from external API. This test runs in othervm mode and >>>>>>>> AFAICT the thread count is expected to be >>>>>>>> deterministic. I don't expect the VM will start and >>>>>>>> terminate any thread any time. >>>>>>>> >>>>>>>> I agree with David that we should diagnose why there >>>>>>>> is one additional thread started before the reset. >>>>>>>> If it is the LogManager$Cleaner thread, like David >>>>>>>> said, the VM is shutting down while the test is still >>>>>>>> running which doesn't quite make sense. >>>>>>>> >>>>>>>> >>>>>>> I think that Shanliang's suspicion that a thread might >>>>>>> be still alive if unscheduled just after having called >>>>>>> its barrier.signal() is a very good suggestion. I would >>>>>>> advise calling thread.join() on all threads in >>>>>>> terminateThreads, just to make sure they are all really >>>>>>> dead and not in some comatose state... If Shanliang is >>>>>>> right then the test would be failing because some of >>>>>>> the threads we think are dead are not actually dead yet >>>>>>> - and not because of some new VM thread that nobody can >>>>>>> see :-) >>>>>>> >>>>>>> >>>>>> Thanks for pointing that out. >>>>>> >>>>>> I agree that the test should be changed to call >>>>>> Thread.join(). There may be other java.lang.management >>>>>> tests that should also be fixed to call Thread.join. >>>>>> >>>>>> >>>>> I've tried using Thread.join() but I am still getting the >>>>> thread count discrepancy. >>>>> >>>>> Specifically: 1. 10 worker threads have been successfully >>>>> started - mben.getThreadCount() reports 14 and >>>>> Thread.getAllStackTraces() returns 14 items --- Thread: >>>>> Thread[Signal Dispatcher,9,system] Thread: >>>>> Thread[worker-5,5,main] Thread: Thread[worker-7,5,main] >>>>> Thread: Thread[worker-9,5,main] Thread: >>>>> Thread[worker-12,5,main] Thread: Thread[worker-11,5,main] >>>>> Thread: Thread[Reference Handler,10,system] Thread: >>>>> Thread[main,5,main] Thread: Thread[worker-10,5,main] >>>>> Thread: Thread[worker-8,5,main] Thread: >>>>> Thread[Finalizer,8,system] Thread: Thread[worker-6,5,main] >>>>> Thread: Thread[worker-13,5,main] Thread: >>>>> Thread[worker-4,5,main] --- 2. Terminating 8 threads 3. >>>>> After the threads have been terminated (waiting on >>>>> Thread.join() for them to die) - mbean.getThreadCount() >>>>> reports 7 while Thread.getAllStackTraces() returns only 6 >>>>> items --- Thread: Thread[Signal Dispatcher,9,system] >>>>> Thread: Thread[Finalizer,8,system] Thread: >>>>> Thread[worker-12,5,main] Thread: Thread[Reference >>>>> Handler,10,system] Thread: Thread[main,5,main] Thread: >>>>> Thread[worker-13,5,main] --- >>>>> >>>>> This would almost point to mbean.getThreadCount() reporting >>>>> a stale value. Is that possible? >>>>> >>>>> -JB- >>>>> >>>>> >>>>> >>>>>> Mandy >>>>>> >>>>>> >>>>> >>>>> >>>> > >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR75MOAAoJELSZyqhGiB1M1CgIAKcMQMTZlZqM6qFsI5nCc53Y fHEFykf4792Qh/TgqDiyNbDCiTgY0TWoChUEJJEQvlho01TpJmKbkyqx5fNoNqjO l94p073f4GsUSHR4exGmDjJkg87DCzhbhX3bZdwjfsxJHxup8qrXxpz4c5lyBHDH ttoSasrcDIUh7cRoeqY7uWkIcnc8xI1cj7p3JlPUwB251eKzh15GZgMJhNKrn9N2 nhjpGywh3t/kwcsDVCibgBBOJ4ju55PRDZTyxH2R6o4fM+Twl80nZSaxUJiPUfEe yDNFUxMfPcNH+jRAhRlmKRZtfHfYV/nwaj/eqCL8CDtluzVR+lraII81pg7OU+c= =lqyg -----END PGP SIGNATURE----- From shanliang.jiang at oracle.com Wed Jul 24 01:50:26 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 24 Jul 2013 10:50:26 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EF930E.4050507@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> <51EF930E.4050507@oracle.com> Message-ID: <51EF9552.1020901@oracle.com> Jaroslav Bachorik wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/24/2013 10:38 AM, shanliang wrote: > >> - ---> MBean.getThreadCount() = 7 >> >> ................ >> >> - ---> MBean.getThreadCount() = 6 >> >> I suppose that you added sleep between 2 calls, then there might be >> an issue with MBean.getThreadCount() >> > > Actually I tried it with sleep for 10ms as well as without. It seems > that the natural latency between those 2 calls is enough to get the > thread count updated to the actual value. > So we have 2 kinds of issues here: 1) the test related, like Thread state checking, we can fix them in the test 2) MBean.getThreadCount() issue, we can create a bug to trace it (add your test case to the bug), and add a workaround (sleep or call 2 times) in the test to make the test pass. Mandy is the expert and better to get her opinion. Shanliang > - -JB- > > >> Shanliang >> >> Jaroslav Bachorik wrote: On 07/24/2013 09:21 AM, shanliang wrote: >> >> >>>>> Just to be a test, after terminated 8 threads and checked >>>>> their states by calling Thread.join() (must be same to >>>>> Thread.getState()), DO sleep sometime and then call >>>>> mbean.getThreadCount(), if it reports a right number, then we >>>>> may need to verify mbean.getThreadCount() method. >>>>> >>>>> >> The result is: >> >> Thread: Thread[Signal Dispatcher,9,system] Thread: >> Thread[Finalizer,8,system] Thread: Thread[worker-12,5,main] Thread: >> Thread[Reference Handler,10,system] Thread: Thread[main,5,main] >> Thread: Thread[worker-13,5,main] ---> MBean.getThreadCount() = 7 >> Thread(1): Thread[Signal Dispatcher,9,system] Thread(1): >> Thread[Finalizer,8,system] Thread(1): Thread[worker-12,5,main] >> Thread(1): Thread[Reference Handler,10,system] Thread(1): >> Thread[main,5,main] Thread(1): Thread[worker-13,5,main] ---> >> MBean.getThreadCount() = 6 >> >> -JB- >> >> >> >> >>>>> Shanliang >>>>> >>>>> Jaroslav Bachorik wrote: >>>>> >>>>> >>>>>> On Wed 24 Jul 2013 08:20:56 AM CEST, Mandy Chung wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 7/24/2013 2:09 PM, Daniel Fuchs wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 7/24/13 8:01 AM, Mandy Chung wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> I am catching up on this thread.... >>>>>>>>> >>>>>>>>> The thread count counts Java threads that are not >>>>>>>>> hidden. I believe all VM internal threads are hidden >>>>>>>>> from external API. This test runs in othervm mode and >>>>>>>>> AFAICT the thread count is expected to be >>>>>>>>> deterministic. I don't expect the VM will start and >>>>>>>>> terminate any thread any time. >>>>>>>>> >>>>>>>>> I agree with David that we should diagnose why there >>>>>>>>> is one additional thread started before the reset. >>>>>>>>> If it is the LogManager$Cleaner thread, like David >>>>>>>>> said, the VM is shutting down while the test is still >>>>>>>>> running which doesn't quite make sense. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> I think that Shanliang's suspicion that a thread might >>>>>>>> be still alive if unscheduled just after having called >>>>>>>> its barrier.signal() is a very good suggestion. I would >>>>>>>> advise calling thread.join() on all threads in >>>>>>>> terminateThreads, just to make sure they are all really >>>>>>>> dead and not in some comatose state... If Shanliang is >>>>>>>> right then the test would be failing because some of >>>>>>>> the threads we think are dead are not actually dead yet >>>>>>>> - and not because of some new VM thread that nobody can >>>>>>>> see :-) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Thanks for pointing that out. >>>>>>> >>>>>>> I agree that the test should be changed to call >>>>>>> Thread.join(). There may be other java.lang.management >>>>>>> tests that should also be fixed to call Thread.join. >>>>>>> >>>>>>> >>>>>>> >>>>>> I've tried using Thread.join() but I am still getting the >>>>>> thread count discrepancy. >>>>>> >>>>>> Specifically: 1. 10 worker threads have been successfully >>>>>> started - mben.getThreadCount() reports 14 and >>>>>> Thread.getAllStackTraces() returns 14 items --- Thread: >>>>>> Thread[Signal Dispatcher,9,system] Thread: >>>>>> Thread[worker-5,5,main] Thread: Thread[worker-7,5,main] >>>>>> Thread: Thread[worker-9,5,main] Thread: >>>>>> Thread[worker-12,5,main] Thread: Thread[worker-11,5,main] >>>>>> Thread: Thread[Reference Handler,10,system] Thread: >>>>>> Thread[main,5,main] Thread: Thread[worker-10,5,main] >>>>>> Thread: Thread[worker-8,5,main] Thread: >>>>>> Thread[Finalizer,8,system] Thread: Thread[worker-6,5,main] >>>>>> Thread: Thread[worker-13,5,main] Thread: >>>>>> Thread[worker-4,5,main] --- 2. Terminating 8 threads 3. >>>>>> After the threads have been terminated (waiting on >>>>>> Thread.join() for them to die) - mbean.getThreadCount() >>>>>> reports 7 while Thread.getAllStackTraces() returns only 6 >>>>>> items --- Thread: Thread[Signal Dispatcher,9,system] >>>>>> Thread: Thread[Finalizer,8,system] Thread: >>>>>> Thread[worker-12,5,main] Thread: Thread[Reference >>>>>> Handler,10,system] Thread: Thread[main,5,main] Thread: >>>>>> Thread[worker-13,5,main] --- >>>>>> >>>>>> This would almost point to mbean.getThreadCount() reporting >>>>>> a stale value. Is that possible? >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Mandy >>>>>>> >>>>>>> >>>>>>> >>>>>> >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJR75MOAAoJELSZyqhGiB1M1CgIAKcMQMTZlZqM6qFsI5nCc53Y > fHEFykf4792Qh/TgqDiyNbDCiTgY0TWoChUEJJEQvlho01TpJmKbkyqx5fNoNqjO > l94p073f4GsUSHR4exGmDjJkg87DCzhbhX3bZdwjfsxJHxup8qrXxpz4c5lyBHDH > ttoSasrcDIUh7cRoeqY7uWkIcnc8xI1cj7p3JlPUwB251eKzh15GZgMJhNKrn9N2 > nhjpGywh3t/kwcsDVCibgBBOJ4ju55PRDZTyxH2R6o4fM+Twl80nZSaxUJiPUfEe > yDNFUxMfPcNH+jRAhRlmKRZtfHfYV/nwaj/eqCL8CDtluzVR+lraII81pg7OU+c= > =lqyg > -----END PGP SIGNATURE----- > From mandy.chung at oracle.com Wed Jul 24 02:31:57 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 24 Jul 2013 17:31:57 +0800 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EF9552.1020901@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> <51EF930E.4050507@oracle.com> <51EF9552.1020901@oracle.com> Message-ID: <51EF9F0D.7040709@oracle.com> On 7/24/2013 4:50 PM, shanliang wrote: > So we have 2 kinds of issues here: > 1) the test related, like Thread state checking, we can fix them in > the test > 2) MBean.getThreadCount() issue, we can create a bug to trace it (add > your test case to the bug), and add a workaround (sleep or call 2 > times) in the test to make the test pass. Mandy is the expert and > better to get her opinion. It's probably a race in the VM implementation in determining the thread count. You will need to diagnose the VM implementation and compare the thread list and the implementation of getting the thread count (check hotspot/src/share/vm/services/threadService.cpp) Mandy From david.holmes at oracle.com Wed Jul 24 04:21:27 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jul 2013 21:21:27 +1000 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EF9F0D.7040709@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> <51EF930E.4050507@oracle.com> <51EF9552.1020901@oracle.com> <51EF9F0D.7040709@oracle.com> Message-ID: <51EFB8B7.6030204@oracle.com> On 24/07/2013 7:31 PM, Mandy Chung wrote: > > On 7/24/2013 4:50 PM, shanliang wrote: >> So we have 2 kinds of issues here: >> 1) the test related, like Thread state checking, we can fix them in >> the test >> 2) MBean.getThreadCount() issue, we can create a bug to trace it (add >> your test case to the bug), and add a workaround (sleep or call 2 >> times) in the test to make the test pass. Mandy is the expert and >> better to get her opinion. > > It's probably a race in the VM implementation in determining the thread > count. You will need to diagnose the VM implementation and compare the > thread list and the implementation of getting the thread count (check > hotspot/src/share/vm/services/threadService.cpp) There is a considerable code path between the point where a terminating thread causes Thread.join() to be allowed to return, and the point where the live thread count gets decremented. So using join() does not help here. Arguably JVMTI should have based its counts around the lifecycle of the Java thread not the underlying native thread. David ----- > Mandy From jaroslav.bachorik at oracle.com Wed Jul 24 04:50:59 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 24 Jul 2013 13:50:59 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EFB8B7.6030204@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> <51EF930E.4050507@oracle.com> <51EF9552.1020901@oracle.com> <51EF9F0D.7040709@oracle.com> <51EFB8B7.6030204@oracle.com> Message-ID: <51EFBFA3.90608@oracle.com> On 07/24/2013 01:21 PM, David Holmes wrote: > On 24/07/2013 7:31 PM, Mandy Chung wrote: >> >> On 7/24/2013 4:50 PM, shanliang wrote: >>> So we have 2 kinds of issues here: >>> 1) the test related, like Thread state checking, we can fix them in >>> the test >>> 2) MBean.getThreadCount() issue, we can create a bug to trace it (add >>> your test case to the bug), and add a workaround (sleep or call 2 >>> times) in the test to make the test pass. Mandy is the expert and >>> better to get her opinion. >> >> It's probably a race in the VM implementation in determining the thread >> count. You will need to diagnose the VM implementation and compare the >> thread list and the implementation of getting the thread count (check >> hotspot/src/share/vm/services/threadService.cpp) > > There is a considerable code path between the point where a terminating > thread causes Thread.join() to be allowed to return, and the point where > the live thread count gets decremented. So using join() does not help > here. Arguably JVMTI should have based its counts around the lifecycle > of the Java thread not the underlying native thread. So, if I understand it correctly, it is not possible to get 100% accuracy of the thread related counters in situations when you create and terminate a number of threads rapidly. In that case this test could be fixed with a small waiting period after all the joined threads were terminated - just to make sure that all the exiting threads were properly collected. The only question remains whether a bug should be filed for the discrepancy between the thread counters obtained from ThreadMXBean and the ones coming from different paths. -JB- > > David > ----- > >> Mandy From david.holmes at oracle.com Wed Jul 24 04:58:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jul 2013 21:58:32 +1000 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EFBFA3.90608@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> <51EF930E.4050507@oracle.com> <51EF9552.1020901@oracle.com> <51EF9F0D.7040709@oracle.com> <51EFB8B7.6030204@oracle.com> <51EFBFA3.90608@oracle.com> Message-ID: <51EFC168.6030205@oracle.com> Aside: it is really annoying that jmx-dev mangles the subject such that cross-posts end up creating two different email threads :( On 24/07/2013 9:50 PM, Jaroslav Bachorik wrote: > On 07/24/2013 01:21 PM, David Holmes wrote: >> On 24/07/2013 7:31 PM, Mandy Chung wrote: >>> >>> On 7/24/2013 4:50 PM, shanliang wrote: >>>> So we have 2 kinds of issues here: >>>> 1) the test related, like Thread state checking, we can fix them in >>>> the test >>>> 2) MBean.getThreadCount() issue, we can create a bug to trace it (add >>>> your test case to the bug), and add a workaround (sleep or call 2 >>>> times) in the test to make the test pass. Mandy is the expert and >>>> better to get her opinion. >>> >>> It's probably a race in the VM implementation in determining the thread >>> count. You will need to diagnose the VM implementation and compare the >>> thread list and the implementation of getting the thread count (check >>> hotspot/src/share/vm/services/threadService.cpp) >> >> There is a considerable code path between the point where a terminating >> thread causes Thread.join() to be allowed to return, and the point where >> the live thread count gets decremented. So using join() does not help >> here. Arguably JVMTI should have based its counts around the lifecycle >> of the Java thread not the underlying native thread. > > So, if I understand it correctly, it is not possible to get 100% > accuracy of the thread related counters in situations when you create > and terminate a number of threads rapidly. Correct. > In that case this test could be fixed with a small waiting period after > all the joined threads were terminated - just to make sure that all the > exiting threads were properly collected. Yes. > The only question remains whether a bug should be filed for the > discrepancy between the thread counters obtained from ThreadMXBean and > the ones coming from different paths. I'm unclear what the "different paths" are. David ----- > -JB- > >> >> David >> ----- >> >>> Mandy > From david.holmes at oracle.com Wed Jul 24 05:00:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jul 2013 22:00:13 +1000 Subject: RR(XS) 8019396: SA-JDI: OSThread class initialization throws an exception In-Reply-To: <51EE6B0A.3000903@oracle.com> References: <51EE4F34.5030805@oracle.com> <51EE5B83.7050305@oracle.com> <51EE6B0A.3000903@oracle.com> Message-ID: <51EFC1CD.1070303@oracle.com> On 23/07/2013 9:37 PM, Mikael Gerdin wrote: > David, > > On 2013-07-23 12:31, David Holmes wrote: >> Hi Dmitry, >> >> Looks okay. >> >> Minor nit: >> >> ! return (int)threadIdField.getJInt(addr); >> >> The cast should not be need as getJInt returns int. >> >> Aside: this looks like a major bug in BasicField to me: >> >> public long getJLong(Address addr) ... >> >> A jlong is 64-bits but a long may be 32-bits! > > But isn't that a Java land "long"? That's the definition of jlong :) Oops! That Java code sure looked like C code :) Thanks, David /Mikael > >> >> David >> >> On 23/07/2013 7:39 PM, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please, review the fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8019396.SA-JDI/webrev.01/ >>> >>> >>> Method sun.jvm.hotspot.runtime.OSThread.initialize throws a >>> sun.jvm.hotspot.types.WrongTypeException with message: field >>> "_thread_id" in type OSThread is not of type jint, but instead of type >>> unsigned OSThread::thread_id_t. >>> >>> After fixing an exception test still fails, because of wrong value used >>> for JVMTI_THREAD_STATE_WAITING, fixed it as well. >>> >>> Testing: >>> >>> nsk/sajdi/ThreadReference/status/status002 >>> >>> -Dmitry >>> From jaroslav.bachorik at oracle.com Wed Jul 24 05:02:13 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 24 Jul 2013 14:02:13 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EFC168.6030205@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> <51EF930E.4050507@oracle.com> <51EF9552.1020901@oracle.com> <51EF9F0D.7040709@oracle.com> <51EFB8B7.6030204@oracle.com> <51EFBFA3.90608@oracle.com> <51EFC168.6030205@oracle.com> Message-ID: <51EFC245.7070805@oracle.com> On 07/24/2013 01:58 PM, David Holmes wrote: > Aside: it is really annoying that jmx-dev mangles the subject such that > cross-posts end up creating two different email threads :( > > On 24/07/2013 9:50 PM, Jaroslav Bachorik wrote: >> On 07/24/2013 01:21 PM, David Holmes wrote: >>> On 24/07/2013 7:31 PM, Mandy Chung wrote: >>>> >>>> On 7/24/2013 4:50 PM, shanliang wrote: >>>>> So we have 2 kinds of issues here: >>>>> 1) the test related, like Thread state checking, we can fix them in >>>>> the test >>>>> 2) MBean.getThreadCount() issue, we can create a bug to trace it (add >>>>> your test case to the bug), and add a workaround (sleep or call 2 >>>>> times) in the test to make the test pass. Mandy is the expert and >>>>> better to get her opinion. >>>> >>>> It's probably a race in the VM implementation in determining the thread >>>> count. You will need to diagnose the VM implementation and compare >>>> the >>>> thread list and the implementation of getting the thread count (check >>>> hotspot/src/share/vm/services/threadService.cpp) >>> >>> There is a considerable code path between the point where a terminating >>> thread causes Thread.join() to be allowed to return, and the point where >>> the live thread count gets decremented. So using join() does not help >>> here. Arguably JVMTI should have based its counts around the lifecycle >>> of the Java thread not the underlying native thread. >> >> So, if I understand it correctly, it is not possible to get 100% >> accuracy of the thread related counters in situations when you create >> and terminate a number of threads rapidly. > > Correct. > >> In that case this test could be fixed with a small waiting period after >> all the joined threads were terminated - just to make sure that all the >> exiting threads were properly collected. > > Yes. > >> The only question remains whether a bug should be filed for the >> discrepancy between the thread counters obtained from ThreadMXBean and >> the ones coming from different paths. > > I'm unclear what the "different paths" are. Hm, there might be only one "different path" in Java - Thread.dumpStack() and Thread.getAllStackTraces() -JB- > > David > ----- > >> -JB- >> >>> >>> David >>> ----- >>> >>>> Mandy >> From shanliang.jiang at oracle.com Wed Jul 24 05:05:43 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 24 Jul 2013 14:05:43 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EFBFA3.90608@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> <51EF930E.4050507@oracle.com> <51EF9552.1020901@oracle.com> <51EF9F0D.7040709@oracle.com> <51EFB8B7.6030204@oracle.com> <51EFBFA3.90608@oracle.com> Message-ID: <51EFC317.8050809@oracle.com> Jaroslav Bachorik wrote: > On 07/24/2013 01:21 PM, David Holmes wrote: > >> On 24/07/2013 7:31 PM, Mandy Chung wrote: >> >>> On 7/24/2013 4:50 PM, shanliang wrote: >>> >>>> So we have 2 kinds of issues here: >>>> 1) the test related, like Thread state checking, we can fix them in >>>> the test >>>> 2) MBean.getThreadCount() issue, we can create a bug to trace it (add >>>> your test case to the bug), and add a workaround (sleep or call 2 >>>> times) in the test to make the test pass. Mandy is the expert and >>>> better to get her opinion. >>>> >>> It's probably a race in the VM implementation in determining the thread >>> count. You will need to diagnose the VM implementation and compare the >>> thread list and the implementation of getting the thread count (check >>> hotspot/src/share/vm/services/threadService.cpp) >>> >> There is a considerable code path between the point where a terminating >> thread causes Thread.join() to be allowed to return, and the point where >> the live thread count gets decremented. So using join() does not help >> here. Arguably JVMTI should have based its counts around the lifecycle >> of the Java thread not the underlying native thread. >> > > So, if I understand it correctly, it is not possible to get 100% > accuracy of the thread related counters in situations when you create > and terminate a number of threads rapidly. > If Thread.getAllStackTraces() could get right number, then we could not say "it is not possible"? :) Shanliang > In that case this test could be fixed with a small waiting period after > all the joined threads were terminated - just to make sure that all the > exiting threads were properly collected. > > The only question remains whether a bug should be filed for the > discrepancy between the thread counters obtained from ThreadMXBean and > the ones coming from different paths. > > -JB- > > >> David >> ----- >> >> >>> Mandy >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130724/3fb1fe77/attachment-0001.html From chris.hegarty at oracle.com Wed Jul 24 05:32:17 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 24 Jul 2013 13:32:17 +0100 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EFB8B7.6030204@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> <51EF930E.4050507@oracle.com> <51EF9552.1020901@oracle.com> <51EF9F0D.7040709@oracle.com> <51EFB8B7.6030204@oracle.com> Message-ID: <51EFC951.70704@oracle.com> On 24/07/2013 12:21, David Holmes wrote: > On 24/07/2013 7:31 PM, Mandy Chung wrote: >> >> On 7/24/2013 4:50 PM, shanliang wrote: >>> So we have 2 kinds of issues here: >>> 1) the test related, like Thread state checking, we can fix them in >>> the test >>> 2) MBean.getThreadCount() issue, we can create a bug to trace it (add >>> your test case to the bug), and add a workaround (sleep or call 2 >>> times) in the test to make the test pass. Mandy is the expert and >>> better to get her opinion. >> >> It's probably a race in the VM implementation in determining the thread >> count. You will need to diagnose the VM implementation and compare the >> thread list and the implementation of getting the thread count (check >> hotspot/src/share/vm/services/threadService.cpp) > > There is a considerable code path between the point where a terminating > thread causes Thread.join() to be allowed to return, and the point where > the live thread count gets decremented. So using join() does not help > here. Arguably JVMTI should have based its counts around the lifecycle > of the Java thread not the underlying native thread. It appears, from my reading of the code, that this situation ( a thread exiting ) should be handled. Or maybe I'm looking at the wrong interface. JavaThread::exit(...) { ... ThreadService::current_thread_exiting(this); ... ensure_join(..) ... } So the exiting thread should be removed from the live thread count before Thread.join returns. -Chris. > > David > ----- > >> Mandy From jaroslav.bachorik at oracle.com Wed Jul 24 05:49:34 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 24 Jul 2013 14:49:34 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EFC951.70704@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> <51EF930E.4050507@oracle.com> <51EF9552.1020901@oracle.com> <51EF9F0D.7040709@oracle.com> <51EFB8B7.6030204@oracle.com> <51EFC951.70704@oracle.com> Message-ID: <51EFCD5E.3090007@oracle.com> On 07/24/2013 02:32 PM, Chris Hegarty wrote: > On 24/07/2013 12:21, David Holmes wrote: >> On 24/07/2013 7:31 PM, Mandy Chung wrote: >>> >>> On 7/24/2013 4:50 PM, shanliang wrote: >>>> So we have 2 kinds of issues here: >>>> 1) the test related, like Thread state checking, we can fix them in >>>> the test >>>> 2) MBean.getThreadCount() issue, we can create a bug to trace it (add >>>> your test case to the bug), and add a workaround (sleep or call 2 >>>> times) in the test to make the test pass. Mandy is the expert and >>>> better to get her opinion. >>> >>> It's probably a race in the VM implementation in determining the thread >>> count. You will need to diagnose the VM implementation and compare the >>> thread list and the implementation of getting the thread count (check >>> hotspot/src/share/vm/services/threadService.cpp) >> >> There is a considerable code path between the point where a terminating >> thread causes Thread.join() to be allowed to return, and the point where >> the live thread count gets decremented. So using join() does not help >> here. Arguably JVMTI should have based its counts around the lifecycle >> of the Java thread not the underlying native thread. > > It appears, from my reading of the code, that this situation ( a thread > exiting ) should be handled. Or maybe I'm looking at the wrong interface. > > JavaThread::exit(...) { > ... > ThreadService::current_thread_exiting(this); > ... > ensure_join(..) > ... > } > > So the exiting thread should be removed from the live thread count > before Thread.join returns. Unfortunately, ensure_join(...) is called on line 1860 but Threads::remove(this), which does the actual cleanup of the live threads counter, is called only on line 1919, leaving at least a few ns window when the thread is reported as terminated in java but the counters haven't been updated yet. -JB- > > -Chris. > >> >> David >> ----- >> >>> Mandy From chris.hegarty at oracle.com Wed Jul 24 06:17:41 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 24 Jul 2013 14:17:41 +0100 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EFCD5E.3090007@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> <51EF930E.4050507@oracle.com> <51EF9552.1020901@oracle.com> <51EF9F0D.7040709@oracle.com> <51EFB8B7.6030204@oracle.com> <51EFC951.70704@oracle.com> <51EFCD5E.3090007@oracle.com> Message-ID: <51EFD3F5.3060209@oracle.com> On 24/07/2013 13:49, Jaroslav Bachorik wrote: > On 07/24/2013 02:32 PM, Chris Hegarty wrote: >> On 24/07/2013 12:21, David Holmes wrote: >>> On 24/07/2013 7:31 PM, Mandy Chung wrote: >>>> >>>> On 7/24/2013 4:50 PM, shanliang wrote: >>>>> So we have 2 kinds of issues here: >>>>> 1) the test related, like Thread state checking, we can fix them in >>>>> the test >>>>> 2) MBean.getThreadCount() issue, we can create a bug to trace it (add >>>>> your test case to the bug), and add a workaround (sleep or call 2 >>>>> times) in the test to make the test pass. Mandy is the expert and >>>>> better to get her opinion. >>>> >>>> It's probably a race in the VM implementation in determining the thread >>>> count. You will need to diagnose the VM implementation and compare the >>>> thread list and the implementation of getting the thread count (check >>>> hotspot/src/share/vm/services/threadService.cpp) >>> >>> There is a considerable code path between the point where a terminating >>> thread causes Thread.join() to be allowed to return, and the point where >>> the live thread count gets decremented. So using join() does not help >>> here. Arguably JVMTI should have based its counts around the lifecycle >>> of the Java thread not the underlying native thread. >> >> It appears, from my reading of the code, that this situation ( a thread >> exiting ) should be handled. Or maybe I'm looking at the wrong interface. >> >> JavaThread::exit(...) { >> ... >> ThreadService::current_thread_exiting(this); >> ... >> ensure_join(..) >> ... >> } >> >> So the exiting thread should be removed from the live thread count >> before Thread.join returns. > > Unfortunately, ensure_join(...) is called on line 1860 but > Threads::remove(this), which does the actual cleanup of the live threads > counter, is called only on line 1919, leaving at least a few ns window > when the thread is reported as terminated in java but the counters > haven't been updated yet. Again, maybe I'm missing something but, static jlong get_live_thread_count() { return _live_threads_count->get_value() - _exiting_threads_count; } ... and current_thread_exiting(..) increments _exiting_threads_count, no? -Chris. > > -JB- > >> >> -Chris. >> >>> >>> David >>> ----- >>> >>>> Mandy > From shanliang.jiang at oracle.com Wed Jul 24 06:51:29 2013 From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com) Date: Wed, 24 Jul 2013 13:51:29 +0000 Subject: hg: jdk8/tl/jdk: 8016221: A unit test should not use a fix port to run a jmx connector Message-ID: <20130724135234.0309948303@hg.openjdk.java.net> Changeset: 187a1f2613c0 Author: sjiang Date: 2013-07-24 15:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/187a1f2613c0 8016221: A unit test should not use a fix port to run a jmx connector Reviewed-by: jbachorik, dfuchs ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanDoubleInvocationTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanInvocationTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTest.java From jaroslav.bachorik at oracle.com Wed Jul 24 07:08:02 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 24 Jul 2013 16:08:02 +0200 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EFD3F5.3060209@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> <51EF930E.4050507@oracle.com> <51EF9552.1020901@oracle.com> <51EF9F0D.7040709@oracle.com> <51EFB8B7.6030204@oracle.com> <51EFC951.70704@oracle.com> <51EFCD5E.3090007@oracle.com> <51EFD3F5.3060209@oracle.com> Message-ID: <51EFDFC2.20503@oracle.com> On 07/24/2013 03:17 PM, Chris Hegarty wrote: > On 24/07/2013 13:49, Jaroslav Bachorik wrote: >> On 07/24/2013 02:32 PM, Chris Hegarty wrote: >>> On 24/07/2013 12:21, David Holmes wrote: >>>> On 24/07/2013 7:31 PM, Mandy Chung wrote: >>>>> >>>>> On 7/24/2013 4:50 PM, shanliang wrote: >>>>>> So we have 2 kinds of issues here: >>>>>> 1) the test related, like Thread state checking, we can fix them in >>>>>> the test >>>>>> 2) MBean.getThreadCount() issue, we can create a bug to trace it (add >>>>>> your test case to the bug), and add a workaround (sleep or call 2 >>>>>> times) in the test to make the test pass. Mandy is the expert and >>>>>> better to get her opinion. >>>>> >>>>> It's probably a race in the VM implementation in determining the >>>>> thread >>>>> count. You will need to diagnose the VM implementation and compare the >>>>> thread list and the implementation of getting the thread count (check >>>>> hotspot/src/share/vm/services/threadService.cpp) >>>> >>>> There is a considerable code path between the point where a terminating >>>> thread causes Thread.join() to be allowed to return, and the point >>>> where >>>> the live thread count gets decremented. So using join() does not help >>>> here. Arguably JVMTI should have based its counts around the lifecycle >>>> of the Java thread not the underlying native thread. >>> >>> It appears, from my reading of the code, that this situation ( a thread >>> exiting ) should be handled. Or maybe I'm looking at the wrong >>> interface. >>> >>> JavaThread::exit(...) { >>> ... >>> ThreadService::current_thread_exiting(this); >>> ... >>> ensure_join(..) >>> ... >>> } >>> >>> So the exiting thread should be removed from the live thread count >>> before Thread.join returns. >> >> Unfortunately, ensure_join(...) is called on line 1860 but >> Threads::remove(this), which does the actual cleanup of the live threads >> counter, is called only on line 1919, leaving at least a few ns window >> when the thread is reported as terminated in java but the counters >> haven't been updated yet. > > Again, maybe I'm missing something but, > > static jlong get_live_thread_count() { return > _live_threads_count->get_value() - _exiting_threads_count; } > > ... and current_thread_exiting(..) increments _exiting_threads_count, no? Well, apparently it does. I am a complete stranger to the concurrency issues in the hotspot - would it be possible that in ThreadService::remove_thread(..) the _exiting_threads_count is decremented but _live_threads_count hasn't been updated yet when someone calls the get_live_thread_count() function? -JB- > > -Chris. > >> >> -JB- >> >>> >>> -Chris. >>> >>>> >>>> David >>>> ----- >>>> >>>>> Mandy >> From chris.hegarty at oracle.com Wed Jul 24 07:20:22 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 24 Jul 2013 15:20:22 +0100 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EFDFC2.20503@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> <51EF930E.4050507@oracle.com> <51EF9552.1020901@oracle.com> <51EF9F0D.7040709@oracle.com> <51EFB8B7.6030204@oracle.com> <51EFC951.70704@oracle.com> <51EFCD5E.3090007@oracle.com> <51EFD3F5.3060209@oracle.com> <51EFDFC2.20503@oracle.com> Message-ID: <51EFE2A6.8010103@oracle.com> On 24/07/2013 15:08, Jaroslav Bachorik wrote: > On 07/24/2013 03:17 PM, Chris Hegarty wrote: >> On 24/07/2013 13:49, Jaroslav Bachorik wrote: >>> On 07/24/2013 02:32 PM, Chris Hegarty wrote: >>>> On 24/07/2013 12:21, David Holmes wrote: >>>>> On 24/07/2013 7:31 PM, Mandy Chung wrote: >>>>>> >>>>>> On 7/24/2013 4:50 PM, shanliang wrote: >>>>>>> So we have 2 kinds of issues here: >>>>>>> 1) the test related, like Thread state checking, we can fix them in >>>>>>> the test >>>>>>> 2) MBean.getThreadCount() issue, we can create a bug to trace it (add >>>>>>> your test case to the bug), and add a workaround (sleep or call 2 >>>>>>> times) in the test to make the test pass. Mandy is the expert and >>>>>>> better to get her opinion. >>>>>> >>>>>> It's probably a race in the VM implementation in determining the >>>>>> thread >>>>>> count. You will need to diagnose the VM implementation and compare the >>>>>> thread list and the implementation of getting the thread count (check >>>>>> hotspot/src/share/vm/services/threadService.cpp) >>>>> >>>>> There is a considerable code path between the point where a terminating >>>>> thread causes Thread.join() to be allowed to return, and the point >>>>> where >>>>> the live thread count gets decremented. So using join() does not help >>>>> here. Arguably JVMTI should have based its counts around the lifecycle >>>>> of the Java thread not the underlying native thread. >>>> >>>> It appears, from my reading of the code, that this situation ( a thread >>>> exiting ) should be handled. Or maybe I'm looking at the wrong >>>> interface. >>>> >>>> JavaThread::exit(...) { >>>> ... >>>> ThreadService::current_thread_exiting(this); >>>> ... >>>> ensure_join(..) >>>> ... >>>> } >>>> >>>> So the exiting thread should be removed from the live thread count >>>> before Thread.join returns. >>> >>> Unfortunately, ensure_join(...) is called on line 1860 but >>> Threads::remove(this), which does the actual cleanup of the live threads >>> counter, is called only on line 1919, leaving at least a few ns window >>> when the thread is reported as terminated in java but the counters >>> haven't been updated yet. >> >> Again, maybe I'm missing something but, >> >> static jlong get_live_thread_count() { return >> _live_threads_count->get_value() - _exiting_threads_count; } >> >> ... and current_thread_exiting(..) increments _exiting_threads_count, no? > > Well, apparently it does. > > I am a complete stranger to the concurrency issues in the hotspot - > would it be possible that in ThreadService::remove_thread(..) the > _exiting_threads_count is decremented but _live_threads_count hasn't > been updated yet when someone calls the get_live_thread_count() function? I am not familiar with the intricate workings of this code, but as a casual observer I would say that this must be a bug in the VM. It appears that the original authors did take into account exiting threads, and went to some lengths to provide accurate diagnostic information. If this is not producing the correct results, then I can only imagine there is a bug here. To your specific question, then yes this would appear possible. I am not sure what synchronization, if any, protects this code. -Chris. > > -JB- > >> >> -Chris. >> >>> >>> -JB- >>> >>>> >>>> -Chris. >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Mandy >>> > From daniel.daugherty at oracle.com Wed Jul 24 07:34:52 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 24 Jul 2013 08:34:52 -0600 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EF83A6.1040200@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> Message-ID: <51EFE60C.9010104@oracle.com> On 7/24/13 1:35 AM, Jaroslav Bachorik wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/24/2013 09:21 AM, shanliang wrote: >> Just to be a test, after terminated 8 threads and checked their >> states by calling Thread.join() (must be same to >> Thread.getState()), DO sleep sometime and then call >> mbean.getThreadCount(), if it reports a right number, then we may >> need to verify mbean.getThreadCount() method. > The result is: > > Thread: Thread[Signal Dispatcher,9,system] > Thread: Thread[Finalizer,8,system] > Thread: Thread[worker-12,5,main] > Thread: Thread[Reference Handler,10,system] > Thread: Thread[main,5,main] > Thread: Thread[worker-13,5,main] > - ---> MBean.getThreadCount() = 7 The above count == 7, but there are only 6 thread names above it. That's good confirmation of a race between when a thread is declared dead (and you can't get its name anymore) and the live thread counter being off... This has turned into an interesting test fix... Dan > Thread(1): Thread[Signal Dispatcher,9,system] > Thread(1): Thread[Finalizer,8,system] > Thread(1): Thread[worker-12,5,main] > Thread(1): Thread[Reference Handler,10,system] > Thread(1): Thread[main,5,main] > Thread(1): Thread[worker-13,5,main] > - ---> MBean.getThreadCount() = 6 > > - -JB- > > >> Shanliang >> >> Jaroslav Bachorik wrote: >>> On Wed 24 Jul 2013 08:20:56 AM CEST, Mandy Chung wrote: >>> >>>> On 7/24/2013 2:09 PM, Daniel Fuchs wrote: >>>> >>>>> On 7/24/13 8:01 AM, Mandy Chung wrote: >>>>> >>>>>> I am catching up on this thread.... >>>>>> >>>>>> The thread count counts Java threads that are not hidden. >>>>>> I believe all VM internal threads are hidden from external >>>>>> API. This test runs in othervm mode and AFAICT the thread >>>>>> count is expected to be deterministic. I don't expect the >>>>>> VM will start and terminate any thread any time. >>>>>> >>>>>> I agree with David that we should diagnose why there is >>>>>> one additional thread started before the reset. If it is >>>>>> the LogManager$Cleaner thread, like David said, the VM is >>>>>> shutting down while the test is still running which doesn't >>>>>> quite make sense. >>>>>> >>>>> I think that Shanliang's suspicion that a thread might be >>>>> still alive if unscheduled just after having called its >>>>> barrier.signal() is a very good suggestion. I would advise >>>>> calling thread.join() on all threads in terminateThreads, >>>>> just to make sure they are all really dead and not in some >>>>> comatose state... If Shanliang is right then the test would >>>>> be failing because some of the threads we think are dead are >>>>> not actually dead yet - and not because of some new VM thread >>>>> that nobody can see :-) >>>>> >>>> Thanks for pointing that out. >>>> >>>> I agree that the test should be changed to call Thread.join(). >>>> There may be other java.lang.management tests that should also >>>> be fixed to call Thread.join. >>>> >>> I've tried using Thread.join() but I am still getting the thread >>> count discrepancy. >>> >>> Specifically: 1. 10 worker threads have been successfully started >>> - mben.getThreadCount() reports 14 and >>> Thread.getAllStackTraces() returns 14 items --- Thread: >>> Thread[Signal Dispatcher,9,system] Thread: >>> Thread[worker-5,5,main] Thread: Thread[worker-7,5,main] Thread: >>> Thread[worker-9,5,main] Thread: Thread[worker-12,5,main] Thread: >>> Thread[worker-11,5,main] Thread: Thread[Reference >>> Handler,10,system] Thread: Thread[main,5,main] Thread: >>> Thread[worker-10,5,main] Thread: Thread[worker-8,5,main] Thread: >>> Thread[Finalizer,8,system] Thread: Thread[worker-6,5,main] >>> Thread: Thread[worker-13,5,main] Thread: Thread[worker-4,5,main] >>> --- 2. Terminating 8 threads 3. After the threads have been >>> terminated (waiting on Thread.join() for them to die) - >>> mbean.getThreadCount() reports 7 while Thread.getAllStackTraces() >>> returns only 6 items --- Thread: Thread[Signal >>> Dispatcher,9,system] Thread: Thread[Finalizer,8,system] Thread: >>> Thread[worker-12,5,main] Thread: Thread[Reference >>> Handler,10,system] Thread: Thread[main,5,main] Thread: >>> Thread[worker-13,5,main] --- >>> >>> This would almost point to mbean.getThreadCount() reporting a >>> stale value. Is that possible? >>> >>> -JB- >>> >>> >>>> Mandy >>>> >>> >>> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJR74OmAAoJELSZyqhGiB1M4k8H/2hM5o2vVe2lfhc374IBaR5R > R8i9Z2n0prBRKIqg4bTkAcllq5pmdozxwFyaEBzJtAGh9vnL7Tmojn6ksg9K+MMl > bSgWSeg+gSZyymS7aE8rTVqKigH8vNOpHOogePDrUOCZGeZgJIMpmY1QcVbLeq8k > mkz5mPYxEE2E7gt8cjvcXknOWeQUTyZILWGIPBfx9FL0iwBtK5h0PnfasR7bCxcR > DO48USIuTxe+aN687OkAlJq9bCR6HRzWQiaSdi4ROVyrx2xYtir4n9sZtNWJwokv > 3p5TdX6S64jnVZZMjbPJgCENTYMvTeRCj/8GvCYlI9KQEa9x2zhU2wIp5Zw4ag4= > =4vkV > -----END PGP SIGNATURE----- From jason.uh at oracle.com Wed Jul 24 12:50:33 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Wed, 24 Jul 2013 19:50:33 +0000 Subject: hg: jdk8/tl/jdk: 8016916: UnstructuredName should support DirectoryString Message-ID: <20130724195115.5085E48320@hg.openjdk.java.net> Changeset: f9224fb49890 Author: juh Date: 2013-07-24 12:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9224fb49890 8016916: UnstructuredName should support DirectoryString Reviewed-by: mullan ! src/share/classes/sun/security/pkcs/PKCS9Attribute.java ! src/share/classes/sun/security/tools/keytool/Main.java + test/sun/security/pkcs/pkcs9/UnstructuredName.java From chris.hegarty at oracle.com Wed Jul 24 14:53:05 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 24 Jul 2013 21:53:05 +0000 Subject: hg: jdk8/tl/jdk: 8021261: ProblemList.txt updates (7/2013) Message-ID: <20130724215333.7F7EE48325@hg.openjdk.java.net> Changeset: fd1b5adcfdf0 Author: chegar Date: 2013-07-24 22:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fd1b5adcfdf0 8021261: ProblemList.txt updates (7/2013) Reviewed-by: alanb, mcimadamore ! test/ProblemList.txt From jonathan.gibbons at oracle.com Wed Jul 24 17:36:13 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 25 Jul 2013 00:36:13 +0000 Subject: hg: jdk8/tl/langtools: 8020556: doclint does not check type variables for @throws Message-ID: <20130725003619.3FE3D48339@hg.openjdk.java.net> Changeset: 2fbe77c38802 Author: jjg Date: 2013-07-24 17:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2fbe77c38802 8020556: doclint does not check type variables for @throws Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! test/tools/doclint/ReferenceTest.java From sundararajan.athijegannathan at oracle.com Wed Jul 24 21:45:09 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 25 Jul 2013 04:45:09 +0000 Subject: hg: jdk8/tl/nashorn: 7 new changesets Message-ID: <20130725044516.6B74148346@hg.openjdk.java.net> Changeset: 8b97fe2b7c98 Author: attila Date: 2013-07-23 18:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8b97fe2b7c98 8021129: Use public lookup again Reviewed-by: lagergren, sundar ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java - src/jdk/internal/dynalink/beans/SafeUnreflector.java - src/jdk/internal/dynalink/beans/SafeUnreflectorImpl.java - src/jdk/internal/dynalink/beans/SandboxClassLoader.java - src/jdk/internal/dynalink/beans/sandbox/Unreflector.java + test/script/trusted/JDK-8021129.js + test/script/trusted/JDK-8021129.js.EXPECTED + test/src/jdk/nashorn/internal/test/models/InternalRunnable.java + test/src/jdk/nashorn/internal/test/models/RestrictedRunnable.java + test/src/jdk/nashorn/test/models/InternalRunnableSuperclass.java Changeset: a58a07a00122 Author: attila Date: 2013-07-24 11:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a58a07a00122 8021189: Prevent access to constructors of restricted classes Reviewed-by: lagergren, sundar ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java ! test/script/trusted/JDK-8006529.js ! test/script/trusted/JDK-8021129.js + test/script/trusted/JDK-8021189.js + test/script/trusted/JDK-8021189.js.EXPECTED Changeset: e4efb3ce97b2 Author: attila Date: 2013-07-24 12:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e4efb3ce97b2 8021246: Fix regression for 8021189 Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! test/script/trusted/JDK-8006529.js Changeset: 2a25917777f7 Author: hannesw Date: 2013-07-24 13:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2a25917777f7 8020718: RETURN symbol has wrong type in split functions Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/SplitMethodEmitter.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/Symbol.java Changeset: 573cc6eb66ae Author: jlaskey Date: 2013-07-24 08:25 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/573cc6eb66ae Merge - src/jdk/internal/dynalink/beans/SafeUnreflector.java - src/jdk/internal/dynalink/beans/SafeUnreflectorImpl.java - src/jdk/internal/dynalink/beans/SandboxClassLoader.java - src/jdk/internal/dynalink/beans/sandbox/Unreflector.java Changeset: dc54df348a58 Author: sundar Date: 2013-07-24 20:28 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/dc54df348a58 8021262: Make nashorn access checks consistent with underlying dynalink Reviewed-by: jlaskey, lagergren, attila ! make/code_coverage.xml ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java ! test/script/sandbox/nashorninternals.js ! test/script/trusted/JDK-8006529.js ! test/script/trusted/JDK-8021129.js ! test/script/trusted/JDK-8021189.js ! test/script/trusted/JDK-8021189.js.EXPECTED ! test/src/jdk/nashorn/test/models/InternalRunnableSuperclass.java Changeset: d203d68f6624 Author: sundar Date: 2013-07-24 21:01 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d203d68f6624 8021294: --verify-code option results in AnalyzerException Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/runtime/Context.java From david.holmes at oracle.com Wed Jul 24 22:07:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jul 2013 15:07:01 +1000 Subject: jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently In-Reply-To: <51EFDFC2.20503@oracle.com> References: <51ED1DBE.3030304@oracle.com> <51EE3C9B.3050604@oracle.com> <51EE3EE2.1000202@oracle.com> <51EE4A91.3000305@oracle.com> <51EE4BD6.7040707@oracle.com> <51EE50B4.8040000@oracle.com> <51EE528F.2050302@oracle.com> <51EE52B9.6070506@oracle.com> <51EF6DD6.5060806@oracle.com> <51EF6FA1.9000103@oracle.com> <51EF7248.2070405@oracle.com> <51EF7888.40100@oracle.com> <51EF8091.9030603@oracle.com> <51EF83A6.1040200@oracle.com> <51EF926A.3060705@oracle.com> <51EF930E.4050507@oracle.com> <51EF9552.1020901@oracle.com> <51EF9F0D.7040709@oracle.com> <51EFB8B7.6030204@oracle.com> <51EFC951.70704@oracle.com> <51EFCD5E.3090007@oracle.com> <51EFD3F5.3060209@oracle.com> <51EFDFC2.20503@oracle.com> Message-ID: <51F0B275.4060906@oracle.com> On 25/07/2013 12:08 AM, Jaroslav Bachorik wrote: > On 07/24/2013 03:17 PM, Chris Hegarty wrote: >> On 24/07/2013 13:49, Jaroslav Bachorik wrote: >>> On 07/24/2013 02:32 PM, Chris Hegarty wrote: >>>> On 24/07/2013 12:21, David Holmes wrote: >>>>> On 24/07/2013 7:31 PM, Mandy Chung wrote: >